Вопросы Теги

Действительно ли возможно изменить все пользовательские пароли на верхний регистр

На каждом сервере можно запросить sysjobs таблицу в msdb. Например:

SELECT job_id, [name] FROM msdb.dbo.sysjobs;
1
задан 7 December 2010 в 17:38
6 ответов

Можно действительно написать сценарий паролей от SQL-сервера 2000 и импортировать их в SQL-сервер 2008 так, чтобы они были распознаны как прописные пароли. Вот некоторое дополнительное чтение, которое будет полезно в понимании хэшей пароля SQL-сервера, таким образом, Вы будете мочь следующее наряду с примером.

Пароли SQL Server 2000 были на самом деле нечувствительны к регистру, как описано в этой напыщенной речи. Несмотря на это, хеши SQL-сервера хранят чувствительную к регистру и нечувствительную к регистру копию пароля, так, чтобы, когда Вы мигрируете, хэши пароля к SQL-серверу 2005/2008 Ваши пароли были затем чувствительны к регистру.

Для проверения этого можно выполнить следование Сервера SQL Server 2000:

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 будет означать, что пароль распознан как верхний регистр!

6
ответ дан 3 December 2019 в 16:20

Нет никакого способа изменить их текущие пароли, они эффективно шифруются локально, но можно изменить их пароли к чему-то в верхнем регистре и сообщить им

2
ответ дан 3 December 2019 в 16:20

корректный ответ должен исправить приложения прежней версии так, чтобы они не делали этого (который имеет право на DailyWTF - сознательно сокращение пространства поиска для трещины грубой силы).

надо надеяться, Вы имеете исходный код и можете сделать это.

в противном случае ответ chopper3 будет работать.

1
ответ дан 3 December 2019 в 16:20
  • 1
    Я знаю, это взяло меня долгое время для понимания то, что продолжалось, i' m, все еще пытаясь удаться, почему! Тем более, что приложения так ограничены в функциональности они don' t действительно должно быть защищено паролем так или иначе (по моему скромному мнению). Я знаю это в конечном счете i' ll должны исправить приложения, но проект состоит в том, чтобы переместить сервер. I' m, просто пытаясь ограничить вещи, в то время как i' m выполнение его. –  Kurut 14 August 2009 в 16:10

Просто к вашему сведению чувствительность к регистру зависит от сопоставления. Существуют нечувствительные к регистру фильтрации, которые Вы могли использовать в качестве обходного решения, возможно, временно.

1
ответ дан 3 December 2019 в 16:20

Можно также сделать, как Chopper3 предполагает, потому что Вы оказываетесь перед необходимостью сообщать пользователям так или иначе. Даже если можно написать сценарий изменения в верхнем регистре, это - все еще изменение пароля, и пользователям нужно сказать об этом.

0
ответ дан 3 December 2019 в 16:20
  • 1
    Нет я wouldn' t, как в данный момент независимо от того, что пользователь входит, преобразовывается в верхний регистр клиентским приложением без пользовательского ведома –  Kurut 14 August 2009 в 13:07
  • 2
    Я понимаю, что но изменяете ли Вы пользовательский пароль на верхний регистр won' t пользователи затем должен знать это, когда они входят в систему сами? –  John Gardeniers 14 August 2009 в 15:17
  • 3
    Хм, я вижу, куда Вы происходите из, но пользователи don' t входят в систему сервера с именем пользователя и паролем, которое они имеют для приложения. О нет у них есть другое имя пользователя и пароль для этого, или они могли использовать известный пароль sa, который им дают в их первый день работы здесь!!! Я чувствую it' s собирающийся быть долгим процессом, получая эту путаницу, в которой разбираются! –  Kurut 14 August 2009 в 16:08

Проблема состоит в том, что сопоставление базы данных, устанавливающее это, которое Вы имели в старой базе данных 2000 года, было нечувствительно к регистру, но Вы мигрировали на новую базу данных, где установка сопоставления была чувствительна к регистру. Все, что необходимо сделать, изменяют настройки сопоставления в Вас более новые свойства баз данных, и затем они будут соответствовать именам независимо от случая.

Ваше приложение было кодировано к Верхнему регистру пароли, потому что разработчики не поняли, что база данных 2000 года была чувствительна к регистру. Они, возможно, легко изменили настройки базы данных 2000 года к нечувствительному к регистру для решения их проблемы, но они, очевидно, приняли решение "взломать" вокруг этого вместо этого.

Я нахожу это интересным, что все, на которые elses отвечают на этот вопрос, следуют за тем же наивным путем. Вообразите все напрасно потраченное время в истории из-за разработчиков, не понимающих эту простую проблему.

0
ответ дан 3 December 2019 в 16:20

Теги

Похожие вопросы