后缀 + 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.