Как зашифровать пароль в 1С: практическое руководство

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

Принципиально важно понимать: пароли не шифруют в классическом смысле, а хешируют. Шифрование обратимо — зашифрованное значение можно расшифровать ключом. Хеширование необратимо: из хеша восстановить исходный пароль нельзя, можно только вычислить хеш от введенного значения и сравнить его с сохраненным. Именно так работают все современные системы аутентификации, включая саму платформу 1С.

В платформе 1С:Предприятие 8.3 есть встроенные средства криптографии: объект «ХешированиеДанных» с поддержкой алгоритмов MD5, SHA-1, SHA-256 и других, а также менеджер криптографии для шифрования и электронной подписи. Этого достаточно, чтобы реализовать безопасное хранение паролей без внешних компонент.

Когда в 1С вообще нужно работать с паролями

Прежде чем писать код, определите, какая из задач стоит перед вами. Если речь о входе пользователей в информационную базу, платформа делает всё сама: при установке пароля в конфигураторе или через объект ПользовательИнформационнойБазы значение сохраняется в защищенном виде, а при входе выполняется проверка без раскрытия исходного пароля. Вмешиваться в этот механизм не нужно и небезопасно.

Самостоятельная реализация требуется в других случаях: хранение пароля для подключения к FTP, почтовому серверу или API внешнего сервиса; дополнительный пароль на выполнение критичной операции (например, отмена проведения закрытого периода); собственная регистрация пользователей в облачном расширении или мобильном клиенте. Здесь разработчик отвечает за защиту сам.

Третья ситуация — хранение чужих секретов: токенов, ключей API, паролей к сторонним системам, которые 1С должна предъявлять при обмене. Их нельзя хешировать, потому что исходное значение нужно восстанавливать. Для таких данных применяют обратимое шифрование или безопасное хранилище, о чем ниже.

Хеширование пароля через объект ХешированиеДанных

Основной инструмент — встроенный объект ХешированиеДанных. Он принимает данные в виде строки или двоичных данных и возвращает хеш в виде двоичного буфера, который удобно представить в hex-виде для хранения в строковом реквизите.

Базовый пример вычисления хеша SHA-256 от пароля:

Функция ХешПароля(Пароль, Соль)
Хеширование = Новый ХешированиеДанных(ХешФункция.SHA256);
Хеширование.Добавить(Соль + Пароль);
Возврат НРег(ПолучитьHexСтрокуИзБуфераДвоичныхДанных(
Хеширование.ХешСумма));
КонецФункции

Алгоритм выбирается через перечисление ХешФункция: доступны MD5, SHA-1, SHA-256 и другие в зависимости от версии платформы. Для паролей используйте SHA-256: MD5 и SHA-1 считаются устаревшими для защитных задач, так как для них известны коллизии и они быстро перебираются на современном оборудовании.

Результат хеширования — буфер двоичных данных. Чтобы сохранить его в строковом реквизите справочника или регистра сведений, преобразуйте буфер в hex-строку (как в примере) или в Base64 через Base64Строка(). Длина hex-представления SHA-256 — 64 символа, закладывайте реквизит с запасом.

Зачем нужна соль и как ее генерировать

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

Соль не является секретом: ее хранят рядом с хешем в открытом виде. Ее задача — сделать каждый хеш уникальным, а не скрываться. Генерируйте соль криптографически стойким генератором случайных чисел:

Генератор = Новый ГенераторСлучайныхЧисел();
Соль = "";
Для Сч = 1 По 16 Цикл
Соль = Соль + Символ(Генератор.СлучайноеЧисло(33, 126));
КонецЦикла;

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

Проверка введенного пароля

Проверка выполняется без расшифровки: берется сохраненная соль, к ней добавляется введенный пароль, вычисляется хеш и сравнивается с сохраненным. Совпадение означает верный пароль.

Функция ПарольВерен(ВведенныйПароль, СохраненныйХеш, Соль)
Возврат ХешПароля(ВведенныйПароль, Соль) = СохраненныйХеш;
КонецФункции

