1с v8.1
УТ 10.2 ( но это не важно )

Допустим я программно открываю форму обработки и задаю пользователя и его пароль в полях формы :

ФормаОбр.ПользовательИнформационнойБазыДляПодключения   = "Федоров";
ФормаОбр.ПарольИнформационнойБазыДляПодключения  = "123";


Смысл сокрытия пароля - не столько скрыть его от следующего 1С-ника , а скорее от пользователей , у которых есть право доступа в базу ( от этого не деться ).
И вообще с точки зрения безопасности - не правильно указывать в коде пароль.

Как скрыть пароль ?

Ну а что делать, если я, например, на фтп выкладываю... пароль в коде.

никак. но послушаю, что ещё люди скажут

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

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

(1) вбс+ком+компиляция может так ?

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

(0) Запароленный текст модуля не катит?

а на модуль поставить защиту!

(6) они все равно вскрываются... но от первичного интереса покатит

говорят что Red Hat в последней версии ядра применило обфускацию участков кода, чтобы его не смогли применить Oracle в своем Oracle Linux

(6) Паролить целиком модуль , чтоб запаролить одно строковое значение ?
Можно , но не изящно.

(0) лучше уж внешнюю компоненту написать

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

(9) они просто не сделали отдельных патчей, а выложили все ядро. Мол кому надо сами выковыривайте (что весьма не просто).

(10) функция изящней

(0) а тупо сделать константу, которая заполняется в пользовательском режиме не катит? В коде не видно, да и поменять при необходимости можно. Сам пороль не отображать.

ну если скрыть только от пользователя и сейчас все равно прописано коде - то константа - форма ввода пароль - в обработке получаешь константу - пользователю не видно а в обработке работает...

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

(15) - :)))

А не проще генерировать случайный пароль перед входом и устанавливать его пользователю?

2(13) ну я вот на это опираюсь:
http://distrowatch.com/weekly.php?issue=20110307

One of the more interesting topics discussed on many Linux websites last week was about Red Hat's new method of "obfuscating" the kernel source code in the recently released Red Hat Enterprise Linux (RHEL) 6. Jonathan Corbet of Linux Weekly News has confirmed that Red Hat's patches are now included in the kernel, rather than shipped separately: "Red Hat is making things harder by shipping its RHEL 6 kernel source as one big tarball, without breaking out the patches. Your editor has downloaded the 2.6.32-71.14.1.el6 source package and verified that this is the case. One of the key points behind the RPM and Debian package formats is that source is shipped in its upstream form, with patches shipped separately and applied at build time. Red Hat has always followed this convention; the failure to do so with the RHEL 6 kernel is a new and discouraging change of behavior." Red Hat has responded to these accusations with a press release in which the company confirms the change: "To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL." While Red Hat does not mention the competitors directly, many analysts, including Cade Metz writing for Channel Register speculate that Oracle and its Oracle Linux, a distribution built from Red Hat's source packages, is the main reason behind the "obfuscation" policy.

ну и похоже одно другому не противоречит

не хранить пароль и имя пользователя, запрашивать при начале работы процесса

Ага. И в табло набрать "Константы.КазалосьБыХренКтоПрочтетЭтуКонстанту.Получить()" :))

(22) ну так то да.... :))

(19) Еще кошернее пароль вообще не использовать, но всегда писать пользователю статус внизу на пару секунд "Проверка пароля..." 8))

(15) При соответствующем ограниченном доступе к самой константе - это одно из решений.

(0) тупо хэш пароля в код забиваешь.
а при запуске проверяешь - но если сам код открыт ничто не мешает закоментировать твою проверку

зашифруй его примитивным алгоритмом, типа как ответы к тестам на ИТС

например так:
   Доступ =Новый COMОбъект("accsess.WSC");    
   ПолученДоступ = Доступ.getaccsess("srv00686","sa");
           СтрокаКоннекта = "Provider=SQLOLEDB;Initial Catalog=billing_exchange;Data Source=" + Доступ.server+ ",uid=" + Доступ.user + ",pwd=" + Доступ.pasword;

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

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

(27) а потом зашифровать примитивный алгоритм шифрования?:))

md5 не предлагать?

(29) А если отладчиком пройтись?

от отладчика, боюсь, не спрячешь...

(28) Вариант.

Напиши что-нить типа
Пароль="123"; а потом далекоооооо справа через кучу пробелов Пароль="321";
:)

(28) а что такое "accsess.WSC" ?

Запускай обработку пакетным батником и никаких проблем.

ну если что самыый тупой алгоритм "шифрования" -
шифр = ЗначениеВСтрокуВнутр(Новый ХранилищеЗначения("этопароль"));

(35) Это вариант?!
Тогда про какое запароливание всего модуля ты говорил?
Делаешь новый общий запароленный модуль, в нем одна процедура, возвращающая пароль.

Фигня всё, кроме мёда. Если есть доступ к отладчику, тогда ничего не спрячете. А если и спрячете, тогда тупо в том месте где требуется проверка напишу = ИСТИНА вместо проверке пароля.

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

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

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

а если серьезно к вопросу подходить, то http://www.aladdin-rd.ru/catalog/hasp/hasp_srm/1c_conf_protection.php

(45) чем не устраивает  то скомпилированный код  на другом языке ? если серъезно

(40) Задачка была - скрыть код из модуля. Выполнена? Выполнена...

(47) ну будет у тебя пароль на другом языке, будет другой инструмент его подглядеть. в (45) идеальный вариант. а если попроще, то использовать учетку домена.

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

(48) софиайс или оле дебагер мало кто пользовать будет в отличае от отладчика 1с

(50)софТайс

(0) авторизация средствами учетки венды ?