Как раз хотел написать статью про практическую реализацию с примерами ошибок реализации хеширования.
Там и этот пример и еще более классический с DES и 8 байт в .htpasswd и другие.
Спасибо!
Но это не имеет отношения к тем методам, которые я предлагал, так как такой код в моей статье никак не упоминался.
Есть тонна методов накосячить в реализации, и это один из них.
Но никакого отношения к методике это не имеет.
Также в статье, которую вы почему-то решили хаить, отдельно написано про необходимость первым передавать в подхешевое выражение пароль, а вы сделали наоборот :)
Тем не менее, вы сделали полезное дело, что написали людям про свои ошибки. Спасибо!
«Перец, как бы «усиливает» слабый пароль, но только в недрах системы. Через форму логина пароль «asdf» подбирается все так же легко. Слабый пароль — это слабый пароль, как бы Вы себя не обманывали.»
Именно так. Это называется онлайн и офлайн атаки. И от онлайн атаки есть другие методы, такие как freeze. В статье же были рассмотрены только офлайн атаки, о чем написано отдельно. Но вы просто решили хаить, вам же все равно :)
"Все, что может быть украдено, будет украдено. Если вы уверены в защищенности кода, то свой алгоритм хеширования поможет лучше соли. "
Это вообще перл! Его надо запомнить и передавать из поколения в поколение.
Следуя такой логике, будут сразу украдены пользовательские (например) данные, которые мы защищаем паролями. Ну или сами пароли, если так проще воспринимать метод индукции.
Советовать собственный алгоритм хеширования программистам — это диверсия :)
Веб-программисты! Никогда не пишите своей криптухи, никогда!
Поставлю точку. Локальный параметр — это секрет. Такой же секрет, как ваш закрытый SSH ключ, как закрытый ключ от SSL сертификата вашего веб-сервера. И как все секреты его надо защищать.
Вы можете, например, использовать защищенный носитель (смарт-карты, USB токены, и другие). В защищенную область памяти записывается локальный параметр, затем при вызове функции хеширования (cryptoapi), реализованной в самом устройстве, указать, что требуется посчитать ее (хеш) от данных из защищенной памяти (локального параметра), с прибавленными справа входными данными (солью с паролем).
В таком случае, доступ к локальному параметру сводится к физическому доступу к серверу. А получив удаленный доступ на сервер возможно перебирать пароли со скоростью защищенного носителя через тот же cryptoapi. Но в реальной жизни, получив доступ на сервер приложения аутентификации, проще оказывается компрометировать саму систему аутентификации, чем заморачиваться с хешами. О чем тут тоже неоднократно писали в комментариях.
Такие расходы и уровень защищенности для большинства веб-проектов не обоснованы, поэтому хранить локальный параметр предлагается в отдельном месте от хранилища хешей и солей.
oclHashcat очень здесь не репрезентативен для тестов — он закрытый.
И вот, кстати, в тему, как мучался с ним при падении скорости от длины соли: hashcat.net/forum/thread-1437.html
Более чем в два раза никак не должно получаться.
Нет, по вашей базе можно сразу отобрать одинаковые пароли, это очень не хорошо.
Одинаковые — значит самые слабые.
То есть если с атакующий и могу регаться в вашей системе — то смогу нарегать 100500 аккаунтов с типичными паролями и сразу узнать другие логины, которые также их используют.
Вот пример из жизни: у вас есть SQL-инъекция в SELECT с правами на чтение таблицы users. Это mysql, FILE_PRIV нету, никаких других полезных прав кроме этой таблицы на чтение у вас (у того пользователя базы, от которого выполняется SQL запрос) нету. Пусть даже вы можете читать файлы через инъекцию, но СУБД расположена на отдельном сервере, а не на сервер приложений (все так делают, правда).
В базе лежат хэши, соли и логины. Но вы ничего не сможете с ними сделать, если алгоритм хеширования надежный, а локальный параметр достаточной длины.
Получить доступ на чтение (инъекция в SELECT) — одно, на запись (инъекция в UPDATE/INSERT) — другое. Залить шелл и взять логопасс из конфига, а затем UPDATE себе прав — третье.
Но это не значит, что можно забить на хеширование…
Скорость перебора.
Вместо
$hash = hash($user_salt. $passwd);
Можно использовать
$hash = hash($hash_const,$passwd);
где $hash_const=hash($user_salt) будет статичной для каждой соли юзера.
«Я могу предположить, что злоумышленник, написав модифицированный алгоритм нужной хеш-функции, может заранее посчитать известные начала строк, но при условии, что длина этих строк кратна размеру блока хеш-функции.»
Очень странно. Нет, не может. «Известные начала строк» — откуда они известные?
Закончился срок хранения файла. Файл удален с сервиса.
Заранее спасибо!
Там и этот пример и еще более классический с DES и 8 байт в .htpasswd и другие.
Спасибо!
Но это не имеет отношения к тем методам, которые я предлагал, так как такой код в моей статье никак не упоминался.
Есть тонна методов накосячить в реализации, и это один из них.
Но никакого отношения к методике это не имеет.
Также в статье, которую вы почему-то решили хаить, отдельно написано про необходимость первым передавать в подхешевое выражение пароль, а вы сделали наоборот :)
Тем не менее, вы сделали полезное дело, что написали людям про свои ошибки. Спасибо!
«Перец, как бы «усиливает» слабый пароль, но только в недрах системы. Через форму логина пароль «asdf» подбирается все так же легко. Слабый пароль — это слабый пароль, как бы Вы себя не обманывали.»
Именно так. Это называется онлайн и офлайн атаки. И от онлайн атаки есть другие методы, такие как freeze. В статье же были рассмотрены только офлайн атаки, о чем написано отдельно. Но вы просто решили хаить, вам же все равно :)
Это вообще перл! Его надо запомнить и передавать из поколения в поколение.
Следуя такой логике, будут сразу украдены пользовательские (например) данные, которые мы защищаем паролями. Ну или сами пароли, если так проще воспринимать метод индукции.
Советовать собственный алгоритм хеширования программистам — это диверсия :)
Веб-программисты! Никогда не пишите своей криптухи, никогда!
Поставлю точку. Локальный параметр — это секрет. Такой же секрет, как ваш закрытый SSH ключ, как закрытый ключ от SSL сертификата вашего веб-сервера. И как все секреты его надо защищать.
Вы можете, например, использовать защищенный носитель (смарт-карты, USB токены, и другие). В защищенную область памяти записывается локальный параметр, затем при вызове функции хеширования (cryptoapi), реализованной в самом устройстве, указать, что требуется посчитать ее (хеш) от данных из защищенной памяти (локального параметра), с прибавленными справа входными данными (солью с паролем).
В таком случае, доступ к локальному параметру сводится к физическому доступу к серверу. А получив удаленный доступ на сервер возможно перебирать пароли со скоростью защищенного носителя через тот же cryptoapi. Но в реальной жизни, получив доступ на сервер приложения аутентификации, проще оказывается компрометировать саму систему аутентификации, чем заморачиваться с хешами. О чем тут тоже неоднократно писали в комментариях.
Такие расходы и уровень защищенности для большинства веб-проектов не обоснованы, поэтому хранить локальный параметр предлагается в отдельном месте от хранилища хешей и солей.
Есть модель, в которой локальный параметр недоступен атакующему, в это случае атака становится на порядки сложнее.
Эта модель очень применима для веб-приложений на основе 5 лет аудитов.
Если Вы говорите, что модель не применима — аргументируйте.
И вот, кстати, в тему, как мучался с ним при падении скорости от длины соли: hashcat.net/forum/thread-1437.html
Более чем в два раза никак не должно получаться.
10 = md5($pass.$salt)
Speed.GPU.#8...: 3341.1M/s
20 = md5($salt.$pass)
Speed.GPU.#8...: 4386.9M/s
698458060175b453b3c59834fdf3f8c5:1q2w3e4r5t
Для хеширования паролей это не играет.
Одинаковые — значит самые слабые.
То есть если с атакующий и могу регаться в вашей системе — то смогу нарегать 100500 аккаунтов с типичными паролями и сразу узнать другие логины, которые также их используют.
По теме перебора — используются специальные правила, распределающие по вероятности пароли при переборе.
Почитать:
www.openwall.com/john/doc/MODES.shtml
hashcat.net/trac/ticket/60
contest-2010.korelogic.com/rules.html
Вы все-равно не сможете это доказать или опровергнуть :)
В базе лежат хэши, соли и логины. Но вы ничего не сможете с ними сделать, если алгоритм хеширования надежный, а локальный параметр достаточной длины.
Думаете редкий пример? Отнюдь :)
Но это не значит, что можно забить на хеширование…
Вместо
$hash = hash($user_salt. $passwd);
Можно использовать
$hash = hash($hash_const,$passwd);
где $hash_const=hash($user_salt) будет статичной для каждой соли юзера.
Очень странно. Нет, не может. «Известные начала строк» — откуда они известные?