В настоящее время я переношу некоторые серверы с MS sql server 2000 на 2008. Некоторые из устаревших приложений защищены паролем, по сути, проверяя, существует ли на сервере пользователь с таким именем и паролем.
Каждое приложение преобразует пароль в верхний регистр перед его отправкой на сервер, но да, как вы уже догадались, пароли на сервере не обязательно хранятся в верхнем регистре: это не было проблемой для 2000 года, но это было в 2008 году (и правильно! ).
В приложениях нет каких-либо умных функций, которые позволяют пользователю изменять свой пароль, и я не хочу просить каждого пользователя изменить свой пароль или изменить приложения, поэтому мне было интересно, возможно ли это для сценария изменить пароли всех пользователей на верхний и как его создать (таблицы для изменения, как изменить хешированные поля и т. д.)?
Вы действительно можете записать пароли из sql server 2000 и импортировать их в sql server 2008, чтобы они распознавались как пароли в верхнем регистре. Вот некоторые фоновое чтение это будет полезно для понимания хэшей паролей сервера sql, поэтому вы можете следовать примеру.
Пароли SQL Server 2000 фактически нечувствительны к регистру, как описано в эта напыщенная речь. Даже в этом случае хэши сервера sql хранят чувствительную к регистру и нечувствительную к регистру копию пароля, поэтому при переносе хэшей паролей на sql server 2005/2008 ваши пароли чувствительны к регистру.
Чтобы проверить это, вы можете запустить на своем SQL Server 2000 Server следующее:
exec sp_addlogin @loginame= 'usera' , @passwd='password'
вход в SQL Server 2000 в качестве пользователя работает с ПАРОЛЕМ, хотя и не должен. Чтобы перенести пользователя на SQL Server 2005/2008, мы можем использовать следующее, чтобы скопировать логин с сохранением хэша sid и пароля:
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 и хешем):
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 в качестве параметра @passwd для процедуры sp_addlogin будет означать, что пароль распознается в верхнем регистре!
Невозможно изменить их существующие пароли, они эффективно зашифрованы локально, но вы можете сбросить их пароли на что-то в верхнем регистре и сообщить им
правильный ответ - исправить устаревшие приложения, чтобы они этого не делали (это соответствует требованиям DailyWTF - намеренное сокращение пространства поиска для взлома методом грубой силы).
надеюсь, у вас есть исходный код, и вы можете это сделать.
если нет, ответ chopper3 будет работать.
К вашему сведению, чувствительность к регистру зависит от сопоставления. Существуют параметры сортировки без учета регистра, которые можно использовать как временное решение.
Вы также можете сделать то, что предлагает Chopper3, потому что вам все равно придется информировать пользователей. Даже если вы можете записать изменение в верхний регистр, это все равно изменение пароля, и пользователям необходимо сообщить об этом.
Проблема в том, что параметр сортировки базы данных, который был у вас в старой базе данных 2000 года, был нечувствителен к регистру, но вы перешли на новую базу данных, где параметр сортировки был чувствителен к регистру. Все, что вам нужно сделать, это изменить настройку сопоставления в свойствах новых баз данных, и тогда имена будут совпадать независимо от регистра.
Ваше приложение было закодировано для ввода паролей в верхнем регистре, потому что разработчики не понимали, что в базе данных 2000 регистр учитывается. Они могли бы легко изменить настройку базы данных 2000 на регистронезависимую, чтобы решить свою проблему, но они, очевидно, предпочли вместо этого "взломать".
Мне интересно, что все, кто отвечает на этот вопрос, идут по тому же наивному пути. Представьте себе все потраченное впустую время в истории из-за того, что разработчики не понимают этой простой проблемы.