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

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

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

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

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

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

Достигается это за счёт случайности соли.

У меня она и есть случайная.

bcrypt ;-)

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

У меня она и есть случайная.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

peace

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

md5 от md5 пароля+соль

Вот так: http://php.net/manual/ru/function.password-hash.php

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