• Spring Remoting — Spring + RMI
    0
    Прошу пакет с примера перезалить.
    Закончился срок хранения файла. Файл удален с сервиса.

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

    Спасибо!

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

    Если Вы говорите, что модель не применима — аргументируйте.
  • Как надо хешировать пароли и как не надо
    0
    oclHashcat очень здесь не репрезентативен для тестов — он закрытый.
    И вот, кстати, в тему, как мучался с ним при падении скорости от длины соли: hashcat.net/forum/thread-1437.html
    Более чем в два раза никак не должно получаться.
  • Как надо хешировать пароли и как не надо
    +1
    Согласен!
  • Как надо хешировать пароли и как не надо
    +1
    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
  • Как надо хешировать пароли и как не надо
    +3
    Это из определения криптографических хешей приведено.
    Для хеширования паролей это не играет.
  • Как надо хешировать пароли и как не надо
    +2
    Не я придумал терминологию локального параметра. Написал откуда она. И не думаю, что можно оспаривать эти материалы.
  • Как надо хешировать пароли и как не надо
    –2
    Это вообще не про то, что спрашивали, cost параметр. А так есть, да. И константы в алгоритмах тоже менять не следует :)
  • Как надо хешировать пароли и как не надо
    0
    Один, но bcrypt
  • Как надо хешировать пароли и как не надо
    +3
    Нет, по вашей базе можно сразу отобрать одинаковые пароли, это очень не хорошо.
    Одинаковые — значит самые слабые.
    То есть если с атакующий и могу регаться в вашей системе — то смогу нарегать 100500 аккаунтов с типичными паролями и сразу узнать другие логины, которые также их используют.

    По теме перебора — используются специальные правила, распределающие по вероятности пароли при переборе.
    Почитать:
    www.openwall.com/john/doc/MODES.shtml
    hashcat.net/trac/ticket/60
    contest-2010.korelogic.com/rules.html
  • Как надо хешировать пароли и как не надо
    +2
    И да, представьте что у всех этих пользователей пароль 1234.
    Вы все-равно не сможете это доказать или опровергнуть :)
  • Как надо хешировать пароли и как не надо
    +5
    Вот пример из жизни: у вас есть SQL-инъекция в SELECT с правами на чтение таблицы users. Это mysql, FILE_PRIV нету, никаких других полезных прав кроме этой таблицы на чтение у вас (у того пользователя базы, от которого выполняется SQL запрос) нету. Пусть даже вы можете читать файлы через инъекцию, но СУБД расположена на отдельном сервере, а не на сервер приложений (все так делают, правда).

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

    Думаете редкий пример? Отнюдь :)
  • Как надо хешировать пароли и как не надо
    +4
    Получить доступ на чтение (инъекция в SELECT) — одно, на запись (инъекция в UPDATE/INSERT) — другое. Залить шелл и взять логопасс из конфига, а затем UPDATE себе прав — третье.

    Но это не значит, что можно забить на хеширование…
  • Как надо хешировать пароли и как не надо
    +1
    Скорость перебора.
    Вместо
    $hash = hash($user_salt. $passwd);
    Можно использовать
    $hash = hash($hash_const,$passwd);
    где $hash_const=hash($user_salt) будет статичной для каждой соли юзера.
  • Как надо хешировать пароли и как не надо
    +2
    Ну просто здесь GPU скорости описаны, а для CPU будут другие соотношения. bcrypt специально спроектирован для противодействия GPU атакам.
  • Как надо хешировать пароли и как не надо
    +1
    Это для случая hash(salt.password), но для случая hash(password.salt) такое уже не работает, о чем и речь идет.
  • Как надо хешировать пароли и как не надо
    0
    Ровно про это же я писал в тексте :) Но это не значит, что не надо защищать этот аспект.
  • Как надо хешировать пароли и как не надо
    0
    «Я могу предположить, что злоумышленник, написав модифицированный алгоритм нужной хеш-функции, может заранее посчитать известные начала строк, но при условии, что длина этих строк кратна размеру блока хеш-функции.»

    Очень странно. Нет, не может. «Известные начала строк» — откуда они известные?
  • Как надо хешировать пароли и как не надо
    +12
    Парольная политика — организационная мера. Очень важная и правильная. Также как и осведомленность сотрудников о том, что пароли не надо выкладывать на pastebin, ssh ключи пушить в github, и записывать секреты на бумажках рядом с мониторами. Но текст не об этом.
  • Как надо хешировать пароли и как не надо
    +5
    В тексте ссылки на тексты Solar Designer, какому еще эксперту в криптографии вы доверяете?
  • Как надо хешировать пароли и как не надо
    +4
    С точки зрения оптимизации — вы полностью правы. Но проблемы возникают на доказательстве реально величины энтропии этих случайностей.
  • Как надо хешировать пароли и как не надо
    +9
    Мы сводим к невозможной офлайн атаку через доступ только к одному хранилищу.

    Не знаю сколько систем вы атаковали, но могу сказать по своей статистике за 5 лет, что это очень хороший уровень защиты. Про его обходы написано в теле статьи.
  • Как надо хешировать пароли и как не надо
    0
    Зависит от, надо тестировать конкретную систему. Если у вас скорости менее 1000 хэшей в секунду — вы ничего не заметите. Иначе — давайте смотреть ТТХ.
  • Как надо хешировать пароли и как не надо
    +11
    Это вообще не security through obscurity, это называется разделяемый секрет.
    Security through obscurity — это если бы атакующий не знал алгоритма хэширования.
  • Как надо хешировать пароли и как не надо
    +5
    Специально начал статью с определения условий применимости, чтобы избежать таких странных комментов — но всем пофигу :)
  • Как надо хешировать пароли и как не надо
    0
    Эта соль будет в базе и захватив хранилище можно будет проводить атаку.
    Если соль не будет в базе, а будет одна на всех — то можно будет быстро найти все одинаковые пароли.
  • Как надо хешировать пароли и как не надо
    0
    Константа вне базы? Тогда это и есть локальный параметр.
    Дата регистрации — это соль фактически, пользовательская.
  • Как надо хешировать пароли и как не надо
    0
    я же большими буквами написал, что bcrypt
  • Как надо хешировать пароли и как не надо
    0
    там же снизу цифры!
    220M против 8,5k, то есть где-то на 4 порядка для GPU
  • Как надо хешировать пароли и как не надо
    0
    «Ещё я интуитивно делаю хешеривание на стороне приложения, а не в БД — избегаю передачи пароля и глобальной соли лишний раз даже на локальной машине по файловым сокетам, не говоря о сети — мало ли кто как к каналу присосался. Или к логам БД.»

    напишите как схема работает, клиент передает hash(login.salt), где hash вычисляется на JavaScript?
  • Подробно о генераторах случайных и псевдослучайных чисел
    0
    «Если у нас есть 624 последовательных числа сгенерированных Mersenne Twister, то применив этот алгоритм для этих последовательных чисел, мы получим полное состояние Mersenne Twister» а зачем это делать?
    Все проще!
    У нас есть seed и rand и они зависимы между собой. Связь однозначная.
    Если же значения ранда модулированные, то есть mt_rand(0,N), то надо больше rand, но поверьте — 624 — это ПРОСТО ДОФИГА :)
    См. www.slideshare.net/d0znpp/dcg7812-cryptographyinwebapps-14052863 слайды с 18го
  • Случайные числа. Take Two
    0
    На тему получения pid+microtime от самого аппсервера решал эту задачу и добавил в слайды с Defcon-Russia: oxod.ru/DCG7812-Cryptography-in-webapps.pdf
    Вместе с этим инструментов и хотел бы использовать, но AMD все испортило :(((
  • Случайные числа. Take Two
    0
    Самая главная сложность — server-status. С этого можно начать и закончить.
    Про Date — вы так атаковали хотя бы один сервер с балансером или фронотэдом? Как?

    Про атаки на сами веб-приложения все-таки не совсем не понятно по статье. Давайте разделять — веб-сервер с пыхом в целом, и там генерация PHPSESSID и отдельно веб-приложения, в частности, с выводом mt_rand значений в HTTP ответ. Тогда с примерами покажите как это связать вместе.
  • Случайные числа. Take Two
    +1
    Спасибо за хороший инструмент и статью! А можете собрать вариант для ATI карточек под OpenCL? Они быстрее и дешевле Nvidia.

    Есть практические суровые НО, на которые стоит обратить внимание администраторам, прежде чем пытаться решить проблему на стороне каких-то Cisco.
    Эта атака имеет существенное ограничение, про которое не стоит забывать — ей нельзя атаковать реальные веб-проекты. Дело в том, что заголок Date, который необходим в реальной жизни переписывает фронтэндом или балансером. Поэтому мешается. Keep-alive тоже в 50% случаях запрещен просто на балансирующей nginx и приехали. В этих условиях беда-беда, особенно если таймзона аппсервера и балансера разбежались. Это даже если открыт server-status, который в реальной жизни встречается в 5% случаев.

    По статье, все очень грамотно изложено, но причем тут фраза «Принцип такой. Отправляем два запроса один за другим: первый на сброс пароля себе, второй — на сброс пароля админа. Разница в microseconds будет минимальна.» и как это связано с PHPSESSID хоть убейте — не понимаю!

    Также просьба — пишите, пожалуйста, ссылки на исследования, которые легли в основу в тексте, в частности www.suspekt.org/2008/08/17/mt_srand-and-not-so-random-numbers/ забыли. Ссылки в комментах искать нереально, а разобраться почему работает тот же keep-alive, просто по атаке, очень трудно.

    Еще раз спасибо за инструмент и статью, вы МОЛОДЦЫ!
  • Уязвимость PHP в режиме CGI
    +1
    Это удаленно выполнение команд, и это весело %)
  • Типичная ошибка при установке COOKIE в PHP
    0
  • Типичная ошибка при установке COOKIE в PHP
    +1
    Действительно, это так. Спасибо! При указании даже прямого домена, браузер все-равно проставяет на все поддомены. Новый RFC работает именно так. Надо думать…
  • Типичная ошибка при установке COOKIE в PHP
    0
    Все проверил — никто не ставит на поддомены. Вы на чем проверяли?