如果我的数据库内的表如下所示：
userid uniqueidentifier
username varchar(20)
password varbinary(max)
当用户提交（注册）时，我将用户/通行证发送到存储过程。
存储过程创建一个新的 GUID（使用 NEWID()）然后我使用 HashBytes(sha1 ）SQL Server 函数根据提供的 GUID+密码创建密码，然后将值插入到上表中。
当用户提交（登录）时，我将用户/密码发送到存储过程。
存储过程查找用户名并获取用户 ID，将 guid+密码的 hashbyte(sha1) 与密码字段进行比较。
你认为这个逻辑有什么缺陷吗？
If my table inside the database look like:
userid uniqueidentifier
username varchar(20)
password varbinary(max)
When the user submit(to register), I send the user/pass to a stored procedure.
The stored procedure create a new GUID(Using NEWID()) then I use the HashBytes(sha1) function of SQL Server to create the password based on the GUID+password provided then I insert the values into the table above.
When the user submit(to login), I send the user/pass to a stored procedure.
The stored procedure look for the username and grab the userid to compare the hashbyte(sha1) of guid+password with the password field.
do you see any flaw inside that logic?
发布评论
评论（5）
这是相当标准的——一个指南对于盐来说就可以了。 盐的目的是防止Rainbow 攻击，以及几乎任何随机值（甚至是如果不是随机的，那么至少对于每个用户来说都是不同的。
That's pretty standard - a guid would be fine for a salt. The point of a salt is to prevent Rainbow attacks, and pretty much any value that's random (or even if not random, then at the very least, different) for each user will do the trick.
如果安全性是首要考虑因素，我宁愿不使用 GUID 作为盐值。
GUID 有不同的“类型”，其中一些比其他的更“随机”。 然而，即使是最好的 GUID 类型（从“随机性”角度来看，这将是 V4 类型的 GUID）也不真正适合加密功能。
来自 关于 GUID 的维基百科文章：
If security is the primary concern, I'd rather NOT use a GUID for the salt value.
GUID's come in different "types", with some being more "random" than others. However, even the best type of GUID (this would be V4-type GUID's from a "randomness" perspective) are not really suitable for cryptographic functions.
From the Wikipedia article on GUID's:
正如所描述的，尚不清楚该机制是如何工作的 - 我假设
userid字段包含生成的 GUID（否则我看不到如何检索它以进行比较）。有不同的 GUID 类型，并非所有类型都是随机的。 但是，密码加盐并不真正需要随机性。 总而言之，您的方法看起来不错，尽管您可能会考虑多次执行散列（“密钥强化”< /a>) 进一步提高安全性。
As describe, it's not clear how the mechanism works - I assume the
useridfield contains the generated GUID (otherwise I don't see how you retrieve it for comparison).There are different types of GUID, not all of them random. But then, randomness is not really required for password salting. All in all, your approach looks fine, though you might consider performing the hashing multiple times ("key strengthening") to improve security further.
正如 Craig Stuntz 指出的那样，你不应该尝试自己进行加密。 salt 的定义位于此处。 正如它所说，这应该是随机的，而您的 GUID 可能不是随机的，因此您可能会出现信息泄漏，并降低安全性。 话虽如此，这取决于您想要系统的安全程度。 如果这不是一个大型应用程序，那么您也许可以使用当前的系统。
As Craig Stuntz noted, you should not be trying to do crypto on your own. The defition of salt is here. As it says, this should be random, and your GUID may not be random, and therefore you may have information leekage, and decreased security. That being said, it depends on how much security you want for your system. If this is not a large application, then you may be able to get away with your current system.
当你不理解 nonce 时，为什么要重新发明登录？
根据评论中问题的新细节进行更新。 对于与 SQL Server 通信的 Windows GUI 应用程序，我的身份验证选择将从：
Why are you re-inventing login when you don't understand nonces?
Update based on new details of question from comments. For a Windows GUI app talking to SQL Server, my authentication choices would start with: