有更好的方法吗?
是的,它被称为 SSL/HTTPS。如果您已经在使用 HTTPS,则不需要任何这种加密魔法。如果您不使用 HTTPS,那么您在设计上就已经不安全,您想出的任何办法都无法解决重新发明 SSL 的问题。
那么如果传输是安全的(HTTPS)你应该怎么做
- 客户端以纯文本形式发送用户名+密码进行身份验证请求。
- 服务器根据与帐户一起存储的(希望)散列密码验证用户名 + 密码对。
- 服务器使用静态 AES 密钥以令牌(加密的帐户 ID、到期时间等)进行响应。
- 客户端将令牌用于所有经过身份验证的请求。
简单的。
你可以做的一件事...
为了防止在非安全设备上使用的凭据丢失,您应该从 Google 和其他人那里获取一个页面。与其让用户输入他们的网站密码,不如让他们访问并登录到您的网络服务器。从那里他们单击“为设备生成访问令牌”。生成一个唯一的数据字符串(20 个或更多字符)并记录在他们的帐户中。然后,用户可以从您的网站撤销此“备用密码”。
我怎样才能使它更安全?
你真的不能做得更好,这就是为什么......
假设攻击者可以访问您的私钥。然后,攻击者可以替换您的服务器或扮演中间人,同时窃取用户名和密码。
为了防止这种情况发生,您设计了一些 PKI 交换来发送由服务器给您的公钥加密的密码。作为中间人,我可以简单地给你我自己的公钥并访问用户名和密码,然后如果我选择,将其转发到真实服务器。
- 或者 -
为了防止这种情况发生,您可以使用一些盐 + 密码散列,这些散列将被发送到服务器以代替明文密码。我作为一个中间人可以简单地给你一个盐的固定值,然后为这个盐值预先计算一个完整的彩虹表。现在我再次以明文形式获得了每个人的密码(大多数情况下)。
- 或者 -
为了防止这种情况发生,您使用 PKI 建立一些秘密会话密钥,然后对每个通信进行签名和加密。好吧,哎呀...听起来很熟悉...请参阅Wikipedia 上的 SSL。意识到使 SSL 安全的唯一因素是保护它的私钥。一旦私钥丢失,所有安全和信任都将丢失。
最后注意事项:
如果无法保护某些加密密钥,您就无法建立安全的通信。
您还应该知道,在 SSL 的软件实现(如 OpenSSL)上花费了数千个工时,并且他们不断地在其实现中发现漏洞。您自己实现它并像 IIS 或 OpenSSL 一样安全的希望几乎是零。那不是你的Digg,那只是现实,我也做不到,我只知道甚至不尝试。
最后,我的最后建议是关于您的陈述:“系统内部的某个人可以泄漏它并滥用它”。这是你真正的问题。解决这个问题,其他一切都会容易得多。保护服务器环境应该是您的首要任务。您的第二个优先事项应该是在您未能做到第一个时尽量减少对您的客户的影响。
一些有用的链接: