后缀 + MySQL ENCRYPT()，它如何使用随机盐验证密码？
我已经按照此处。
它工作得很好。我的好奇心围绕着将用户输入数据库并对他们进行身份验证
运行：
INSERT INTO users (email, password) VALUES ('[email protected]', ENCRYPT('password'));
多次将为加密密码提供不同的哈希值，因为它使用随机盐。即，如果我使用相同的密码输入 [email protected] 三次，每个哈希值相同是不同的...
我的问题是，当用户通过邮件客户端登录时，Postfix 服务器如何能够真正验证密码？
没有任何问题，因为它工作得很好，更多只是为了满足我的好奇心，这样我就可以完全了解幕后发生的事情，以正确验证加密的密码。
I've implemented my mail server as dictated here.
It works perfectly fine. My curiousity revolves around entering users into the database and authenticating them
Running:
INSERT INTO users (email, password) VALUES ('[email protected]', ENCRYPT('password'));
Multiple times will give a different hash for the encrypted password as its utilizing a random salt. I.e. If I enter [email protected] three times with the same password each hash is different...
My question to this is, how is it that the Postfix server can actually authenticate the password when a user logs in via a mail client?
There isn't any problem per say as it works fine, more just to satisfy my curiosity so I can fully understand whats going on behind the scenes to properly authenticate the encrypted password.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Postfix 将数据库中的密码与使用盐（来自数据库的密码）完成的新加密进行比较。
加密：
检查密码：
Postfix compares the password from the database to a new encrypt done with the salt(password from db).
to encrypt:
to check password:
阅读 man crypt：它返回返回值的前两个字符中的盐。
因此盐不会丢失，您可以将加密的字符串与 crypt( 'pass', $first_two_chars_of_encrypted_value ) 的结果进行比较。
Read man crypt: it returns the salt in the first two chars of the return value.
So the salt is not lost, you can compare the encrypted string to the result of crypt( 'pass', $first_two_chars_of_encrypted_value ).
您必须使用 ENCRYPT('pass','salt') 强制加盐，否则盐将永远丢失并且您无法恢复它。没有它，这个功能就毫无意义。不过，这个功能用起来很糟糕，因为安全性太低了。请改用 PASSWORD() 或 OLD_PASSWORD()。
ENCRYPT() 使用系统 crypt()，它可以使用全部或仅前 8 个字符，必须是可打印的 7 位 ascii，通常使用 1 轮基于 DES 的哈希，并且完全不可移植。避免它。
You must use ENCRYPT('pass','salt') to force a salt, otherwise the salt is lost forever and you have no way of recovering it. Fairly pointless function without it. It's a terrible function to use, though, because the security is so minimal; use PASSWORD() or OLD_PASSWORD() instead.
ENCRYPT() uses the system crypt(), which may use all or only the first 8 characters, must be printable 7-bit ascii, generally uses 1 round of a DES-based hash, and is completely unportable. Avoid it.