Шифрование/Хеширование незашифрованных паролей в базе данных

• Шифруют использование чего-то как MD5, кодируют его шестнадцатеричной строкой
• , Вам нужна соль; в Вашем случае имя пользователя может использоваться в качестве соли (это должно быть уникально, имя пользователя должно быть самым уникальным доступным значением;-)
• используют поле старого пароля для хранения MD5, но отмечать MD5 (i.e.g "MD5:687A878....") так, чтобы старый (простой текст) и новые пароли (MD5) мог сосуществовать
• , изменяют процедуру входа в систему для проверки против MD5, если существует MD5, и против простого пароля иначе
• изменяют "пароль изменения" и "нового пользователя", функции для создания паролей MD5'ed [только 114]
• теперь можно выполнить пакетное задание преобразования, которое могло бы взять как долго по мере необходимости
• после того, как преобразование было выполнено, удалите поддержку прежней версии

Шаг 1: Добавьте зашифрованное поле к базе данных

Шаг 2: код Изменения так, чтобы, когда пароль изменяется, он обновил оба поля, но входящий в систему все еще, использует старое поле.

Шаг 3: Выполненный сценарий для заполнения всех новых полей.

Шаг 4: код Изменения так, чтобы, входя в систему использование новое поле и изменение паролей прекратили обновлять старое поле.

Шаг 5: Удалите незашифрованные пароли из базы данных.

Это должно позволить Вам выполнять переключение без прерывания конечному пользователю.

Также: Что-то, что я сделал бы, назвать новое поле базы данных чем-то, что абсолютно не связано с паролем как "LastSessionID" или что-то столь же скучное. Тогда вместо того, чтобы удалить поле пароля, просто заполните с хешами случайных данных. Затем если Ваша база данных когда-нибудь ставится под угрозу, они могут потратить все время, они хотят пытаться дешифровать поле "пароля".

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

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

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

Это было проблемой мои несколько недель назад. Мы развертывали большой проект MIS на 975 различных географических положениях, где наше собственное пользовательское учетное хранилище будет использоваться в качестве аутентификатора для различного набора уже реализованных и используемых приложений. Мы уже обеспечили и REST и основанную на SOAP услугу аутентификации, но клиент настоял, чтобы быть в состоянии достигнуть пользовательского учетного хранилища из других приложений только с соединение с БД к представлению только для чтения связанной таблицы или представлению. Вздох... (это очень двойное плохое проектное решение является предметом другого вопроса).

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

Мы назвали его Довольно Безопасными Хешированными Паролями или FSHP короче говоря. Реализованный это в Python, Ruby, PHP5 и выпущенный это к Общественному достоянию. Доступный, чтобы быть использованным, разветвленный, горел или плевал на GitHub на http://github.com/bdd/fshp

, FSHP является соленой, многократно хешированной реализацией хеширования пароля.

Принцип разработки является похожим с спецификация PBKDF1 в RFC 2898 (иначе: PKCS № 5: основанная на пароле Версия 2.0 Спецификации Криптографии.) FSHP позволяет выбирать соленую длину, количество повторений и базовой криптографической хеш-функции среди SHA-1 и SHA-2 (256, 384, 512). Сам определяющий meta префикс в начале каждого вывода делает его портативным при разрешении потребителю для выбора его собственной базовой линии безопасности хранения пароля.

БЕЗОПАСНОСТЬ :

Значение по умолчанию FSHP1 использует 8-байтовые соли с 4 096 повторениями хеширования SHA-256. - 8 байтов солят нападения таблицы радуги рендеринга, непрактичные путем умножения требуемого пространства с 2^64. - 4 096 повторений заставляет атаки перебором быть довольно дорогими. - Нет никаких известных нападений на SHA-256 для нахождения коллизий с вычислительным усилием меньше, чем 2^128 операции во время этого выпуска.

РЕАЛИЗАЦИИ:

• Python: Протестированный с 2.3.5 (w/hashlib), 2.5.1, 2.6.1
• Ruby: Протестированный с 1.8.6
• PHP5: Протестированный с 5.2.6

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

ОСНОВНАЯ ОПЕРАЦИЯ (с Python) :

