"В эти функции уже встроена работа с солью, и она автоматически добавляется в хэш при его создании, и так же извлекается из хэша при сравнении его с введенным паролем."
У меня вопрос в этих функциях создается соль автоматически. Допустим я перенесу сайт на другой хостинг где свой интерпритатор php. Не потеряется ли соль на предыдущем хостинге при проверке пароля на новом хостинге но с прежней БД паролей?
Интересности ^^ Правда пока начало статьи не особо понял. Надеюсь после завершения обучения пойму что там и как работает. Но статья полезна уже сейчас. Спасибо.
Добавлю, что passwordhash для каждого пароля генерирует уникальную соль. Пошло это с 7 версии php. Однако это все равно дыра в безопасности, если php может понять что там за соль у каждого пароля. В вики написано, что на данный момент заточенное железо может ломать эти пароли. Алгоритму как никак уже 20 лет.
Ждем php 8. Скорей всего алгоритм поменяют.
Появилась функция ещё в PHP 5.5. Знание соли - не дыра. Соль - способ защититься от rainbow tables, в которых просто перечислены хэши без соли, для одного пароля каждый раз одинаковые. Соль же позволяет для одного и того же пароля сгенерить разные результирующие хеши, что исключит поиск по хэшу в списке.
Остаётся только перебор. И конкретно алгоритм mcrypt, используемый на данный момент этой функцией - надежный, так как проверка по этому алгоритму достаточно трудоёмкая.
Простой пароль подберется, конечно, быстро. Но это не проблема алгоритма, а проблема того, кто этот пароль использует. И вот это уже дыра.
Ну смотри. Так сказать от сокурсника ))). Есть у нас жертва, у которой мы вытащили хеш пароля. Из него получили соль (так как это простая процедура и даже не важно, что для остальных соль другая). Далее алгоритм начинает перебирать пароли, но не через запрос к базе, а путем генерации радужной таблицы с данной солью. Путь не быстрый, но заточенное железо эту операцию делает достаточно шустро.
Конечно, уже не получится использовать стандартные радужные таблицы для поиска такого пароля из-за уникальной соли, придется генерить свою, что однозначно дольше. Но все равно этот способ проще, чем перебор пароля в лоб.
P.S. Там bcrypt. А можно подключить Argon2id. Вот это реально мощная штука.
Простой перебор втыкает пароль в запрос и получает - ок или не ок и идёт дальше. При радужной таблице, одна машина генерит список хешей, а вторая проверяет на совпадение. Первый вариант по старинке называется «в лоб».
Скорей всего мы об одном и том же, только разными словами )))
p.s. в лоб еще перебирают пароли у архивов.
Зачем в запрос втыкать? Есть хэш, есть гипотетически правильный пароль. Просто выполняешь проверку. Про радужные таблицы тоже не понял зачем 2 машины. Параллелить смысла нет - пока таблица не сгенерена, смысл её долбить?
В данной статье мы поговорим о хэшировании. Данная процедура подразумевает под собой одностороннее шифрование, после которого из получившегося значения невозможно восстановить исходное.
Хэширование - это не шифрование!!! Термин "шифрование" подразумевает возможность расшифровки, а хэширование - необратимо. Правильнее написать "необратимое преобразование данных". Wiki
Попадался на просторах интернета самописный скрипт букса. Как-то допиливая его под себя обнаружил существенную дыру то ли случайно, то ли нарочно оставленную разработчиком. Смысл бага в следующем. Пользователи могут загружать картинку фона или аватара, при этом проверка типа файла выполнялась на странице на уровне JS, а вот php файле, к которому шло обращение через JQuery, такой проверки не было реализовано, только на размер. В итоге можно было создать простую форму с POST запросом прямо к этому php файлу и отправить на сервер свой файл. А дальше полное управление как вы понимаете.
Ух, хорошо что прочитал статью после того как настроил отправку писем на хостинге, а файл с настройками оказался залит в github. После прочтения сразу гитигнор настроил и удалил файлы важные файлы из гита:) Спасибо!
"В эти функции уже встроена работа с солью, и она автоматически добавляется в хэш при его создании, и так же извлекается из хэша при сравнении его с введенным паролем."
У меня вопрос в этих функциях создается соль автоматически. Допустим я перенесу сайт на другой хостинг где свой интерпритатор php. Не потеряется ли соль на предыдущем хостинге при проверке пароля на новом хостинге но с прежней БД паролей?
Не потеряется, она включена в хэш.
Имею ввиду интерпитатор на новом хостинге не придумает свою соль?
При проверке пароля не рассчитывается новая соль в принципе, она просто берется из уже готового хэша.
Интересности ^^ Правда пока начало статьи не особо понял. Надеюсь после завершения обучения пойму что там и как работает. Но статья полезна уже сейчас. Спасибо.
Пожалуйста)
Добавлю, что passwordhash для каждого пароля генерирует уникальную соль. Пошло это с 7 версии php. Однако это все равно дыра в безопасности, если php может понять что там за соль у каждого пароля. В вики написано, что на данный момент заточенное железо может ломать эти пароли. Алгоритму как никак уже 20 лет.
Ждем php 8. Скорей всего алгоритм поменяют.
Появилась функция ещё в PHP 5.5. Знание соли - не дыра. Соль - способ защититься от rainbow tables, в которых просто перечислены хэши без соли, для одного пароля каждый раз одинаковые. Соль же позволяет для одного и того же пароля сгенерить разные результирующие хеши, что исключит поиск по хэшу в списке.
Остаётся только перебор. И конкретно алгоритм mcrypt, используемый на данный момент этой функцией - надежный, так как проверка по этому алгоритму достаточно трудоёмкая.
Простой пароль подберется, конечно, быстро. Но это не проблема алгоритма, а проблема того, кто этот пароль использует. И вот это уже дыра.
Ну смотри. Так сказать от сокурсника ))). Есть у нас жертва, у которой мы вытащили хеш пароля. Из него получили соль (так как это простая процедура и даже не важно, что для остальных соль другая). Далее алгоритм начинает перебирать пароли, но не через запрос к базе, а путем генерации радужной таблицы с данной солью. Путь не быстрый, но заточенное железо эту операцию делает достаточно шустро.
Конечно, уже не получится использовать стандартные радужные таблицы для поиска такого пароля из-за уникальной соли, придется генерить свою, что однозначно дольше. Но все равно этот способ проще, чем перебор пароля в лоб.
P.S. Там bcrypt. А можно подключить Argon2id. Вот это реально мощная штука.
Построение радужной таблицы под конкретную соль дешевле простого перебора? Я, видимо, не совсем понимаю как они работают)
Простой перебор втыкает пароль в запрос и получает - ок или не ок и идёт дальше. При радужной таблице, одна машина генерит список хешей, а вторая проверяет на совпадение. Первый вариант по старинке называется «в лоб».
Скорей всего мы об одном и том же, только разными словами )))
p.s. в лоб еще перебирают пароли у архивов.
Зачем в запрос втыкать? Есть хэш, есть гипотетически правильный пароль. Просто выполняешь проверку. Про радужные таблицы тоже не понял зачем 2 машины. Параллелить смысла нет - пока таблица не сгенерена, смысл её долбить?
Можно, конечно, но суть PDO прежде всего в предоставлении абстракции при работе с БД. Параметризованные запросы - приятное дополнение.
На каком этапе? - перед передчей в БД или на выходе из БД при выдаче клиенту?
С этим что-то пока не очень понятно в конкретной реализации((( И судя по комментариям из статьи по сслыке - работает это дело не очень корректно...
Хэширование - это не шифрование!!! Термин "шифрование" подразумевает возможность расшифровки, а хэширование - необратимо. Правильнее написать "необратимое преобразование данных". Wiki
include - это выражение, а не функция
Спасибо, поправил.
Интересная статья, теперь буду знать) Спасибо!
Попадался на просторах интернета самописный скрипт букса. Как-то допиливая его под себя обнаружил существенную дыру то ли случайно, то ли нарочно оставленную разработчиком. Смысл бага в следующем. Пользователи могут загружать картинку фона или аватара, при этом проверка типа файла выполнялась на странице на уровне JS, а вот php файле, к которому шло обращение через JQuery, такой проверки не было реализовано, только на размер. В итоге можно было создать простую форму с POST запросом прямо к этому php файлу и отправить на сервер свой файл. А дальше полное управление как вы понимаете.
Жёсткий баг)
Ух, хорошо что прочитал статью после того как настроил отправку писем на хостинге, а файл с настройками оказался залит в github. После прочтения сразу гитигнор настроил и удалил файлы важные файлы из гита:) Спасибо!
Не забывайте, что файл можно найти в предыдущих коммитах в истории гита. Иногда из-за этого приходится пересоздавать репу.