Вопрос по hash, encryption, bcrypt, salt, passwords – Пароли веб-приложений: bcrypt и SHA256 (и scrypt)

13

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

Specific Questions

Does using a integer unique user ID fail as an effective salt? (crypt() uses only 16 bits?)

If I simply run sha256() on a hash over and over until a second is used up does that defeat the brute-force attacks?

If I have to ask these questions should I be using bcrypt?

Discussion/Explanation:

Цель состоит в том, чтобы просто, если хешированные пароли моего пользователя были слиты, они:

would not be "easy" to crack, cracking one password would not expose other users that use the same password).

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

В bcrypt это встроено, и scrypt, если я правильно понимаю, более ориентирован на будущее и включает в себя требование минимального использования памяти.

Но является ли такой же эффективный подход, чтобы «съесть время» путем «перефразирования»? результат sha256 () столько раз, сколько нужно, чтобы использовать несколько секунд и затем сохранить окончательный счетчик циклов с помощью хэша для последующей проверки предоставленного пароля?

Для # 2 важно использовать уникальную соль для каждого пароля. Неясно, насколько случайной (или крупной) должна быть соль. Если цель состоит в том, чтобы избежать всех, кто использует & quot; mypassword & quot; как их пароль от того же хэша, разве недостаточно просто сделать это?

hash = sha256_hex( unique_user_id + user_supplied_password );

или даже это, хотя я не уверен, что он мне что-нибудь купит:

hash = sha256_hex( sha256( unique_user_id ) + user_supplied_password );

Единственное преимущество, которое я вижу от использования идентификатора пользователя, кроме того, что я знаю, что он уникален, - это избегание необходимости сохранять соль вместе с хешем. Не так много преимуществ. Есть ли реальная проблема с использованием идентификатора пользователя в качестве соли? Разве это не достигло # 2?

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

# app_wide_string = one-time generated, random 64 7-bit *character* string.
hash = sha256_hex( unique_user_id + app_wide_string + user_supplied_password );

Я видел, что предложено, но я не понимаю, что я получаю от этого по соли для каждого пользователя. Если бы кто-то хотел перехватить атаку, он бы знал, что & quot; app_wide_string & quot; и использовать это при запуске атаки по словарю, верно?

Есть ли веская причина использовать bcrypt вместо того, чтобы переворачивать мой собственный, как описано выше? Может быть, тот факт, что я задаю эти вопросы, является достаточной причиной?

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

Некоторые связанные ссылки:

использование sha256 в качестве хэширования и посола с идентификатором пользователя

SHA512 против Blowfish и Bcrypt

Какова оптимальная длина для соли пароля пользователя?

Ваш Ответ

2   ответа
0

) uses only 16 bits?)

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

crypt просто хранит соль и хеш в одну строку вместе с алгоритмом для использования.

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

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

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

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

Bcrypt действительно хорошо подходит для сетевых атак, если вы правильно установили коэффициент работы, потому что даже если я получу хэш, то есть, если «противник» получает хеш, рабочий фактор делает действительно болезненным просмотр всего словаря, занимающий несколько дней, и если пароль отсутствует в словаре, то у меня действительно проблемы, потому что атака методом перебора будет эпической, пароль битовое пространство для bcrypt довольно большое, хотя и конечное :)

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

you want the salt to be as large and random as possible using only numbers makes it easier for me to iterate over all the possible ids.
multiple sha256 may take a second now but down the road it won't be effective any more, computers processing power grows exponentially and so you want an algorithm that can be configured as such.
you are doing the right thing by asking questions and doing your homework if more people did this we wouldn't have so many breaches
Благодарю. И в качестве продолжения добавим & quot; всего приложения & quot; Строка (как в моем примере выше) для пароля перед хэшированием обеспечит какую-либо выгоду? Похоже, случайной соли достаточно, правильно? user1446426
в отношении пункта 2: может ли многократно примененный хеш масштабироваться экспоненциально? Я утверждаю, что это возможно, они могут применяться столько, сколько нужно. например, сегодня я применяю ша-512 10 ^ 3 раза. завтра я применю это 10 ^ 4.
в зависимости от энтропии делать атаки в автономном режиме (словарь и грубая сила) становится все труднее, поскольку эти строки найти не удастся, но он ничего не делает для сетевых атак, когда у противника есть как хэш, так и соль, поскольку они имеют быть сохраненным в виде простого текста, для целей проверки, поэтому, если ваша БД или ваши хэши скомпрометированы, то соли не очень полезны, помните, что соли предотвращают автономные атаки, рабочий фактор предотвращают онлайн-атаки, другая проблема заключается в хэш-коллизиях, однако, это довольно низкая встречаемость ... bcrypt с подходящим рабочим фактором должен быть хорошим.
@JanusTroelsen Я не уверен, что вы подразумеваете подpoint 2то, что вы описываете, не может быть применено к пункту 2, так как оно предполагает постоянный коэффициент, учитывая, что я был весьма неоднозначным, что касается увеличения «фактора», вам придется правильно рассчитать его, чтобы соответствовать улучшениям ЦП, даже при использовании bcrypt Вы все еще должны сделать то же самое, но это уже хорошо настроено для этого. В конечном итоге процессоры улучшатся до такой степени, что мы сможем пройти через все битовое пространство, и к тому времени мы выясним что-то еще (надеюсь) ...
Этот ответ является полезным началом, но его можно улучшить, если 1) определить «онлайн». против & quot; в автономном режиме & quot; атаки (как здесь подразумевается - обычно эти термины означают, подключен ли кто-либо к Интернету, но я думаю, что вы имеете в виду что-то еще); 2) объяснение, почему «приложение в целом»; помогает строка (что, я думаю, возможно, только если атака предоставляет доступ к базе данных, но не к коду); 3) каким образом параметр настройки bcrypt легче (или лучше) использовать, чем отдельный параметр, используемый в качестве показателя степени для управления количеством приложений SHA256, согласно комментарию Януса Троелсена.

Похожие вопросы