@xav1er ?

@zhaoxiting1997 get 的合适用法，应该是可多次请求但基本不会改变其数据的资源。比如读取文章（尽管可能更新阅读数）；至于增删改，因为对数据影响比较大，一概用 post。响应了 post 请求之后，应该 redirect 到一个结果页，以防刷新页面引发重复提交。

装个 Ubuntu ，几条命令就好了……

鉴得多了，就成了黄牛

@jsq2627 那这样是正确的用法吗：HMAC(myFunc(originalHash, salt), randomString)

@wy315700 昂……是的啊。所以说，在安全策略不允许明文存储密码的前提下，客户端要实现对应的加密算法才行呢。

引用 @wy315700：
「你这样如何检验密码正确性，每次提交的MD5都不一样。」

服务器也用这个随机数，和之前存储的用户密钥放在一起，用相同的算法计算结果，与客户端相同，则认为其是授权用户。所以，在上面我也说这要求客户端也实现加密算法，从而不适用传统 Web 应用。
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

@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」有些反感。