Шифрование и дешифрование текстовой информации с применением пароля

Мне кажется вы усложняете, для ограничения пользователей хватит и простеньких операций:

Object.Requisites('LongString').CanGUIWrite = FALSE // Блокируем от изменений!
Object.Requisites("LongString2").CanGUIRead = FALSE // Скрываем из виду!  

Ну и раз пошла такая пьянка:

1. Создаем Реквизиты:

• Строка "Пароль" (String2)
• Строка "Скрытый пароль" (DFAString2)
• Строка для шифрования или что угодно иное (String3)

2. Создаем Действие "OnExecute_ЗадатьПароль"

if Object.Requisites("DFAString2").IsNull
  Object.Requisites("DFAString2").AsString = Object.Requisites("String2").AsString
  MessageBox("Поздравляем!";"Вы назначили новый пароль!")
  Object.Requisites("String3").CanGUIRead = FALSE                 // Скрываем шифруемую строку
  Object.Requisites("String2").AsString = ''                      // Скрываем введенный пароль
  Object.Form.Actions.FindAction("ЗадатьПароль").Visible = FALSE  // Скрываем кнопку
endif

3. Создаем Действие "OnExecute_Дешифровать"

if Assigned(Object.Requisites("DFAString2").Value)
    if Object.Requisites("String2").AsString == Object.Requisites("DFAString2").AsString
        Object.Requisites("String2").AsString = ''
          Object.Requisites("String3").CanGUIRead = TRUE
            Object.Form.Actions.FindAction("ЗадатьПароль").Visible = TRUE
              Object.Requisites("DFAString2").Value = NULL
                MessageBox("Внимание!";"Пароль сброшен!")
    else
      MessageBox("ВНИМАНИЕ!";"Пароль не Верный!!!")
    endif
endif

4. Вносим строки в Форму-карточки-Показ:

if not Object.Requisites("DFAString2").IsNull
       Object.Requisites("String3").CanGUIRead = FALSE
       Object.Requisites("String2").AsString = ''
       Object.Form.Actions.FindAction("ЗадатьПароль").Visible = FALSE
endif

Готово. Теперь выводим поля и кнопки на Форму карточки:

Тестируем:

Жмем "Задать Пароль"

Сохраняем. Закрываем. Открываем вновь:

Пробуем ввести пароль "12345" и дешифровать:

Теперь вводим "123456":

Работа выполнена!

Тарас, если хранить пароль в строковом реквизите карточки документа, то любой пользователь сможет его увидеть, воспользовавшись поиском документов и выведя нужный реквизит в список отображаемых колонок (начиная с версии системы 5.5 или 5.6, точно не помню). Поэтому нужно либо использовать реквизит с типом "текст", либо использовать табличный раздел - такие в окне поиска не отображаются (по крайней мере, пока =))

Вы правы - забить это в таблицу и можно спать спокойно.

Наталья, а какой алгоритм шифрования используется в вашем примере? Насколько оно взломостоек и для чего его можно применять?

Тарас, я очень надеюсь что вы не применяете такое решение в продакшене, ведь с точки зрения безопасности оно смысла не имеет. Вы закрываете реквизит с паролем только из отображения (CanGUIRead), и если тянуть его из АПИ то все данные будут доступны, а значит имея права хотя бы на чтение справочника, злоумышленник может вытянуть все пароли. Даже если спрячете в табличные разделы.

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

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

Тарас, тогда и шифровать смысла нет. Заодно и процессор с памятью не занимать лишний раз. Ну или чтобы не совсем "светиться" - XOR еще никто не отменял. Шутка конечно.

А вообще вводить пользователей в заблуждение это плохо. Они же думают что у них все защищено паролем и никто больше прочитать информацию не сможет. А это не так.

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

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

По поводу алгоритма шифрования раскопал сам, может кому интересно. Согласно справке используется 3DES.

Андрей Посаженников, ну я с этого и начал:

Object.Requisites('LongString').CanGUIWrite = FALSE // Блокируем от изменений!
Object.Requisites("LongString2").CanGUIRead = FALSE // Скрываем из виду!  

Это легко активируется простым вычислением пользователей по Ролям/группам/полномочиям.

CurrentUser = ServiceFactory.GetUserByName(Application.Connection.UserName) 
Admin = ServiceFactory.GetGroupMembers(ServiceFactory.GetGroupByName('Administrators')).Find(CurrentUser)
////////////////////////////////
FinDirectorRole = ServiceFactory.GetRoleMembers(ServiceFactory.GetRoleByName('ФинДиректор'); NIL) 
IsFinDirector = FinDirectorRole.Find(CurrentUser) 
///////////////////////////////
CurrentUser.UserType = utAdministrator

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

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