Здравствуйте, я начинаю разбираться в программировании на платформе "1С:Предприятие 8.3", мой вопрос может показаться глупым, знаний у меня немного... Интересует способ решения следующего момента: насколько удалось мне узнать, что пароль в 1С 8.3 хранится в виде хэша по алгоритму SHA-1, что сейчас уже небезопасно. Я занимаюсь самописной ИС на файловой информационной базе, и возможно ли сделать свою обработку создания пароля для пользователей, которые хэшировались бы более надежными функциями, например, MD5, SHA256? Только удалось найти, что есть функция ХешированиеДанных(), которая реализует расчет хеш-сумм. Но интересует обработка пароля, задаваемого пользователем, его хэширование MD5 или SHA256 и хранение этого хэша (особенно интересует как его хранить и куда записывать в файловой базе). Подскажите, пожалуйста, как это реализовать и возможно ли? Буду очень благодарна за помощь.

(0) MD5 надежнее SHA-1 ? Поржал чо

Жил на свете рыцарь бедный
Молчаливый и простой
С виду сумрачный и бледный
Духом смелый и прямой.

Он имел одно виденье
Непостижное уму,
И глубоко впечатленье
В сердце врезалось ему.

Полон искренней любовью,
Верен сладостной мечте
«Ave Mater Dei» кровью
Начертал он на щите.

(0) Есть очень хорошая книга - "прикладная криптография" Брюс Шнайдер. Рекомендую.

я совсем не понимаю в программировании
я занимаюсь разработкой ИС
я занимаюсь шифрованием
как то все это не вяжется

(0) Преподы импортозамещаются?
Вы там им скажите, что 1С - немного про другое.

(0) В какой модели угроз это имеет смысл?
Если зловред то имеет доступ к SQL - то алгоритм хеширования пароля это самое последнее что должно волновать

(4) Да, занимаюсь этим в рамках дипломного проекта, изучаю, разрабатываю ИС, что не вяжется то?) Или вы начинали свой путь сразу с уровня Гуру программирования?

(7) Ну вот если вы занимаетесть шифрованием и разработкой угроз - скажите мне в какой модели угроз это имеет ссмысл?

(8) Чего вы добьетесь изменением алгоритма шифрования пароля?
Ну помимо мнимой уверенности что что то станет надежнее

(8) Я еще раз вам говорю, я студент, моя ИС это лишь дипломный проект, который не претендует на уровень реальной работы в организации. Я не занимаюсь шифрованием или разработкой угроз. Мне просто нужна была информация по этому поводу, чтобы когда у меня спросили почему я не использовала более надежное шифрование, то смогла ответить на этот вопрос. Раз это не нужно и не возможно без исходных кодов, то вопрос закрыт.

(1) "В особенности после 2005 года существует множество различных атак на алгоритм SHA1. Первый публичные коллизиии опубликованы в 2017 году, и после этого SHA1 не считается безопасным."

(10) ответ простой.
Алгоритм шифрования поставляется плтаформой и изменен быть не может.
Если зловред имеет ФИЗИЧЕСКИЙ доступ к файлу 1cd - то алгоритм шифрования пароля не имеет никакого значения.
Если не имеет - то внезапно тоже.

Если нужны особые требования к безопасности - в платформе реализована возможность подключить 2ой фактор (12)

(12) Спасибо. Уже выяснила что не может быть изменен. Но мой вопрос был изначально мотивирован логикой, что SHA-1 сейчас признан небезопасным и замен группами SHA-2, SHA-3. Если бы возможно было это просто переписать, то почему нет. Есть небольшой опыт работы с языками программирования, где это очень просто все делалось и заносилось в базу, но 1C отдельный случай. Ладно. Меня наоборот устраивает, что это не получится переписать, меньше работы :)

(14) ну хеш пароля вы можете узнать 2 мя способами - сниффануть траффик или имея прямой доступ к sql/1cd
Первое лечится шифрованным траффиком, второе нормальной настройкой прав.
Иных способов на клиентской части получить хеш ИИ скомпрометировать его я не знаю, соответственно хранение паролей в извращенном виде ну видится не так приоритетным вендору, всё же там не совсем олени сидят

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

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

