Использование асимметричного шифрования для защиты паролей - PullRequest
0 голосов
/ 08 августа 2011

В соответствии с требованиями наших клиентов пароли пользователей должны храниться в некоторой «читаемой» форме, чтобы можно было конвертировать учетные записи позднее. К сожалению, просто сохранить хеш-значения и сравнить их при аутентификации здесь не вариант. Хранение простых паролей в базе данных, конечно, тоже не вариант, но можно использовать такую ​​схему шифрования, как AES. Но в этом случае ключ для расшифровки паролей должен был бы храниться в системе, выполняющей аутентификацию, и мне это не совсем удобно.

В надежде получить «лучшее из обоих миров», моя реализация теперь использует RSA асимметричное шифрование для защиты паролей. Пароли засолены и зашифрованы с использованием открытого ключа. Я отключил любые дополнительные, внутренние механизмы соления или набивки. Зашифрованный пароль будет всегда один и тот же, как хешированный пароль MD5 или SHA1. Таким образом, системе аутентификации нужен только открытый ключ. Закрытый ключ не требуется.

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

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

Заранее большое спасибо!

-

Обновление: В ответ на приведенные ниже аргументы Джека я хотел бы добавить соответствующие подробности реализации нашей функции хеширования на основе RSA:

Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());
Cipher rsa = Cipher.getInstance("RSA/None/NoPadding");
rsa.init(Cipher.ENCRYPT_MODE, publicKey);
byte[] cryptRaw = rsa.doFinal(saltedPassword.getBytes());

Быстро пролистав документ, упомянутый Джеком, я думаю, что немного понимаю важность предварительной обработки, такой как OAEP. Хорошо ли было бы расширить мой исходный вопрос и спросить, есть ли способ применить необходимую предварительную обработку и при этом иметь функцию, возвращающую один и тот же выход каждый раз для каждого входа, как это делает обычная функция хеширования? Я бы принял ответ на этот «бонусный вопрос» здесь. (Или я должен задать этот отдельный вопрос по SOF?)

-

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

Ответы [ 5 ]

2 голосов
/ 10 августа 2011

Я добавляю это как другой ответ, потому что вместо ответа на заданный вопрос (как я сделал в первом ответе) это обходное / альтернативное предложение.

Проще говоря:

Используйте хеши, НО, всякий раз, когда пользователь меняет свой пароль, также используйте ваш открытый ключ следующим образом:

  • Создайте случайный симметричный ключ и используйте его для шифрования метки времени, идентификатора пользователя и нового пароля.
    • Временная метка предназначена для того, чтобы вы не запутались позже при попытке найти текущий / самый актуальный пароль.
    • Имя пользователя, чтобы вы знали, с каким аккаунтом вы имеете дело.
    • Пароль, потому что это требование.
  • Сохранить зашифрованный текст.
  • Зашифруйте симметричный ключ с помощью вашего открытого ключа.
  • Хранить зашифрованный симметричный ключ с открытым ключом вместе с зашифрованным текстом.
  • Уничтожить симметричный ключ открытого текста, оставив только зашифрованный ключ с открытым ключом.

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

  • Используя личный ключ, расшифруйте симметричный ключ.
  • Используя симметричный ключ, расшифруйте запись.
  • Если у вас уже есть запись для этого пользователя, сравните отметки времени и сохраните самый последний пароль (исключая старый).
  • пена, промыть, повторить.

(Честно говоря, я, вероятно, переусердствовал, зашифровывая временную метку и не оставляя ее открытым текстом, но я параноик и у меня есть кое-что для временных меток. Не заводите меня.)

Поскольку при смене паролей вы используете только открытый ключ, скорость не критична. Кроме того, вам не нужно хранить записи / файлы / данные, где незашифрованный пароль шифруется на сервере, который пользователь использует для аутентификации. Эти данные можно регулярно архивировать или иным образом удалять, поскольку они не требуются для обычных операций (для этого и нужен хеш).

1 голос
/ 08 августа 2011

В вопросе недостаточно информации, чтобы дать разумный ответ.В любом случае, поскольку вы отключаете заполнение, есть большая вероятность, что применима одна из атак, описанных в статье «Почему учебник ElGamal и RSA-шифрование небезопасны» Д. Бонэ, А. Жу и П. Нгуена.

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

0 голосов
/ 10 августа 2011

Один серьезный недостаток, о котором я не упомянул, это скорость.

Симметричное шифрование обычно намного быстрее, чем асимметричное. Обычно это нормально, потому что большинство людей учитывают это в своих разработках (например, SSL использует только асимметричное шифрование для совместного использования симметричного ключа и проверки сертификатов). Вы будете делать асимметричное (медленное) для каждого входа в систему вместо криптографического хеширования (довольно быстрое) или симметричного шифрования (довольно быстрое). Я не знаю, что это повлияет на производительность, но может.

Для сравнения: на моей машине шифрование AES симметричным потоковым шифром (aes-128 cbc) дает до 188255 КБ / с. Это много паролей. На той же машине пиковая производительность для сигнатур в секунду (возможно, наиболее близкая к предполагаемой операции) при использовании DSA с 512-битным ключом (больше не используется для подписи ключей SSL) составляет 8916,2 операций в секунду. Это различие (примерно) в тысячу раз при условии, что подписи использовали контрольные суммы размера MD5. Три порядка величины.

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

Если у вас есть криптографические алгоритмы, которые вы бы предпочли использовать или сравнить, и вы хотите сравнить их в своей системе, я предлагаю команду 'openssl speed' для систем, в которых есть сборки openssl.

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

0 голосов
/ 08 августа 2011

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

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

0 голосов
/ 08 августа 2011

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

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

...