LINUX.ORG.RU

История изменений

Исправление n_play, (текущая версия) :

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

Ну в смысле, хеш понятно храним (да не простой md5, а какой-нибудь посерьёзнее, пусть будет sha2),

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

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

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

Или это только защит qwerty паролей которые одинаковые у многих юзеров?

это лишь положительный побочный эффект от соли.

Исходная версия n_play, :

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

Ну в смысле, хеш понятно храним (да не простой md5, а какой-нибудь посерьёзнее, пусть будет sha2),

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

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

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

Или это только защит qwerty паролей которые одинаковые у многих юзеров?

это лишь положительный побочный эффект от соли.