问题的出现原因：

问题的出现是因为作者想要了解在密码存储和验证过程中，使用的加密算法和技术的差异。作者提到了HMAC和salt两个概念，并且对它们的作用和使用进行了讨论。然后，作者提出了一个存储密码的方案，并希望能够通过这种方案来验证密码。然而，作者对于如何安全地传输和存储salt以及如何防止中间人攻击的问题存在疑虑。因此，作者希望了解在这种情况下应该如何生成和使用salt以及是否需要使用SSL来保护连接。

解决方法：

对于问题中提到的密码存储方案，有几个解决方法可以考虑。首先，关于salt的生成和使用，可以选择在客户端生成salt，然后将salt和密码一起进行哈希计算。这样可以防止彩虹表攻击。然而，这样做的问题是salt可能是可预测的，从而降低了解决方案的安全性。因此，更好的方法是在服务器端生成salt，并将salt与密码一起进行哈希计算。这样可以确保salt的随机性和安全性。

其次，关于传输和存储salt的问题，作者提到了使用HTTPS来保护连接的可能性。使用HTTPS可以确保传输的数据是加密的，从而防止中间人攻击。因此，为了确保数据的安全性，建议在传输salt和哈希值时使用HTTPS。

对于密码存储和验证过程中的加密算法和技术的选择，可以考虑使用HMAC和salt来增加密码的安全性。在存储密码时，建议在服务器端生成salt，并将salt和密码一起进行哈希计算。在验证密码时，通过传输salt给客户端，然后客户端将salt和输入的密码进行哈希计算，并将哈希值发送给服务器进行比较。为了确保数据的安全性，建议使用HTTPS来保护连接。这样可以防止中间人攻击，并提高密码的安全性。

在存储密码时，hash和hash_hmac哪个更好呢？这个问题的出现是因为当前的密码存储方式不够安全。简单使用hash($password . $salt)或hash_hmac($password, $salt)是不够的。计算机（或GPU）的计算时间非常便宜，对密码列表进行暴力破解非常容易。哈希函数被设计为快速而不是昂贵。因此，需要一种更加昂贵的哈希函数来提高密码存储的安全性。

解决方法是使用迭代的方式增加哈希函数的计算复杂度。使用循环对哈希进行多次计算是不好的，因为这样的算法容易受到攻击。使用hash_hmac可以提高工作量，因为每次调用hash_hmac会使用两个哈希循环，而且由于底层是使用C语言实现的，所以只需要大约1.5倍于hash的时间。因此，将hash替换为hash_hmac可以在指定时间内提高33%的工作量。

然而，还可以进一步提高密码存储的安全性。观察上述算法的内部循环，可以发现除了密码和盐之外，所有的算法都只使用了非常少的内存。如果能增加内存使用量，就可以防止并行攻击。一种方法是使用自适应哈希算法bcrypt，它使用比上述算法更多的内存，因此更难以并行化和暴力破解。另一种更安全的算法是scrypt，它使用更多的内存（约20MB到40MB）来哈希单个密码，进一步增加了并行攻击的困难程度。不过，scrypt目前还不支持PHP。

为了确保密码存储的安全性，应该使用经过验证的算法库，如CRYPT_BLOWFISH（bcrypt）、PHPASS或PasswordLib。不要自己发明算法，因为这样做是不负责任的。

附注：根据最近的经验教训，很多人在密码存储上都做错了。使用一个经过验证的算法库是非常重要的。阅读更多相关文章可以深入了解密码存储的方法和原理。

在IT安全专家的观点中，他们建议使用Bcrypt来存储密码。SO的观点是，openssl_digest、hash和hash_hmac都是用于计算哈希值的函数，而HMAC是一种特定的构造，用于计算消息认证码（MAC）。密码的存储通常使用openssl_digest更好。关于SALT和HMAC的比较，SALT是用于增强哈希函数参数的辅助数据，而HMAC是将哈希函数（和可选的SALT）应用于消息认证码的方法。HMAC适用于具有随机和秘密密钥的情况，而SALT通常是一个随机值，不需要保密。个人而言，他们更倾向于使用SALT和哈希函数。此外，NIST批准的PBKDF2算法使用HMAC作为SALT的目的。openssl_digest和hash函数实际上是做了相同的事情，都是计算了密码的哈希值。因此，如果hash函数不好，那么openssl_digest也不好。此外，HMAC已被证明不会削弱原始哈希函数，而hash(password + salt)则不具备这个特性。因此，专家建议使用Bcrypt来存储密码。