>>> fsh = fshp.crypt('OrpheanBeholderScryDoubt')
>>> print fsh
{FSHP1|8|4096}GVSUFDAjdh0vBosn1GUhzGLHP7BmkbCZVH/3TQqGIjADXpc+6NCg3g==
>>> fshp.validate('OrpheanBeholderScryDoubt', fsh)
True

НАСТРОЙКА СКЛЕПА:

Позволяют нам ослабить нашу схему хеширования пароля. - Уменьшают соленую длину со значения по умолчанию от 8 до 2. - Уменьшают повторение вокруг со значения по умолчанию от 4096 до 10. - Выбирают FSHP0 с SHA-1 как базовый хеш-алгоритм.

>>> fsh = fshp.crypt('ExecuteOrder66', saltlen=2, rounds=10, variant=0)
>>> print fsh
{FSHP0|2|10}Nge7yRT/vueEGVFPIxcDjiaHQGFQaQ==

Я думаю, что необходимо сделать следующее:

1. Создают новый столбец под названием HASHED_PASSWORD или что-то подобное.
2. Изменяют Ваш код так, чтобы он проверил на оба столбца.
3. Постепенно перемещают пароли от нехешированной таблицы до хешированной. Например, когда пользователь входит в систему, переместите его пароль автоматически в хешированный столбец и удалите нехешированную версию. Все недавно зарегистрированные пользователи хешируют пароли.
4. После закрытия, можно выполнить сценарий, который перемещает n пользователей время
5. , Когда Вы не имеете более нехешированные пароли в запасе, можно удалить столбец старого пароля (Вы не можете быть в состоянии сделать так, зависит от базы данных, которую Вы используете). Кроме того, можно удалить код для обработки старых паролей.
6. Вы сделаны!

Последуйте совет Xan из имения в наличии текущего столбца пароля некоторое время поэтому, если вещи разлагаются, можно откатывать quick-n-easy.

До шифрования Ваших паролей:

• используют соль
• , используют хеш-алгоритм, это предназначено для паролей (т.е., - это медленно )

, Посмотрите Thomas Ptacek Достаточно С Таблицами Радуги: Что Вы Потребность Знать О Схемах Безопасного пароля для некоторых деталей.

РЕДАКТИРОВАНИЕ (2016): используйте Argon2, scrypt, bcrypt, или PBKDF2, в том порядке предпочтения. Используйте столь большой фактор замедления, как выполнимо для Вашей ситуации. Используйте исследуемую существующую реализацию. Удостоверьтесь, что Вы используете надлежащую соль (хотя библиотеки, которыми Вы пользуетесь, должны удостоверяться в этом для Вас).

, Когда Вы хешируете использование паролей , НЕ ИСПОЛЬЗУЮТ ПРОСТОЙ MD5.

Использование PBKDF2, который в основном означает использовать случайную соль, чтобы предотвратить нападения таблицы радуги и выполнить итерации (перефразирование) достаточно раз для замедления хеширования - не так много, что приложение занимает слишком много времени, но достаточно что принуждение скота взломщика большое количество различного пароля заметит

Из документа:

• Выполняют итерации по крайней мере 1 000 раз, предпочтительно более - время Ваша реализация для наблюдения, сколько повторений выполнимо для Вас.
• 8 байтов (64 бита) соли достаточны, и случайное не должно быть безопасным (соль не шифруется, мы не волнуемся, что кто-то предположит его).
• А хороший способ применить соль, когда хеширование должно будет использовать HMAC с Вашим любимым хеш-алгоритмом, с помощью пароля в качестве ключа HMAC и соли как текст для хеширования (см. этот раздел из документа).

реализация В качестве примера в Python, с помощью SHA-256 в качестве безопасного хеша:

РЕДАКТИРОВАНИЕ : как упомянуто Eli Collins это не реализация PBKDF2. Необходимо предпочесть реализации, которые придерживаются стандарта, такой как PassLib.

from hashlib import sha256
from hmac import HMAC
import random

def random_bytes(num_bytes):
  return "".join(chr(random.randrange(256)) for i in xrange(num_bytes))

def pbkdf_sha256(password, salt, iterations):
  result = password
  for i in xrange(iterations):
    result = HMAC(result, salt, sha256).digest() # use HMAC to apply the salt
  return result

