安全地发送纯文本密码?

我正在开发一个 iOS 应用程序,该应用程序将让用户填写他们的密码.然后,密码将使用 POST 或 GET 发布到我网站上的 PHP 页面.(它必须是明文,因为它在脚本中使用.)

I'm working on an application for iOS which will have the user fill out their password. The password will then be posted to a PHP page on my site using either POST or GET. (It must be plaintext because it is used in a script.)

除了 HTTPS,还有什么方法可以保护密码吗?用 Obj-C 加密,然后用 PHP 解密?

Besides HTTPS, is there any way to secure the password? Encrypt it in Obj-C and then decrypt it in PHP?

注意:不发送用户名...仅将密码发布到服务器.

NOTE: The username is not sent... only the password is posted to the server.

澄清一下,David Stratton 是正确的……我试图防止公共场所的恶意嗅探器在明文密码发布到服务器时简单地读取它们.

To clarify, David Stratton is correct... I'm trying to prevent malicious sniffers in public locations from simply reading clear text passwords as they are posted to the server.

推荐答案

挑战响应大纲

假设您有单向哈希函数 abc(实际上使用 md5sha1 加密PHP 的强散列算法参见:password_hash).

Lets assume you have one-way hash function abc (in practice use md5 or sha1 a cryptographically strong hashing algorithm for PHP see: password_hash).

您存储在数据库中的密码是abc(password + salt)(单独存储salt)

The password you store in your database is abc(password + salt) (store the salt separately)

服务器生成随机挑战challenge并将其发送给客户端(使用salt)并计算预期响应:abc(challenge + abc(密码+盐))

The server generates a random challenge challenge and sends it to the client (with the salt) and calculates the expected response: abc(challenge + abc(password + salt))

客户端然后计算:abc(user_password + salt)并应用challenge得到abc(challenge + abc(user_password + salt))code>,即发送到服务器,服务器可以方便地验证有效性.

The client then calculates: abc(user_password + salt) and applies the challenge to get abc(challenge + abc(user_password + salt)), that is sent to the server and the server can easily verify validity.

这是安全的,因为:

  • 密码永远不会以明文形式发送或以明文形式存储
  • 每次发送的哈希值都会改变(缓解重放攻击)

有一些问题:

你怎么知道要送什么盐?好吧,我从来没有真正找到解决方案,但是使用确定性算法将用户名变成盐可以解决这个问题.如果算法不是确定性的,攻击者可能会找出哪个用户名存在,哪个不存在.不过,这确实需要您拥有用户名.或者,您可以只使用静态盐,但我对密码学的了解不够,无法评估该实现的质量.

How do you know what salt to send? Well, I've never really found a solution for this, but using a deterministic algorithm to turn a username into a salt solves this problem. If the algorithm isn't deterministic an attacker could potentially figure out which username exists and which do not. This does require you to have a username though. Alternatively you could just have a static salt, but I don't know enough about cryptography to assess the quality of that implementation.

相关文章