Типовая схема хранения — регистр сведений или табличная часть с полями «Пользователь», «ХешПароля», «Соль». При смене пароля генерируется новая соль, вычисляется новый хеш, оба значения перезаписываются. Старый хеш удаляется, историю паролей ведите только если это требуется политикой безопасности (например, запрет повторного использования последних паролей).

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

1. 1
   Создайте регистр сведений с полями: пользователь, хеш пароля (строка 64+), соль (строка 36+)
2. 2
   При установке пароля сгенерируйте соль через УникальныйИдентификатор
3. 3
   Вычислите SHA-256 от конкатенации соли и пароля, сохраните hex-строку
4. 4
   При проверке вычислите хеш от введенного значения с той же солью и сравните
5. 5
   При смене пароля пересоздайте соль и хеш, старые значения удалите
6. 6
   Проверьте, что в журнале регистрации и отладке пароль нигде не выводится открытым текстом

Штатная аутентификация платформы и ее ограничения

Если задача — обычный вход пользователей, используйте штатный механизм. Пароль задается в конфигураторе (Администрирование — Пользователи) или программно через объект ПользовательИнформационнойБазы: свойство Пароль доступно только для записи, прочитать его нельзя. Платформа сама хеширует значение и хранит его в базе.

ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоИмени("Иванов");
ПользовательИБ.Пароль = "НовыйПароль123";
ПользовательИБ.Записать();

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

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

Хранение паролей для внешних сервисов

Пароли к почте, FTP, веб-сервисам хешировать нельзя — их нужно предъявлять в исходном виде. Здесь применяется обратимое шифрование. В платформе это делается через МенеджерКриптографии: методы Зашифровать и Расшифровать с сертификатом или паролем.

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

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

Способы защиты паролей в 1С

Хеширование SHA-256 с солью

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

Штатный механизм платформы

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

Обратимое шифрование (МенеджерКриптографии)

Для секретов, которые нужно предъявлять внешним системам. Требует защиты ключа шифрования отдельно от базы.

Хранение вне базы

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

Типичные ошибки и как их избежать

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

Вторая ошибка — использование MD5 или самодельных «алгоритмов» вида сдвига символов и XOR. MD5 перебирается на обычной видеокарте со скоростью миллиардов хешей в секунду, а самодельные схемы вскрываются анализом пары известных значений. Используйте только стандартные алгоритмы из объекта ХешированиеДанных.

Третья группа ошибок — утечки через инфраструктуру: пароль попадает в журнал регистрации через ЗаписьЖурналаРегистрации, выводится в сообщениях об ошибках с параметрами подключения, сохраняется в отладочных файлах обмена. Проверьте все места, где значение может быть записано или показано.

Проверка результата и границы самостоятельной работы

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

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

Контрольные точки

Как проверить результат

Содержимое хранилища паролей

Норма

Только хеши и соли, исходных паролей нет

Тревожный признак

Видны пароли открытым текстом или обратимо закодированные значения

Одинаковые пароли у двух пользователей

Норма

Хеши различаются из-за разной соли

Тревожный признак

Хеши совпадают — соль не используется

Смена пароля

Норма

Меняются и хеш, и соль, старый пароль перестает подходить

Тревожный признак

Соль остается прежней или старый пароль продолжает работать

Журнал регистрации после входа

Норма

Нет значений паролей, только события аутентификации

Тревожный признак

В сообщениях об ошибках видны введенные пароли

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

Частые вопросы

Можно ли узнать пароль пользователя 1С из базы?

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

Чем хеширование отличается от шифрования?

Шифрование обратимо: зашифрованное можно расшифровать ключом. Хеширование необратимо: из хеша пароль не восстанавливается, проверка идет сравнением хешей. Для проверки паролей нужно хеширование, для хранения секретов к внешним системам — шифрование.

Какой алгоритм выбрать в объекте ХешированиеДанных?

Для паролей — SHA-256. MD5 и SHA-1 считаются устаревшими для защитных задач: для них найдены коллизии, а перебор выполняется очень быстро. Разницы в производительности для прикладной задачи проверки пароля вы практически не заметите.

Нужно ли скрывать соль так же, как пароль?

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

Как сохранить пароль к почте или FTP, если его нужно использовать при отправке?

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

Достаточно ли одного хеширования для защиты самописной авторизации?

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