NUM_ITERATIONS = 5000
def hash_password(plain_password):
  salt = random_bytes(8) # 64 bits

  hashed_password = pbkdf_sha256(plain_password, salt, NUM_ITERATIONS)

  # return the salt and hashed password, encoded in base64 and split with ","
  return salt.encode("base64").strip() + "," + hashed_password.encode("base64").strip()

def check_password(saved_password_entry, plain_password):
  salt, hashed_password = saved_password_entry.split(",")
  salt = salt.decode("base64")
  hashed_password = hashed_password.decode("base64")

  return hashed_password == pbkdf_sha256(plain_password, salt, NUM_ITERATIONS)

password_entry = hash_password("mysecret")
print password_entry # will print, for example: 8Y1ZO8Y1pi4=,r7Acg5iRiZ/x4QwFLhPMjASESxesoIcdJRSDkqWYfaA=
check_password(password_entry, "mysecret") # returns True

Основная стратегия состоит в том, чтобы использовать ключевую функцию деривации для "хеширования" пароля с небольшим количеством соли. Соль и результат хеша хранятся в базе данных. Когда вводы данных пользователем пароль, соль и их вход хешируются таким же образом и по сравнению с хранимой суммой. Если они соответствуют, пользователь аутентифицируется.

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

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

нападениям Перед вычислением мешают при помощи "криптографической соли". Это - некоторые данные, которые хешируются с паролем. Это не должен быть секрет, это просто должно быть непредсказуемо для данного пароля. Для каждого значения соли взломщику был бы нужен новый словарь. Если Вы используете один байт соли, взломщику нужны 256 копий их словаря, каждый сгенерированный с различной солью. Во-первых, он использовал бы соль для поиска корректный словарь, тогда он будет использовать вывод хеша для поиска применимого пароля. Но что, если Вы добавляете 4 байта? Теперь ему нужны 4 миллиарда копий словарь. При помощи достаточно большой соли устранена атака с подбором по словарю. На практике, 8 - 16 байтов данных из криптографического качественного генератора случайных чисел делает хорошую соль.

С предварительным вычислением от таблицы, взломщик имеет, вычисляют хеш на каждой попытке. Сколько времени это берет, чтобы найти, что пароль теперь зависит полностью от того, сколько времени это берет для хеширования кандидата. Это время увеличено повторением хеш-функции. Повторения числа обычно являются параметром ключевой функции деривации; сегодня, много мобильных устройств использует 10 000 - 20 000 повторений, в то время как сервер мог бы использовать 100,000 или больше. (bcrypt алгоритм использует термин "фактор стоимости", который является логарифмической мерой требуемого времени.)

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

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

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

хешируйте их с md5. это - то, что обычно делается с паролями.

MD5 и SHA1 показали немного слабости (два слова могут привести к тому же хешу), настолько использующий SHA256-SHA512 / повторяющимся хешам рекомендуют хешировать пароль.

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

1. не используют MD5/SHA1
2. , Генерируют хорошую случайную соль (многие crypto библиотеки имеют соленый генератор)
3. , повторяющийся хеш-алгоритм как orip рекомендовал
4. , Гарантируют, что пароли не передаются в простом тексте по проводу

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

Как

ALTER TABLE users ADD COLUMN hashedPassword varbinary(max);
ALTER TABLE users ADD COLUMN salt char(10);
--Generate random salts and update the column, after that
UPDATE users SET hashedPassword = HashBytes('SHA1',salt + '|' + password);

Тогда Вы изменяете код для проверки пароля, с помощью запроса как

SELECT count(*) from users WHERE hashedPassword = 
HashBytes('SHA1',salt + '|' + <password>)

где < пароль> является значением, вводимым пользователем.

Я не специалист по безопасности, но я думаю, что текущая рекомендация состоит в том, чтобы использовать bcrypt/blowfish или вариант SHA-2, не MD5 / SHA1.

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

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

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

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

I would like to suggest one improvement to the great python example posted by Orip. I would redefine the random_bytes function to be:

def random_bytes(num_bytes):
    return os.urandom(num_bytes)

Of course, you would have to import the os module. The os.urandom function provides a random sequence of bytes that can be safely used in cryptographic applications. See the reference help of this function for further details.