ggfdsfds
Новичок
Сталкивался с тем, что соль может храниться, к примеру где ни будь в виде переменной - обычно в настройках сайта (config).
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Вопрос про безопасность SQL-запросов.
- Автор темы ggfdsfds
- Дата начала
омг, вот я не думал что в родном пхпклуббе придется разжевывать, что такое радуга и зачем соль.
Читайте пока тут http://www.phpfaq.ru/hashing
выводы я допишу позже
Читайте пока тут http://www.phpfaq.ru/hashing
выводы я допишу позже
hell0w0rd
Продвинутый новичок
это не соль... это "перец". Если таки взломают базу и сядут хеши рассекречивать, а код останется не доступным - ничего не получится, тк есть еще и перец
ggfdsfds
Новичок
Что то больно много всего полезного там... В общем читаю весь ресурс.
если соль неуникальная, то то, чем ты будешь заниматься после получения соли, будет называться брут.
в процессе построения брута ты можешь строить и радугу тоже, и потом пробивать по ней другие пароли.
но изначально у тебя радуги не будет.
в этом и состоит разница.
тем более, что соль должна быть уникальной - что сделает радугу неприменимой в принципе.
Фанат, я считаю что мд5 ( одна и таже соль (10-30 символов) с паролем хешем от предыдушего вызова) в рекурсии 100 раз чтоб затормозить генератор будет вполне достаточна, можно добавить функциональную фишку типа времени создания но как только этот алгоритм становиться известным (временная метка), это уже не имеет смысла. важно чтоб было биткоинсы майнить дешевле чем пароли разгадывать. а вообще твоя статья очень правильная!
Фанат, у тебя там написано не совсем верно:
Длина пароля тут никакой роли не играет, кроме частоты их использования. Это же хеш-функция, длина результата фиксированная. И тебе не нужен исходный текст - тебе нужен текст, дающий аналогичный хеш. Да, количество вариантов хешей огромно, но их множество все равно заведомо и намного меньше, чем количество комбинаций символов.
Надо конечно, написать еще про двухфакторную авторизацию, авторизацию через соцсети (там нет ни хешей, ни паролей, и в случае утери достаточно отозвать саму подписку приложения) и про новый http://php.net/password_hash в пхп, который значительно упрощает хеширование
Ты неприемлемо уменьшаешь количество вероятных исходных данных. твою рекурсию в 100 проходов выкинут, и будут искать коллизию с текстом с ограниченным набором символов, и заведомо известной длиной - то, что получится на 99 проходе. Брутфорсом тебя в таком раскладе можно перебрать за смешное время.
Найти коллизию заведомо сложнее,чем сбрутить исходный пароль.
В том-то и дело, что при парольных длинах хэшируемой строки - микроскопических по сути - как раз длина-то и играет ключевую роль.
Последнее редактирование:
хорошо, я перечитал еще раз твой абзац, и наверное соглашусь с ним в той формулировке. С точки зрения математики он может быть не точен, но область обсуждения действительно, достаточно узкая, что бы можно было принять за данность, что пароли почти всегда короче хеша, и что перебирать их всегда будут с точки зрения наибольшего ожидания человеческого поведения при выборе пароля.
С одной стороны, это действительно просто обёртка над бкриптом.
С другой - только ради *удобства* упоминать смысла никакого нет. Там весь упор как раз на скорость создания хэша - о чем у меня и говорится.
Ты видел, как в бкрипте создавать нормальный хеш? Там надо с мануалом наверно сидеть час, и все равно можно сделать неверно. Мне кажется, это важная вещь, которая упрощая - мешает делать неправильно. И поэтому ее нужно пропагандировать. Помнится, была презенташка чья-то, кажется, Альшанецкого, где было показано, что с бкриптом не справляются даже такие гиганты, как линкдин.
дещевле 100 раз прокрутить чем подбирать 16³² для каждого пользователя