(15) >  2 мя способами - сниффануть траффик или имея прямой доступ к sql/1cd
Внезпный СП:

ПользовательИнформационнойБазы
    СохраняемоеЗначениеПароля

Использование:
    Чтение и запись.
Описание:
    Тип: Строка.

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

Доступность:
    Сервер, толстый клиент, внешнее соединение.

Примечание:
    Назначается пользователю только в процессе его записи в базу данных на сервере 1С:Предприятия. Доступно только пользователю с административными правами.

Использование в версии:
    Доступен, начиная с версии 8.2.

(14)
>Если бы возможно было это просто переписать, то почему нет.
https://v8.1c.ru/platforma/openid-connect-autentifikatsiya/
https://v8.1c.ru/platforma/openid-autentifikatsiya/

(15)
>хеш пароля вы можете узнать 2 мя способами - сниффануть траффик
>лечится шифрованным траффиком

Ну в рамках дипломной работы это как раз и можно оформить как соответствующую модель угроз. Либо работа в принципиально незащищенном режиме (веб-клиент по хттп, техническая возможность для хттпс отсутствует), либо в небезопасной среде передачи, где существует постоянная угроза MitM и, соответственно, нужно либо асимметричное шифрование (1с умеет ли такое, интересно), либо вот хэширование усложнять, хотя конечно всё равно не очень понятно зачем, но для студентов и преподов сойдёт, кмк, там-то как правило как раз-таки «совсем олени сидят», как вы выразились.

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

(17) Именно.
Я про то что сколько работал в том числе и в банке - особо в БД никто не упарывался именно какими то сложными хешированиями паролей на стороне БД, так как вводимое значение и его преобразования идут на клиенте и узнать чем и как кешируется - дело техники для того кому это действительно нужно.
Очень упарывались именно на безопасности БД и канале.

(21) Тут важнее другое. Знание хэша никак не помогает пройти аутентификацию.

(0) Значение Хэша пароля пользователя в 1С рассчитывается по следующему алгоритму:
        ХешированиеДанных = Новый ХешированиеДанных(ХешФункция.SHA1);
    ХешированиеДанных.Добавить(Пароль);
        
    СохраняемоеЗначениеПароля = Base64Строка(ХешированиеДанных.ХешСумма);
        
    ХешированиеДанных = Новый ХешированиеДанных(ХешФункция.SHA1);
    ХешированиеДанных.Добавить(ВРег(Пароль));
        
    СохраняемоеЗначениеПароля = СохраняемоеЗначениеПароля + ","+ Base64Строка(ХешированиеДанных.ХешСумма);

Установка пароля в базу данных, выполняется через запись свойства пользователя "СохраняемоеЗначениеПароля".
Запись осуществляется в таблицу БД "V8USERS". Для записи пользователя необходимо право "Администрирование".
Поменять алгоритм хэширования пароля нельзя, так как он "зашит" в платформу.
Т.е. хэш ослаблен использованием ВРег, поэтому простые пороли легко брутфорсятся. Если есть физический доступ к БД или 1CD (для файловой базы) или есть доступ в базу под пользователем с правом Администрирование, можно легко поменять пароль на пустой (2jmj7l5rSw0yVb/vlWAYkK/YBwk=,2jmj7l5rSw0yVb/vlWAYkK/YBwk=). Таким образом работает механизм снятия пароля с использованием TOOL_1CD.

На самом деле,независимо от функции хэширования,есть только один способ получения значения - это перебор.
Конечно,наличие таблиц - это значительное ускорение перебора,но принципиально ничем от него не отличается.

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

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

Тут другое - sha256 вычисляется на аппаратном уровне,т.к.оно требовалось во многих алгоритмах шифрования и проверки подлинности,и может оказаться,что перебор будет даже быстрее,чем sha1,который 128.

Кроме того,для коротких паролей есть есть возможность обратного шага хэширования,так как там буфер из 256 бит,и это 32 байта или 16 символов и всего-то 80 циклов.

(25) SHA1 тоже аппаратное
https://en.wikipedia.org/wiki/Intel_SHA_extensions

Я md5,sha1 и sha256 на vbscript писал - тогда еще аппаратного не было.