我目前正在将一些服务器从MS sql server 2000迁移到2008.一些旧版应用程序受到密码保护，主要是检查服务器上是否存在具有该名称和密码的用户。
每个应用程序在将密码发送到服务器之前都会将密码转换为大写，但是，您猜对了，服务器上的密码不一定以大写forms存储：这对于2000年来说并不是问题，而是在2008年（正确的做法！ ）。
这些应用程序没有任何聪明的function，允许用户更改他们的密码，我不希望要求每个用户更改密码或更改应用程序，因此我想知道是否可以为脚本将所有用户密码更改为上限，以及如何创build它（要修改的表，如何修改散列字段等）？
你确实可以从sql server 2000编写脚本，并将它们导入到sql server 2008中，以便它们被识别为大写口令。 这里有一些背景知识 ，将有助于理解SQL Server密码哈希，所以你可以跟随这个例子。
SQL Server 2000的密码实际上是不区分大小写的，正如这个咆哮中所描述的那样。 即使如此，sql服务器哈希存储区分大小写和不区分大小写的密码副本，以便当您将密码哈希迁移到sql server 2005/2008时，您的密码区分大小写。
为了testing这个，你可以在你的SQL Server 2000服务器上运行以下代码：
exec sp_addlogin @loginame= 'usera' , @passwd='password' login到SQL Server 2000作为usera使用“密码”，即使它不应该。 要将usera迁移到SQL Server 2005/2008，我们可以使用以下命令来复制login名，并保留sid＆password hash：
select 'exec sp_addlogin @loginame =''' + [name] + '''' + ', @passwd= ' + master.dbo.fn_varbintohexstr([password]) + ', @sid= ' + master.dbo.fn_varbintohexstr([sid]) + ', @encryptopt = ''skip_encryption_old''' from sysxlogins where name='usera'
您将得到以下输出（当然有不同的sid＆hash）：
exec sp_addlogin @loginame ='usera', @passwd= 0x01004409eb54922c0cd2bedbad754f37afad4053bdadf719ff80c8a8abf5801b813114be6ba0c2c8543b2db77b33, @sid= 0x06cf56eb108a12428712f8b7c66ca1cd, @encryptopt = 'skip_encryption_old'
你可以做的是在导入到2008年之前对密码哈希执行一些“处理”，以便第二个大写散列覆盖区分大小写的散列。 这将意味着你所有的密码都是大写的。 使用上面的密码，你可以执行下面的操作，这是我在t-sql中完成的：
declare @old_passwd char(94) -- original hash from sql server 2000 declare @new_passwd char(94) -- new upper case password for sql server 2008 declare @cs_hash char(40) -- case sentive part declare @ci_hash char(40) -- case insentive part declare @salt char(14) set @old_passwd = '0x01004409EB54922C0CD2BEDBAD754F37AFAD4053BDADF719FF80C8A8ABF5801B813114BE6BA0C2C8543B2DB77B33' set @salt = SUBSTRING(@old_passwd,1,14) set @cs_hash = SUBSTRING(@old_passwd,15,40) -- not used, but here for understanding set @ci_hash = SUBSTRING(@old_passwd,55,40) set @new_passwd = @salt + @ci_hash + @ci_hash SELECT @new_passwd
使用这个@new_password作为sp_addlogin的@passwd参数将意味着密码被识别为大写！
有没有办法改变他们现有的密码，他们是有效的本地encryption，但你可以重置他们的密码大写，并通知他们
正确的答案是修复遗留的应用程序，以便他们不这样做（这符合DailyWTF – 故意减lesssearch空间的暴力破解）。
希望你有源代码，可以做到这一点。
如果没有，chopper3的答案将工作。
仅供参考，区分大小写取决于整理。 有一些大小写不敏感的情况，你可以用它作为解决方法，也许是暂时的。
你可以像Chopper3所build议的那样做，因为你将不得不通知用户。 即使您可以将更改脚本编写为大写，仍然是密码更改，用户需要被告知。
问题是您在旧的2000数据库中的数据库sorting规则设置是不区分大小写的，但您已迁移到sorting规则设置区分大小写的新数据库。 您只需要在新的数据库属性中更改sorting规则设置，然后匹配名称而不考虑大小写。
您的应用程序被编码为密码大写，因为开发人员不了解2000年的数据库区分大小写。 他们可以很容易地将2000年的数据库设置改为不区分大小写来解决他们的问题，但是他们显然select了“破解”它。
我觉得有趣的是，每个人对这个问题的回答都是遵循相同的天真道路。 想象一下，由于开发者不了解这个简单的问题，所有浪费时间的历史。