@wy315700 hmac 里服务端生成的随机数，才是其关键吧！这样不用传输敏感的密码原文，即可完成对密码的验证。

如果只是因为盐与密码原文拼接后有碰撞，而采用 hmac，我觉得大可不必，因为：

1. 盐由服务器管理，每用户唯一，对于单个用户来说，因为盐是固定的（如 ef），所以不存在相似密码与盐拼接后碰撞的问题（abc 永远不会通过验证，盐不可变更）；

2. 盐在生成时，可以技术手段保证位数相同，不给掌握密码前半部分的攻击者以瞎蒙之机；

3. 在用盐计算哈希值时，可以用明文与盐的哈希值拼接，然后再取哈希值。

@stiekel 关于 md5 这段，我突然想到：

如果「浏览器端对密码进行md5」被普遍采用，一旦 md5 值被截取，那将势必「影响到用户在其它场合中的密码安全」。因为密码作为明文输入 md5 函数做参，得到的摘要是一样的。所以，要想各种场合密码互不影响，则要保证：

每一个应用，各自采用不同的 md5 加密次数，你两遍我三遍，猪八戒三十六遍、孙悟空七十二便，以保证网络中传输的 md5 值不被用做其他场合上。

所以，与其这样，不如也在客户端「加盐」，只一遍 md5 就不会影响到其他场合了。再进一步，如果每次会话都由服务器生成一个随机数，作为「胡椒」加到明文后面做出哈西摘要拿去验证，那么，「别人拿到这个md5」也因为再次请求时随机数不同，而不能「直接在应用中登陆」了，岂不更妙。具体实现上，可以参考 hmac。

@zhicheng 可不可以发一篇博文之类，让更多人学习一下？

@wy315700 我理解的 hmac ，是用一定的 hash 算法和随机数，解决了密钥在客户端和服务端传输的风险问题。自然要求客户端实现加密算法啊。

如果只在 B/S 架构的 Server 端应用 hmac 来验证用户提交的密码是否与数据库中一致，hmac 的客户端和服务端角色都由 Server Script 扮演，不会多此一举吗？

@zhicheng 又学到了新名词。楼主的问题是解决简便验证盐、hash，至于怎么加密，则又够开一帖讨论的了。

@wy315700 本贴中的数据库存放盐和 hash 值的做法是传统 B/S 验证的典型方案。hmac 需要客户端自行实现加密方法吧？

我都是咬着牙、闭着眼，原价续的

引用楼主：
正常流程需要三步
表单提交的用户名$username和 密码$psw

步骤1先查出盐$salt
select salt from table where username = '$username'
步骤2然后加密
$password = md5($psw.$salt);
步骤3最后再查是否有符合条件的数据
select * from table where username='' and password='$password'
有结果就说明密码正确
没结果就说明密码错误或者没这个用户名的账号

这里的描述有逻辑漏洞：

* 如果步骤 1 没有查到盐，就说明用户号不存在；
* 如果步骤 1 中查到盐，步骤 3 没有结果则只可能是密码错误；

不如把加密过程留在脚本里做：

1. 先一次查询出盐和密码：
select salt, password from table where username = '$username'

2. 再加密对比：
$result = ($password == md5($psw.$salt) ? 'success' : 'failed');

这样，加密方式有很多种选择。比如：

sha1( password + sha1( salt ) )

@stiekel
@xenme
@BOYPT 不如直接用 https 处理登录请求，安全方便。

引用 @xenme ：
> 1. 从前台收到用户名，根据规则计算出 salt

「计算出」的过程可逆吗？以用户名做种子的算法也是不安全的，用随机生成的短密钥做盐会好些。

@puras
@laoyur 是冲了，看到「有空XX却没空YY」有些反感。

用豆瓣管理书单、阅读状态；
用文件夹对资源简单分类；
用 Everything 搜索资源。

@est 那就关注我的知乎吧，嘿嘿

@jedihy
@ynyounuo 哈哈，只是给这位网友回复一下以示尊敬，其他人略过即可 :)

@lingo233 啊？

@suikator 这么可爱还不萌？

@blessme
@laoyuan
@roychan
@imWBB 嗯，哈哈，的确是 Linode 上的邻居

可以 +1

@Gonster 这是来 Linux 社区砸场子的么…