Скл сервер хранит хеши паролей своих логинов. Вопос - известено ли алгоритм хеширования паролей и его параметры? Цель - надо сделать свою проверку уже существующихешей паролей. Скл 2005, 2008, 2012.

авторизация происходит по имени пользователя. Пароль для двух разных учёток может совпадать.

Я про скл авторизацию, там же есть пароль у учетки, о нем и речь..

А какой смысл делать еще одну проверку ПРАВИЛЬНЫХ хешей по тому же алгоритму хеширования? НЕ правильные же НЕ хранятся.
Может стОит задачу описать поподробнее?

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

а вот подбор пароля под известный хеш представляется легко...

> Цель - надо сделать свою проверку уже существующихешей паролей

вранье и провокация! это называется подбор! и не надо тут нам "ляля"!

> Я про скл авторизацию, там же есть пароль у учетки, о нем
> и речь..


SQL авторизация происходит по имени пользователя. Пароль для двух разных sql-учёток может совпадать.

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

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

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

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

>  чтобы не заставлять всех юзеров перевбивать пароли


Заставлять. И не морочьте голову.

> то мы можем сделать корректную авторизацию.
не сможете...
мелкософт даже свою "sql серверную", не считает правильной (убирает начиная с 2005й версии, "не навязчиво" переводит на виндовую...). что уже говорить о вашей "производной" от неправильной "sql серверной".

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

И все сразу взорвется? И земля остановится?

Или админам можно будет просто сбросить хранимый хеш в нулл?

просто - "весело будет".

хотя, с таким подходом, менять данные прямо в системных таблицах (а для этого дать спец разрешения буквально всем, т.к. при входе с любым и пустым в базе паролем, нужно будет этот пароль менять), базу (а вернее все базы под этим сервером) можно легко "потерять".

кому буквально всем?

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

короче еще думаем заюзить PWDCOMPARE (Transact-SQL), на вход подаем введенный пароль пользователя и хэш который у нас есть сохраненный..

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

нормальная тема для нашей задачки?

а с чего ты вообще решил, что на сервере лежит
hash(открытый пароль)?

вызов функции LOGINPROPERTY ( 'login_name' , PasswordHash ) разве не вернет его?

> а дальше авторизоваться не на сервере, а в приложении.
> Скл сервер хранит хеши паролей своих логинов.

если "в приложении" то нафига знать-привязываться к sql-серверным?

нафига так заморачиваться ради одноразовой смены паролей у юзеров?