Чат Telegram
Группа ВКонтакте
Новый комментарий


ArtemijeKA 04.09.2018 в 09:11

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

У меня вопрос в этих функциях создается соль автоматически. Допустим я перенесу сайт на другой хостинг где свой интерпритатор php. Не потеряется ли соль на предыдущем хостинге при проверке пароля на новом хостинге но с прежней БД паролей?

password_verify(
    'password',
    '$2y$10$Ot7AIHSuyDo13Kj6fl2ZOOc7fVCX6fmWx11H6qZQE/J4SLwpN.qQ6'
)
ivashkevich 05.09.2018 в 23:27

Не потеряется, она включена в хэш.

ArtemijeKA 06.09.2018 в 16:46

Имею ввиду интерпитатор на новом хостинге не придумает свою соль?

ivashkevich 07.09.2018 в 08:44

При проверке пароля не рассчитывается новая соль в принципе, она просто берется из уже готового хэша.

Clawson 27.08.2019 в 15:59

Интересности ^^ Правда пока начало статьи не особо понял. Надеюсь после завершения обучения пойму что там и как работает. Но статья полезна уже сейчас. Спасибо.

ivashkevich 28.08.2019 в 05:57

Пожалуйста)

vtolstov 02.10.2019 в 10:22

Добавлю, что passwordhash для каждого пароля генерирует уникальную соль. Пошло это с 7 версии php. Однако это все равно дыра в безопасности, если php может понять что там за соль у каждого пароля. В вики написано, что на данный момент заточенное железо может ломать эти пароли. Алгоритму как никак уже 20 лет.
Ждем php 8. Скорей всего алгоритм поменяют.

ivashkevich 03.10.2019 в 00:32

Появилась функция ещё в PHP 5.5. Знание соли - не дыра. Соль - способ защититься от rainbow tables, в которых просто перечислены хэши без соли, для одного пароля каждый раз одинаковые. Соль же позволяет для одного и того же пароля сгенерить разные результирующие хеши, что исключит поиск по хэшу в списке.

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

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

vtolstov 03.10.2019 в 05:29

Ну смотри. Так сказать от сокурсника ))). Есть у нас жертва, у которой мы вытащили хеш пароля. Из него получили соль (так как это простая процедура и даже не важно, что для остальных соль другая). Далее алгоритм начинает перебирать пароли, но не через запрос к базе, а путем генерации радужной таблицы с данной солью. Путь не быстрый, но заточенное железо эту операцию делает достаточно шустро.
Конечно, уже не получится использовать стандартные радужные таблицы для поиска такого пароля из-за уникальной соли, придется генерить свою, что однозначно дольше. Но все равно этот способ проще, чем перебор пароля в лоб.
P.S. Там bcrypt. А можно подключить Argon2id. Вот это реально мощная штука.

ivashkevich 03.10.2019 в 17:29

Построение радужной таблицы под конкретную соль дешевле простого перебора? Я, видимо, не совсем понимаю как они работают)

vtolstov 03.10.2019 в 17:34

Простой перебор втыкает пароль в запрос и получает - ок или не ок и идёт дальше. При радужной таблице, одна машина генерит список хешей, а вторая проверяет на совпадение. Первый вариант по старинке называется «в лоб».
Скорей всего мы об одном и том же, только разными словами )))
p.s. в лоб еще перебирают пароли у архивов.

ivashkevich 03.10.2019 в 17:37

Зачем в запрос втыкать? Есть хэш, есть гипотетически правильный пароль. Просто выполняешь проверку. Про радужные таблицы тоже не понял зачем 2 машины. Параллелить смысла нет - пока таблица не сгенерена, смысл её долбить?

Логические задачи с собеседований