Pull to refresh
52
Karma
0
Rating
Ivan Novikov @d0znpp

User

Spring Remoting — Spring + RMI

Прошу пакет с примера перезалить.
Закончился срок хранения файла. Файл удален с сервиса.

Заранее спасибо!

Как испортить безопасность паролей, следуя советам с Хабра

Как раз хотел написать статью про практическую реализацию с примерами ошибок реализации хеширования.
Там и этот пример и еще более классический с DES и 8 байт в .htpasswd и другие.

Спасибо!

Но это не имеет отношения к тем методам, которые я предлагал, так как такой код в моей статье никак не упоминался.
Есть тонна методов накосячить в реализации, и это один из них.
Но никакого отношения к методике это не имеет.
Также в статье, которую вы почему-то решили хаить, отдельно написано про необходимость первым передавать в подхешевое выражение пароль, а вы сделали наоборот :)

Тем не менее, вы сделали полезное дело, что написали людям про свои ошибки. Спасибо!

«Перец, как бы «усиливает» слабый пароль, но только в недрах системы. Через форму логина пароль «asdf» подбирается все так же легко. Слабый пароль — это слабый пароль, как бы Вы себя не обманывали.»

Именно так. Это называется онлайн и офлайн атаки. И от онлайн атаки есть другие методы, такие как freeze. В статье же были рассмотрены только офлайн атаки, о чем написано отдельно. Но вы просто решили хаить, вам же все равно :)

Как надо хешировать пароли и как не надо

Дождался, пока вы закончите перепалку.

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


Это вообще перл! Его надо запомнить и передавать из поколения в поколение.

Следуя такой логике, будут сразу украдены пользовательские (например) данные, которые мы защищаем паролями. Ну или сами пароли, если так проще воспринимать метод индукции.

Советовать собственный алгоритм хеширования программистам — это диверсия :)

Веб-программисты! Никогда не пишите своей криптухи, никогда!

Поставлю точку. Локальный параметр — это секрет. Такой же секрет, как ваш закрытый SSH ключ, как закрытый ключ от SSL сертификата вашего веб-сервера. И как все секреты его надо защищать.

Вы можете, например, использовать защищенный носитель (смарт-карты, USB токены, и другие). В защищенную область памяти записывается локальный параметр, затем при вызове функции хеширования (cryptoapi), реализованной в самом устройстве, указать, что требуется посчитать ее (хеш) от данных из защищенной памяти (локального параметра), с прибавленными справа входными данными (солью с паролем).

В таком случае, доступ к локальному параметру сводится к физическому доступу к серверу. А получив удаленный доступ на сервер возможно перебирать пароли со скоростью защищенного носителя через тот же cryptoapi. Но в реальной жизни, получив доступ на сервер приложения аутентификации, проще оказывается компрометировать саму систему аутентификации, чем заморачиваться с хешами. О чем тут тоже неоднократно писали в комментариях.

Такие расходы и уровень защищенности для большинства веб-проектов не обоснованы, поэтому хранить локальный параметр предлагается в отдельном месте от хранилища хешей и солей.

Как надо хешировать пароли и как не надо

Товарищ говорит о модели угроз. Вы почему-то оперируете каким-то термином «допущение».

Есть модель, в которой локальный параметр недоступен атакующему, в это случае атака становится на порядки сложнее.

Эта модель очень применима для веб-приложений на основе 5 лет аудитов.

Если Вы говорите, что модель не применима — аргументируйте.

Как надо хешировать пароли и как не надо

oclHashcat очень здесь не репрезентативен для тестов — он закрытый.
И вот, кстати, в тему, как мучался с ним при падении скорости от длины соли: hashcat.net/forum/thread-1437.html
Более чем в два раза никак не должно получаться.

Как надо хешировать пароли и как не надо

oclHashcat HD7990 (one core):

10 = md5($pass.$salt)
Speed.GPU.#8...: 3341.1M/s
20 = md5($salt.$pass)
Speed.GPU.#8...: 4386.9M/s

698458060175b453b3c59834fdf3f8c5:1q2w3e4r5t

Как надо хешировать пароли и как не надо

Это из определения криптографических хешей приведено.
Для хеширования паролей это не играет.

Как надо хешировать пароли и как не надо

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

Как надо хешировать пароли и как не надо

Это вообще не про то, что спрашивали, cost параметр. А так есть, да. И константы в алгоритмах тоже менять не следует :)

Как надо хешировать пароли и как не надо

Нет, по вашей базе можно сразу отобрать одинаковые пароли, это очень не хорошо.
Одинаковые — значит самые слабые.
То есть если с атакующий и могу регаться в вашей системе — то смогу нарегать 100500 аккаунтов с типичными паролями и сразу узнать другие логины, которые также их используют.

По теме перебора — используются специальные правила, распределающие по вероятности пароли при переборе.
Почитать:
www.openwall.com/john/doc/MODES.shtml
hashcat.net/trac/ticket/60
contest-2010.korelogic.com/rules.html

Как надо хешировать пароли и как не надо

И да, представьте что у всех этих пользователей пароль 1234.
Вы все-равно не сможете это доказать или опровергнуть :)

Как надо хешировать пароли и как не надо

Вот пример из жизни: у вас есть 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) будет статичной для каждой соли юзера.

Как надо хешировать пароли и как не надо

Ну просто здесь GPU скорости описаны, а для CPU будут другие соотношения. bcrypt специально спроектирован для противодействия GPU атакам.

Как надо хешировать пароли и как не надо

Это для случая hash(salt.password), но для случая hash(password.salt) такое уже не работает, о чем и речь идет.

Как надо хешировать пароли и как не надо

Ровно про это же я писал в тексте :) Но это не значит, что не надо защищать этот аспект.

Как надо хешировать пароли и как не надо

«Я могу предположить, что злоумышленник, написав модифицированный алгоритм нужной хеш-функции, может заранее посчитать известные начала строк, но при условии, что длина этих строк кратна размеру блока хеш-функции.»

Очень странно. Нет, не может. «Известные начала строк» — откуда они известные?

Information

Rating
Does not participate
Location
Россия
Registered
Activity