crypt() и bcrypt — это разные вещи. Надо понимать, что для получения bcrypt надо в crypt() передать в поле «соль» строку из 3 параметров, включая результат преобразования Eksblowfish(соль) — и вот в этом вычислении Eksblowfish() лежит солидная доля замедления.
Складывается впечатление, что большинство спорщиков (кроме Lockal) вообще не потрудилось почитать о том, что же такое bcrypt на самом деле. Ну вот вы хотя бы открывали статью в вики про bcrypt?
Кстати, польза от радужных таблиц для паролей с собственной солью для каждого юзера никакая, я это понимаю. Но я и не говорил, что радужные таблицы помогут.
На сегодняшний день ваш способ хранения паролей относительно безопасный. Однако я обращаю внимание, что сейчас ведутся исследования SHA-3, потому что SHA-2 (включает SHA-512) алгоритмически похож на SHA-1, в котором нашли коллизии. Это не значит, что Бкрипт лучше, но судя по всему Блоуфиш лучше исследован, что даёт надежду.
товарищ ~Local уже написал выше: применять bcrypt можно для 2 целей:
1) создание хэша. В этом случае на вход даётся пароль и сложность (число). Результат — строка с айди алгоритма, сложностью, солью (сгенерированной алгоритмом самостоятельно, без вас) и хэш.
2 проверка: хэш получен из пароля. На вход даётся сгенерированная в 1) строка и пароль открытым текстом.
Ну вот как-то так примерно.
в бкрипте, если я правильно понял прочитанное, соль является результатом вычисления сложной функции (причем вычислительная сложность функции регулируется). Где-то в алгоритме используется и генератор псевдослучайных чисел. Я не профессионал в области криптографии, лучше почитайте сами, если сомневаетесь.
а теперь давайте поразмышляем о простом пароле, типа 12345 — согласно вашей идее его безопасность будет обеспечена ТОЛЬКО солью. У вас какого размера соль в проектах?
любая идея по алгоритмической защите паролей сводится именно к замедлению полного перебора. Нужно исходить из предположения, что злоумышленник знает алгоритм и закодированное сообщение (хэш в нашем случае).
Об этом должны знать все, кто пишет код авторизации. К сожалению, мой опыт говорит, что это не так :(
> По поводу множества итераций я не уверен. С одной стороны — это много где используется. Меня смущает, что если на вход первой итерации подается неограниченное количество вариантов, т.е. могут быть любые символы, то на вход второй итерации — уже строго ограниченое (a-z0-9 для md5) и так далее мы «сужаем диапазон». Я в этом не силен поэтому воспринимайте это как домыслы.
Почему это md5 на выходе даёт ограниченное множество (a-z0-9)? Это вы откуда взяли вообще? md5 работает с блоками битов. Автор в статье специально указал, что она для тех, кто видит разницу между md5 и md5crypt.
> Еще одна фантазия про коллизии. Если хешировать бесконечно долго (в цикле) 2 разных строки, то в какой-то момент возникнет коллизия и хеши совпадут. Т.е. изначально hash(str1) != hash(str2), но на 100500й итерации они станут равны. Мне кажется что hash(str1) == hash(str2) намного менее вероятно чем hash(str1) == hash(str2) на n-ой итерации. Опять же, из-за того, что в первом случае str1 и str2 абсолютно случайны, а на n-ой итерации «случайны в определенном диапазоне».
Я не одобряю «хешировать бесконечно долго (в цикле) 2 разных строки». Рассмотрите bcrypt (http://ru.wikipedia.org/wiki/Bcrypt) — там на каждой последующей итерации хэшируется результат предыдущей итерации со строкой, которая есть результат хитрой функции над солью, сложностью и др.
правильно сделали, что удалили пост товарища на Стэковерфлоу. Что именно он хотел показать? Что умеет придумывать хорошие пароли? Да кому он сдался такой умный? Вопрос не в том, чтобы подобрать один сложный пароль, а в том, как усложнить подбор простых паролей.
> Но у меня остается вопрос: зачем тогда вам, дорогие программисты, вообще нужен Drupal или другая CMS? Может пора переходить на фреймворки, там кодить придется чаще и там это вполне ожидаемо…
В моём случае Друпал будет потому что работодатель требует. Все программисты в проекте предпочитают фреймворки
честно говоря, лично мне вообще не очень понятна тема поста. Ноутбучные клавиатуры для меня неудобны ВСЕГДА! Среди них нет никакой унификации. За какой ноутбук ни сядь — везде всё по-разному. Я даже не трудился заучивать расположение разных функциональных клавиш, потому что такие сведения устареют очень быстро.
К счастью, мне не очень нужна мобильность, поэтому я на работе выбрал себе обычный системный блок, а не ноутбук. Как и автор, я поклонник стандартных топорных клавиатур; однако между нами есть и разница — я себе стараюсь взять клаву светлого цвета и ненавижу чёрные.
метод очень специфический и мало кому подойдёт — у среднего хостера нет крупных иностранных клиентов. Второй раз тоже будет сложно — не поверят. Но как идея — прикольно.
Складывается впечатление, что большинство спорщиков (кроме Lockal) вообще не потрудилось почитать о том, что же такое bcrypt на самом деле. Ну вот вы хотя бы открывали статью в вики про bcrypt?
На сегодняшний день ваш способ хранения паролей относительно безопасный. Однако я обращаю внимание, что сейчас ведутся исследования SHA-3, потому что SHA-2 (включает SHA-512) алгоритмически похож на SHA-1, в котором нашли коллизии. Это не значит, что Бкрипт лучше, но судя по всему Блоуфиш лучше исследован, что даёт надежду.
1) создание хэша. В этом случае на вход даётся пароль и сложность (число). Результат — строка с айди алгоритма, сложностью, солью (сгенерированной алгоритмом самостоятельно, без вас) и хэш.
2 проверка: хэш получен из пароля. На вход даётся сгенерированная в 1) строка и пароль открытым текстом.
Ну вот как-то так примерно.
Об этом должны знать все, кто пишет код авторизации. К сожалению, мой опыт говорит, что это не так :(
Пожалуйста, вычеркните Федору из списка неуязвимых.
Почему это md5 на выходе даёт ограниченное множество (a-z0-9)? Это вы откуда взяли вообще? md5 работает с блоками битов. Автор в статье специально указал, что она для тех, кто видит разницу между md5 и md5crypt.
> Еще одна фантазия про коллизии. Если хешировать бесконечно долго (в цикле) 2 разных строки, то в какой-то момент возникнет коллизия и хеши совпадут. Т.е. изначально hash(str1) != hash(str2), но на 100500й итерации они станут равны. Мне кажется что hash(str1) == hash(str2) намного менее вероятно чем hash(str1) == hash(str2) на n-ой итерации. Опять же, из-за того, что в первом случае str1 и str2 абсолютно случайны, а на n-ой итерации «случайны в определенном диапазоне».
Я не одобряю «хешировать бесконечно долго (в цикле) 2 разных строки». Рассмотрите bcrypt (http://ru.wikipedia.org/wiki/Bcrypt) — там на каждой последующей итерации хэшируется результат предыдущей итерации со строкой, которая есть результат хитрой функции над солью, сложностью и др.
В моём случае Друпал будет потому что работодатель требует. Все программисты в проекте предпочитают фреймворки
А вы на утечку памяти демоны с использованием этого класса проверяли?
К счастью, мне не очень нужна мобильность, поэтому я на работе выбрал себе обычный системный блок, а не ноутбук. Как и автор, я поклонник стандартных топорных клавиатур; однако между нами есть и разница — я себе стараюсь взять клаву светлого цвета и ненавижу чёрные.