Шифрование / хеширование паролей в виде обычного текста в базе данных

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

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

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

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

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

При обработке пароля пользователя учитывайте, где происходит хеширование. В моем случае хэш был рассчитан PHP-кодом, запущенным на веб-сервере, но пароль был передан на страницу с пользовательской машины в виде открытого текста! Это было нормально в среде, в которой я работал, так как в любом случае это было внутри системы https (сеть uni). Но в реальном мире я предполагаю, что вы захотите хешировать пароль до того, как он покинет пользовательскую систему, используя javascript и т. Д., А затем передать хеш на свой сайт.

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

При хешировании паролей используйте НЕ ИСПОЛЬЗУЙТЕ ОБЫЧНЫЙ MD5.

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

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

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

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

РЕДАКТИРОВАТЬ: как упоминал Эли Коллинз, это не реализация 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 используется термин «фактор стоимости», который является логарифмической мерой необходимого времени.)

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

Что касается шифрования ваших паролей:

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

См. Статью Томаса Птачека «Достаточно с радужными таблицами: что нужно знать о схемах безопасных паролей» для некоторых Детали.

Думаю, вам следует сделать следующее:

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

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

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

Мы назвали это Fairly Secure Hashed Passwords или сокращенно FSHP. Реализовал его на Python, Ruby, PHP5 и передал в общественное достояние. Доступно для употребления, разветвления, флейма или плевания на GitHub по адресу http://github.com/bdd/fshp

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

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

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

ВНЕДРЕНИЯ:

• Python: протестировано с 2.3.5 (с 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==

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

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

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

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

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

• Зашифруйте, используя что-то вроде MD5, закодируйте его как шестнадцатеричную строку
• Вам нужна соль; в вашем случае имя пользователя может использоваться в качестве соли (оно должно быть уникальным, имя пользователя должно быть самым уникальным доступным значением ;-)
• используйте поле старого пароля для хранения MD5, но пометьте MD5 (например, «MD5: 687A878 ....»), чтобы старый (простой текст) и новый (MD5) пароли могли сосуществовать
• измените процедуру входа в систему, чтобы проверить MD5, если есть MD5, и простой пароль в противном случае
• измените функции «сменить пароль» и «новый пользователь» для создания только паролей MD5
• теперь вы можете запустить пакетное задание преобразования, которое может занять столько времени, сколько необходимо.
• после того, как преобразование было выполнено, удалите устаревшую поддержку

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

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

Шаг 3: Запустите сценарий, чтобы заполнить все новые поля.

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

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

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

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

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

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

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

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

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

Возможно, вам нужно подумать и о полном аудите безопасности.

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

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

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

Я хотел бы предложить одно улучшение отличного примера Python, опубликованного Orip. Я бы переопределил функцию random_bytes следующим образом:

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

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

Для хеширования пароля вы можете использовать функцию 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>)

где ‹password> - это значение, введенное пользователем.

хэшировать их с помощью md5. это то, что обычно делают с паролями.