![]() |
#1 |
Участник
|
Шифрование в dax2012
Вопрос не мой, транслирую "как сформировали" (без понимания смысла). Поэтому на уточняющие вопросы могу отвечать с задержкой
![]() Есть массив паролей (несколько десятков тысяч) они лежат в таблице Dax2012. Их нужно зашифровать. Использование стандарта ограничено тем что использование WinAPIServer::cryptProtectData()и WinAPServer::cryptUnprotectData() подразумевает что ключ лежит в реестре на сервере АОС а серверов более 80. То есть необходимо хранить 80 экземпляров зашифрованного пароля для каждого АОС. Вопрос:
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#2 |
Участник
|
Шифровать для чего?
Правильно хранить пароль в виде результата хэш функции. Пользователь вводит пароль к нему применяют хэш функцию и сравнивают с хранимым. В таком случае даже при попадании базы в чужие руки все ок. |
|
![]() |
#3 |
Участник
|
В нашем случае хранение хеш не подойдет, потому что использование хеш предполагает из пароля создать хеш и сравнить его с тем что сохранено.
Мне нужно шифровать - дешифровать. То есть восстанавливать из того что хранится, то что сохраняли. Возможно постановка "хранятся пароли" немного некорректный. Скорее так "хранится некая конфиденциальная информация" |
|
![]() |
#4 |
Участник
|
Ок пусть храниться некая информация.
Мы ее шифруем/расшифровываем с помощью какого то алгоритма А Вопрос где мы собираемся хранить/держать пароли (будет ли их пользователь вводить или как то иначе)? Депонирование ключей нужно ли при этом? |
|
![]() |
#5 |
Участник
|
Добрый день.
Кто та сторона, что должна обладать расшифрованным паролем? Вы рассматривали вариант с использованием сертификатов и открытых/закрытых ключей? |
|
![]() |
#6 |
Участник
|
Если есть пара открытый-закрытый ключ, то можно попользоваться System.Security.Cryptography; наверное
Пример на C# нарыт в интернетах. Вопрос - где надежно хранить закрытый ключ для дешифрования, в ресурс зашивать или в папке, в кторую имеет доступ только учетка AOS - ну такие себе варианты. X++: using System; using System.Security.Cryptography; using System.Text; namespace RSAEncryptionExample { class Program { static void Main(string[] args) { string originalText = "Text to be encrypted"; byte[] encryptedText; // Get the public key from a file string publicKey = File.ReadAllText("publickey.xml"); // Create an instance of the RSA algorithm with the public key RSA rsa = RSA.Create(); rsa.FromXmlString(publicKey); // Encrypt the original text using the RSA algorithm encryptedText = rsa.Encrypt(Encoding.UTF8.GetBytes(originalText), RSAEncryptionPadding.OaepSHA1); Console.WriteLine("Encrypted Text: " + Convert.ToBase64String(encryptedText)); } } } |
|
![]() |
#7 |
Участник
|
Хранить можно как глобальную переменную в рамках сессии. Пользователь ввел пароль и далее живёт пока жива сессия.
|
|
![]() |
#8 |
Участник
|
Цитата:
Даже если самим обменом занимается пакетная задача, то где тогда хранить этот пароль между запусками пакета? |
|
![]() |
#9 |
Участник
|
Ему и не надо: ему надо ввести пароль чтобы получить доступ к табличке в которой зашифрованы данные для доступа к emarsys
Исхожу из того что пароль нельзя в открытом виде хранить в бд |
|
![]() |
#10 |
Участник
|
С регистрацией на сайте беда. Админов поймать невозможно, чтобы ускорить процесс. Поэтому работаю "почтальоном"
![]() ------------------------------- Немного поясню:
Так вот в чем собственно вопрос:
Цитата:
Цитата:
Тут я не могу придумать сценарий когда это понадобится. |
|
![]() |
#11 |
Участник
|
Из самого очевидного: с помощью упомянутого System.Security.Cryptography шифровать по ключу, который суть какой-то параметр БД или ОС под БД (название или вообще отдельное свойство в реестре спрятать). Кроме АОСов и админов, по-хорошему, никто не должен обладать правами чтения такой информации.
|
|
![]() |
#12 |
Участник
|
Хранить данные для доступа в зашифрованном симметричным алгоритмом виде в табличке.
При работе пакета сессия при запуске обращается к сетевому ресурсу (файл в сети с паролем расшифровки), доступ к которому есть только у пользователей группы пакетные задания/АОСы. |
|
![]() |
#13 |
Участник
|
Или вообще замахнуться на WEB службу управления такими паролями.
То есть, установка и чтение только через WEB службу, а она пусть использует тот же System.Security.Cryptography добившись, что работать будет на одном сервере. Но тут беда - сломался этот уникальный сервер и остались без паролей. Последний раз редактировалось Raven Melancholic; 13.02.2023 в 17:48. |
|
![]() |
#14 |
NavAx
|
Если в DAX2012 есть таблицы CreditCard*, то там можно найти простой вариант шифрования.
|
|
![]() |
#15 |
Участник
|
Цитата:
Цитата:
Здесь Kerebros так и просится в качестве хранилища аутентификационных данных и инструмента для валидации. Последний раз редактировалось Товарищ ♂uatr; 14.02.2023 в 12:08. |
|
![]() |
#16 |
Участник
|
Цитата:
Сообщение от Владимир Максимов
![]()
Так вот в чем собственно вопрос:
|
|
|
За это сообщение автора поблагодарили: Logger (3), LETTO (1), raz (10), S.Kuskov (10), sukhanchik (15), fed (10). |
![]() |
#17 |
Участник
|
|
|
![]() |
#18 |
Участник
|
Требовать каждый раз ПИН или еще что - это одна из опций защиты закрытого ключа, которая имеет смысл, скажем, для клиент-банка. В общем же случае никаких ПИНов не требуется, доступ определяется обычными ACL, как и к файлам на диске. По описанным выше принципам настроено использование сертификатов в D365FO и не только: импортируете с закрытым ключом в cert:\LocalMachine\My, раздаете права доступа на закрытый ключ учеткам или их группам - и готово. Посмотрите, как работают те же SSL-сертификаты. Дали доступ к закрытому ключу, указали отпечаток сертификата в настройках (чтобы приложение знало, какой сертификат грузить) - и готово, никто ж не вводит никакие ПИНы при перезапуске веб-серверов, или того же SQL Server, или любой другой службы, которая умеет использовать SSL-сертификаты.
|
|
![]() |
#19 |
Участник
|
Ребят, я за рулем, на всякий случай ещё этот вариант рассмотрите https://ru.wikipedia.org/wiki/MTProto
|
|
![]() |
#20 |
Участник
|
Позже будут подробности
|
|
|
|