Проверить пароль пользователя ИБ #598309

Как проверить, совпадает ли некая введенная в поле ввода строка с паролем пользователя ИБ Васи Иванова?

никак

Использование: Только запись. Описание: Тип: Строка. Пароль, используемый при стандартной аутентификации. Доступность: Сервер, толстый клиент, внешнее соединение. ТОЛЬКО ЗАПИСЬ. Объяснить, почему?

Можно только поменять

Без палева так :))

А подключиться по COM ?

имхо единственный вариант

Дык в чем проблема? Метод Этопароль(Строка) возврашающий булево решил бы вопрос. Надо быстро идентифицировать сотрудника на АРМ. Подбежал Вася, решил сделать нечто. Сведения об операции должны быть записаны в РС. Перелогиниваться долго. Было бы просто - выбрал себя в списке справочника Пользователи, быстро вколотил пароль или штрихкод подсунул, и дальше побежал.

Ну так и храни их в базе отдельно. Или OLE.

кого их? пароли?

А зачем для этого пароль? Прибежал Вася, подсунул штрих-код - в РС записалось: "приходил В.Пупкин, сделал ТО-ТО".

Классный метод, как раз для брутфорса :)))

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

Брутфорс на 1С? юморист.

Да

можно. подключаясь по ком

Ну их потом в ИБ как-то записывать надо, пользюк сам уже так просто его не сменит и т.п. Костылей я и сам придумаю... Ладно. Закрываем вопрос.

Учитывая "сложность" большинства паролей - запросто. Подобрать цифровой пароль из 8 цифр(дата рождения или ещё там какая) - в чём проблема?

а не проще прогеру просто заменить его? )

Палево. Поменяешь - назад не вернёшь, а значит не сможешь остаться незамеченным.

Хотя навредить конечно можно - например нагенерить случайных GUID-ов и поставить их вместо паролей ВСЕМ пользователям ))

Устаревшие данные, смотрите свойство СохраняемоеЗначениеПароля, разумеется при наличии прав администратора или в привилегированном режиме.

Однако ж. Когда такое появилось?

+ Тогда энто автору подходит на ура(правда сравнивать придётся хэши)

Хэш строки-то как получить?

И чего? Там хэш. А по какой хэш-функции он вычисляется ты знаешь? Да не мудри ты. Тебе уж 2 раза сказали, подключайся по COM. Дёшево и сердито.

Да ладно. А если вот так:

Думаю, что никак, иначе все становится очень просто, я бы даже сказал ОЧЕНЬ просто :))

+ Мда, хорошая такая дыра в 1С :))

Всё проще, ПользовательИнформационнойБазы.СохраняемоеЗначениеПароля доступно на чтение и запись. Примерно так: И транзакция не нужна...

а с транзакцией не быстрее будет?

Если и будет, то несущественно.

Интересно, а почему и чтение и запись для хеша непонятно?

Там есть подвох. Свойство доступно для пользователя с административными правами.

т.е. с привелигированного модуля (вдруг там будет "Выполнить") не сработает?

Не знаю, попробуй, я 25 минут назад узнал об этой фигне :)

И что? Я так думаю, что это из-за того, что можно менять пароль. Но хеш я думаю хоть и записывается, но вычисляется сам.

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

Без записи пароля, через запись хеша?

Интересный вопрос: хеш для одного и того же пользователя и пароля одинаковый для разных баз?

конечно. Хэшируется-то только строка пароля.

Ну да, конечно. В никсах /etc/shadow так же сделан по идее.

нет, в никсах добавляется соль для каждого хеша случайная.

Чё-т я не понял, если соль случайная - как второй раз хэш вычислять при проверке пароля? :)

Разве из хеша можно получить пароль?

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

соль пишется в /etc/shadow просто, для одного и того же пароля хеш и соль будет всегда разные, заранее набить табличку соответствия ключей хеш и пароль нереально получаеться. Т.е. к тебе попала запись из /etc/shadow брутфорсить надо заново. Вот и мне интерестно, если создать в двух разных базах 1-го пользователя и пароль один и тот же, будет ли совпадать хеши.

Кстати да, интересно. Попробуй.

Кстати, ещё одна причина, по которой Пароль доступен только на запись - он просто не хранится в бд, хранится только хэш.

Все печально - хеш вычисляется только для пароля, не зависит от базы и имени пользователя.   Ну в принципе это и не удивительно, если в 1С для пароля нету зависимости от регистра и больше чем 14 или 10 не отрабатываются. Так что берегите хеши директоров, а то злобные хакеры...

Я вам ещё один секрет открою, там хранится не один хеш, а два. Причём первый рассчитан от пароля приведённого к верхнему регистру, чтобы брутфорс упростить. :)

NWoZK3kTsExUV00Ywo1G5jlUKKs=,NWoZK3kTsExUV00Ywo1G5jlUKKs= - я на 1 баловался. :)

Кстати, не работает :)) Надо так: Пользователя нужно заново в базе искать, иначе хеш старый.

кстати, странная идея у 1С-ников насчет хранения 2-х хешей пароля (приведенного к верхнему регистру).

Почему странная, в 1С пароли регистронезависимые.

ой, бред, согласен странная. Зачем 2 если все равно пароль не зависит от регистра.

Можно легко сделать подмену пароля выбранных юзеров на какой-нить "123" и восстановление на старое значение после входа. Осуществить мечту зловредителей: зайти под недругом и напакостить в базе. К тому же часто пароли хранятся даже не в виде хеша, а в открытом виде в базах с длительной историей. Или пропатчить саму 1С, поскольку клиент проверяет можно ли ему заходить, а не сервер

так и до брутфорса недалеко)

тут вроде sha1, а таблички уже набиты ... какой же тут брутфорса, получил хеш 1С вбил в инете - получил пароль.

таблички набиты для цифр и осмысленных слов

Конструкцию Можно записать в одну строку: ИПравдаВася = ХешВведенногоПароля = ХэшНастоящегоПароля;

Собственно сам подбор можно описать так, может еще кто нибудь подскажет, как улучшить?