Хранение паролей, которые нельзя хешировать в серверном приложении

Question

У меня есть серверное приложение .NET, которое должно хранить пароли, которые не могут быть хэшированы, потому что некоторые API, которые я использую, нуждаются в паролях в виде простого текста.

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

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

Какой самый безопасный способ сделать это без особых хлопот для пользователя и минимального риска потери данных из-за потерянного / недоступного ключа шифрования?

---

EDIT

Я ищу больше деталей, таких как:

• Как / где хранить ключ
• Генерация уникальный ключ для каждой установки и хранение против приложения в целом общий ключ

... не какой алгоритм шифрования использовать.

---

РЕДАКТИРОВАТЬ II

Я должен добавить, что это приложение будет распространяться среди клиентов для запуска на их собственных серверах. Это клиент / серверное приложение. Сохраненные пароли используются нашим приложением только для передачи во внешние методы API. Мы не используем их ни для чего другого.

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

Answer 1

На самом деле, хорошим способом было бы использовать пароль ввода пользователя в качестве начального числа / ключа для создания более надежного пароля на лету. Многие серверы делают это все время. Это дает вам несколько преимуществ. 1. Никаких хлопот пользователям. 2. Вы можете сохранить пароли пользователей в виде текстового файла. 3. Машинно сгенерированный пароль намного надежнее, чем пароль, предоставленный человеком. 4. Вы можете сгенерировать новый пароль с тем же начальным значением, что сделает ваш протокол более надежным для атак воспроизведения.

Попробуйте.

Answer 2

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

Какой сервер вы используете? Большинство современных RDMBS поставляются с функциями шифрования, которые будут обрабатывать шифрование данных в то время как в состоянии покоя, внешние ключи не нужны. Это, по крайней мере, защитит данные на сервере ...

Answer 3

Ну, если вы просто ищете сильный алгоритм, вы могли бы сделать намного хуже, чем использовать TripleDES. Ему может быть 32 года, но он все еще очень сильный.

Если вы хотите что-то более новое, AES (изначально Rijndael) тоже подойдет.

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

Answer 4

После редактирования, в котором вы описали то, что вы ищете, ниже приведены еще несколько предложений -

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

Таким образом, в любой день генерация уникального ключа - гораздо лучшая идея. Я думаю, вы должны посмотреть на обмен ключами Диффи-Хеллмана. Я думаю, что это решит большинство ваших проблем. Концепция обмена ключами D-H заключается в том, что вы используете свой собственный ключ, предоставленный пользователем, для создания уникального (каждой транзакции) ключа для связи. Лучшая часть этого метода заключается в том, что фактический ключ никогда не раскрывается, и вы можете каждый раз генерировать новые пароли на основе одного и того же старого семени / ключа.

Взгляните на это.

Answer 5

Мы храним информацию о кредитной карте, используя асимметричное шифрование с открытым ключом. Многие серверы имеют открытый ключ, который используется для шифрования кредитных карт при входе. Только у нашего приложения cc gateway есть закрытый ключ для расшифровки и обработки платежей. Закрытый ключ устанавливается как сертификат на производственном сервере.

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

http://en.wikipedia.org/wiki/Public-key_cryptography

Answer 6

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