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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> разве не вернет его?
пароль никто и нигде не возвращает... или это не система, а "дырка".

> пароль никто и нигде не возвращает... или это не система,
>  а "дырка".


речь о хеше, а не пароле

За 17,5 часов можно было уже не одной сотне пользователей пароль поменять.
Зачем искать сложное решение, если можно сделать всё просто?

Не, я понимаю, когда пользователей сотни тысяч, там да, надо что-то думать.

> За 17,5 часов можно было уже не одной сотне пользователей
> пароль поменять.
> Зачем искать сложное решение, если можно сделать всё просто?
>
>
> Не, я понимаю, когда пользователей сотни тысяч, там да,
> надо что-то думать.


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

> принуждать всех к смене пароля не хотелось бы

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

> Ega23 ©   (19.02.14 17:35) [22]
> Не, я понимаю, когда пользователей сотни тысяч, там да,
> надо что-то думать.

Угу, вы Легыча слушайте :)))
Я помню че он в прошлый раз придумал, когда апдейт базы думали - а давайте  поменяем пользователям все, зато потом запарки не будет (а у нас их, пользователей, ес че, за 240к :)

> это типовое решение
нет, типовое это пользоваться sql-серверной/виндовой авторизацией, без своих велосипедов требующих лезть в систему с подменами...

т.е. включили/сделали (если не было) виндовую авторизацию, настроили, дали права на группы... пользуетесь стандартным. вот это типовое.
и/или переезжаете на новую базу, перемещаете профили стандартными методами (администрированием)... пользуетесь стандартным. это тоже типовое.
а то что ты тут описал, нет.

> sniknik ©   (19.02.14 22:36) [26]
читайте на мсдн про SQLMemberShipProvider-ы и базы ихние, расширяйте кругозор :)