Изменение алгоритма шифрования - PullRequest
4 голосов
/ 09 марта 2011

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

Ответы [ 5 ]

4 голосов
/ 11 апреля 2011

Обычно вы бы не зашифровали пароль пользователя, вместо этого вы просто хешировали бы его солью.

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

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

Если у вас уже есть данные, зашифрованные в формате a, и вы хотите начать использовать другую схему шифрования, b, я могу придумать два способа сделать это:

  1. Расшифруйте все ваши данные и повторно зашифруйте их, используя `b`. Этот подход был бы хорош, если вы можете перевести ваше хранилище данных в автономный режим и" исправить все сразу ".
  2. Для каждого элемента, который вы пытаетесь расшифровать, попробуйте сначала расшифровать его, используя `b`.Если это не помогло, расшифруйте его, используя `a`.В следующий раз, когда вы попытаетесь что-то зашифровать, убедитесь, что вы используете `b`. Этот подход можно использовать, когда вы не можете перевести ваше хранилище данных в автономный режим, но хотите зашифровать все свои данные, используя другой алгоритм.В конечном итоге все ваши данные будут зашифрованы с использованием другого алгоритма.
1 голос
/ 18 апреля 2011

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

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

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

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

Самая прямая замена будет по линии PBEWithSHA256And256BitAES. К сожалению, это не поддерживается Java 6, поэтому вам понадобится сторонняя библиотека JCE, такая как Bouncy Castle . Надувной замок предлагает PBEWithSHA256And256BitAES-CBC-BC, который будет подходящей заменой.

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

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

Также может быть целесообразно сохранить список пользователей, которым еще не были преобразованы их данные, чтобы вы могли предложить им преобразовать.

1 голос
/ 16 апреля 2011

вы можете посмотреть ESAPI - java http://code.google.com/p/owasp-esapi-java/

ESAPI 1.4 использовал PBEWithMD5AndDES, но в 2.0 они представили AES

проверить свою почтовую цепочку здесь

Вы можете проверить разницу между двумя реализациями

1 голос
/ 11 апреля 2011

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

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

...