我编写了一个C应用程序框架,它使用RESTful API与服务器应用程序通信.客户端和服务器之间传递的数据当前使用服务器和客户端中已知(硬编码)的(32位长)简单密码.

在我目前的方案中,客户端和服务器之间的数据传输是作为二进制编码数据完成的.数据是使用密码加密的压缩JSON格式字符串(如上所述).

我知道这可能是最弱的安全形式.我想通过使用HTPPS以及其他一些机制来加强安全性,以便每个客户端都有一个不能伪造的唯一令牌 – 即使是任何可能碰巧正在窃听消息的人也是如此.这非常重要,因为敏感的个人和财务数据将在服务器和客户端之间传输,因此任何安全漏洞都可能被认为是致命的.

任何人都可以概述一个策略/方法(或最佳实践)来实现这样的安全性 – 包括,如果我必须做任何其他事情来使用HTTPS而不是HTTP – 偶然(可能看起来是一个愚蠢的问题),但HTTPS的额外安全性在我上面描述的方案中通过HTTP提供？

我特别感兴趣的是：

> RESTful身份验证/授权
>安全地处理每个客户端 – 以便服务器可以识别试图“假装”成为另一个客户端的恶意客户端的尝试.例如,子应用程序的instanceA不应该伪装成instanceB.

最佳答案 首先关注合理的安全措施

我们广泛部署了一个应用程序(美国和欧洲),它依赖于几个简单的原则

>所有通信都通过HTTPS进行,以防止中间人攻击
>所有用户(或您的案例中的应用程序)都有一个用户名和密码
用于验证身份 – 验证是通过HTTPS进行的
>经过验证的用户会获得一个有时间限制的会话密钥,该密钥会在到期时强制重新进行验证
> sys管理员可以随时撤消任何会话
>跟踪所有无效登录并将警报发送给系统管理员,以便我们可以看到正在进行的攻击.

休息认证

我们的应用程序有一个REST风格的API,远程用户界面和第三方(SAP / Excel …)一样使用. REST方面非常正交,但我们使用Ruby RESTful身份验证模块.关键的学习是会话是可以通过对/ sessions资源集的操作创建和销毁的资源.会话将客户端(用户或应用程序)映射到经过身份验证的会话.

关于RESTful身份验证的背景的一篇很好的文章可以找到here.我特别喜欢这个提取…

Authentication is one of the hardest issues when developing software. Because if you got even one bit wrong, your solution is no longer secure. And your reputation may go down with it. So why do web developers insist on developing their own security? Why not use HTTP authentication which is probably far more secure than most programmers will ever be able to develop themselves?

Stackoverflow中已经有一些很好的资源.以here为例

实施HTTPS

您可能非常了解HTTPS需要什么

>证书 – 我们使用GoDaddy – 可怕的网站,但非常便宜和可靠.我们使用全球证书来涵盖整个域名
>一个可以处理HTTPS的Web服务器 – 所有这些天,我们使用NGINX因为它快速,可靠且易于配置
>适当的客户端库,可以处理HTTPS连接