LINUX.ORG.RU

Как сегодня хранить пароли пользователь web сервиса в бд?


1

1

Добрый день. Какой способ хэширования паролей актуален на сегодняшний день?

  1. MD5/SHA512(password) - совсем не актуально.
  2. MD5/SHA512(randomSalt + password) - хранить соль рядом с хэшем пароля. Если актуально, то какой размер соли должен быть?
  3. PBKDF2(MD5/SHA512, password, randomSalt, iterationCount=4096, len=256) - какой должен быть размер соли, количество итераций и конечная длинна?
  4. Альтернативы?

В безопасности я полный профан, поэтому и прошу помощи и просвещения от сообщества. Сервис написан на java, если это имеет какое либо значение. Спасибо.

хранить соль рядом с хэшем пароля.

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

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от TDrive

Анонимус утверждает, что идея - гогно.

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

anonymous ()
Ответ на: комментарий от TDrive

Ты не подмешиваешь соль (=энтропию) при вычислении хэш-функции, в чём вся суть соли и состоит.

anonymous ()
Ответ на: комментарий от anonymous

Ты не подмешиваешь соль (=энтропию) при вычислении хэш-функции, в чём вся суть соли и состоит.

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

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от anonymous

У тебя она зависит от пароля. Это фейл.

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

TDrive ★★★★★ ()
Ответ на: комментарий от TDrive

Ок, не понял тебя. Но та реализация, которую ты описал, всё равно уныла.

Если ты тупо будешь втыкать один мд5 в другой, то мне не составит труда тупо брутфорсом его оттуда выпилить. Вариантов всего 33. А дальше у меня чистейший мд5.

anonymous ()
Ответ на: комментарий от anonymous

Если ты тупо будешь втыкать один мд5 в другой, то мне не составит труда тупо брутфорсом его оттуда выпилить. Вариантов всего 33. А дальше у меня чистейший мд5.

врятли кто то лепит 33 символьные пароли, вариантов максимум 20.
Ну а что тебе помешает при брутфорсе добавлять соль к паролям, которая хранилась там же в базе где и сам пароль? И там всего 1 вариан.

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от TDrive

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

TDrive ★★★★★ ()
Последнее исправление: TDrive (всего исправлений: 2)
Ответ на: комментарий от TDrive

Например у тебя есть md5 пароля и есть рандомный md5 - соль, берешь соль и вставляешь в md5 пароля на позицию зависящюю от длинны пароля

Теперь следи за руками. У тебя есть соль - рандомный мд5 длиной в 32 символа (мд5 всегда 32 символа). У тебя есть хэш пароля - 32 символа. Ты тупо втыкаешь соль в хэш пароля. У тебя для этого есть 33 варианта. Получилась фигня длинной в 64 символа.

Теперь прихожу я. У меня давным давно есть радужные таблицы на чистый, не солёный мд5.

Я беру твою фигню длинной 64 символа и по очереди выпиливаю оттуда по 32 символа. Сначала 1-32, потом 2-33, потом 3-34. А то, что осталось, записываю себе в файл. В конце этой операции у меня в файле 33 строки. Одна из этих строк - чистый, не солёный мд5-хэш пароля, который я могу сломать по радужной таблице.

Ну а что тебе помешает при брутфорсе добавлять соль к паролям, которая хранилась там же в базе где и сам пароль? И там всего 1 вариан.

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

anonymous ()
Ответ на: комментарий от TDrive

В общем понятно тогда рандомность хэша пропадает, ты прав.

TDrive ★★★★★ ()
Ответ на: комментарий от TDrive

резонно, тогда почему бы просто не сделать md5(md5(pass))

Потому что радужные таблицы под такой банальный вариант кто-то добрый наверняка уже сгенерировал.

anonymous ()

ничто не мешает узнать соль, воспроизвести засолку, построить таблицы с учетом соли

Более перспективно использовать «криптоконтейнер» на стороне клиента. Реализация не определена т.е. например в качестве такого контейнера может быть персональный ssh-сервер или просто gpg или почта c gpg. В простейшем случае крипто-модуль на js.

peace

anonymous ()
Ответ на: комментарий от anonymous

ничто не мешает узнать соль, воспроизвести засолку, построить таблицы с учетом соли

Это же сколько таблиц придется генерить, если соль у всех пользователей разная?

Deleted ()
Ответ на: комментарий от Deleted

Это же сколько таблиц придется генерить, если соль у всех пользователей разная?

Анонимус имеет мнение, что одну. Но большууую. Чем больше соль, тем больше таблица.

anonymous ()
Ответ на: комментарий от anonymous

Анонимус имеет мнение, что одну. Но большууую. Чем больше соль, тем больше таблица.

Пусть соль будет 100-байтовая. Годится?

Deleted ()
Ответ на: комментарий от Deleted

Соль сложно спрятать и это не является скрываемой частью, её нужно так или иначе знать и обмениваться. В противном случае соль ничем не отличается от пароля.

anonymous ()
Ответ на: комментарий от Deleted

Пусть соль будет 100-байтовая. Годится?

Вероятно будет даже через чур большой. АПВС?

anonymous ()
Ответ на: комментарий от anonymous

обмениваться.

Обмениваться солью? Мы таки в третьем тысячелетии, сейчас нинужно обмениваться солью. Совсем нинужно.

anonymous ()

Какой способ хэширования паролей актуален на сегодняшний день?

scrypt пришел на смену bcrypt. Там и соль, и параметры, и хеш - всё в одной строке.

Сервис написан на java

Если брать scrypt из maven-реп (com.lambdaworks % scrypt % 1.4.0), то там в комплекте нативная либа лежит для ускорения. Но либа слинкована с бородатыми версиями libc/libcrypto, что вызывает рандомный крах даже на несвежих сборках бедиана. Можно этот ускоритель отключить, при запуске проекта дёргая:

System.setProperty("com.lambdaworks.jni.loader", "nil")

shahid ★★★★★ ()

Самное умное в таких вопросах - послать на OWASP. Что и сделал анонимус

vertexua ★★★★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.