如果我的数据库往里表所示：
userid uniqueidentifier
username varchar(20)
password varbinary(max)
当用户提交（注册），I发送用户/传递到存储过程。
该存储过程创建一个新的GUID（使用NEWID（） ），那么我用HASHBYTES的SQL Server（SHA1）函数来创建基于提供的话，我值插入到表上方的GUID +的密码。
当用户提交（登录），I发送用户/传递到存储过程。
该存储过程寻找的用户名和抢用户ID，以GUID +密码的hashbyte（SHA1）与密码字段进行比较。
你看到里面的逻辑缺陷任何？
这是相当标准 - 一个GUID将罚款盐。 盐的点是为了防止彩虹攻击 ，和几乎这是随机的（或者即使不是随机的，那么至少是，不同的），为每个用户会做的伎俩任意值。
如果安全是首要关注的问题，我宁可不使用GUID的盐值。
的GUID有不同的“类型”，有些是比别人更多的“随机”。 然而，即使GUID最好的类型（这将是V4型GUID从“随机性”的角度来看的）是不是真的适合加密功能。
从上GUID的维基百科文章 ：
V4的GUID使用后的算法，这是一个伪随机数。 这些具有“4”在同一位置，例如{38a52be4-9352-453e-af97-5c3b448652f0}。 更具体地，“DATA3”的位模式将是0001xxxxxxxxxxxx在第一种情况下，和在0100xxxxxxxxxxxx第二。 所述WinAPI的GUID发生器的安全性分析表明，由于V4的GUID的序列是伪随机的，给出的初始状态可以预测到由函数UuidCreate返回下一个250点000的GUID。 这就是为什么的GUID不应该在密码使用，例如，作为随机密钥。
作为形容，目前尚不清楚该机制的工作原理-我假设userid字段包含生成的GUID（否则我看不出你如何找回它进行比较）。
有不同类型的GUID的 ，不是所有的人随机的。 不过呢，是不是真的需要密码腌制随机性。 总而言之，你的方法看起来不错，但不妨考虑执行散列多次（ “重点强化” ），以进一步提高安全性。
克雷格斯顿茨注意，你不应该试图做你自己的密码。 盐的defition是在这里 。 因为它说，这应该是随机的，您的GUID可能不是随机的，因此，你可能有信息leekage，降低安全性。 话虽这么说，这取决于你有多少安全性要为你的系统。 如果这不是一个大的应用程序，那么你可以逃脱当前系统。
你为什么要重新发明登录时，你不明白的随机数 ？
更新基于来自评论问题的新的细节。 对于Windows GUI应用程序与SQL Server对话，我的身份验证选择，将开始：
