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


ArtemijeKA

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

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

password_verify(
    'password',
    '$2y$10$Ot7AIHSuyDo13Kj6fl2ZOOc7fVCX6fmWx11H6qZQE/J4SLwpN.qQ6'
)
ivashkevich

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

ArtemijeKA

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

ivashkevich

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

Clawson

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

ivashkevich

Пожалуйста)

vtolstov

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

ivashkevich

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

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

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

vtolstov

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

ivashkevich

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

vtolstov

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

ivashkevich

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

Курс программирования на PHP
Подготовка до уровня устройства на работу!
Начать бесплатно
Логические задачи с собеседований