Среда, 15.05.2024, 13:19
Мой персональный сайт Добрым людям smart & sober

Главная Регистрация Вход
Приветствую Вас, Гость · RSS
Калькулятор


Меню сайта
Календарь
«  Июнь 2012  »
ПнВтСрЧтПтСбВс
    123
45678910
11121314151617
18192021222324
252627282930


Форма входа


Архив записей
Мини-чат


Категории раздела


Наш опрос
В чем заключается ваш смысл жизни
Результаты | Архив опросов
Всего ответов: 154
 
Главная » 2012 » Июнь » 8 » Автор md5crypt просит им больше не пользоваться
22:50
Автор md5crypt просит им больше не пользоваться
Автор md5crypt Пол-Хеннинг Камп (Poul-Henning Kamp) опубликовал на персональном сайте призыв ко всем разработчикам прекратить использовать этот алгоритм для шифрования (скремблирования) паролей.

Камп говорит, что для своего времени md5crypt был достаточно надёжной защитой для паролей, но с момента его выхода в 1995 году прошло очень много времени. Последние тесты показывают, что на коммерчески доступном GPU можно перебирать варианты со скоростью 1 миллион в секунду, то есть MD5 сейчас уязвим перед брутфорсом точно в той же степени, в какой был уязвим основанный на DES скремблер crypt в 1995 году. Любой пароль из 8 символов можно взломать за пару дней.

«Как автор md5crypt, я умоляю всех не откладывая перейти на более надёжный скремблер паролей», — говорит Пол-Хеннинг Камп.

Камп не называет конкретно, что выбрать вместо md5crypt. Он говорит, что не является видным специалистом по криптографии и не намерен писать новую программу для шифрования паролей. Однако, может дать пару рекомендаций. Во-первых, на самом лучшем GPU программный алгоритм должен срабатывать не быстрее чем за 0,1 секунды.

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

Алгоритм должен быть основан на повторяемых итерациях с данными, задействуя несколько сложных односторонних хеш-функций — MD5, SHA1, SHA2, Blowfish и так далее. Камп говорит, что можно использовать их все, лишь бы «высосать» максимальное количество аппаратных ресурсов у взломщика.

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

Впрочем, с последней рекомендацией можно поспорить. Известный криптограф Брюс Шнайер в книге «Секреты и ложь» пишет: «Любой, кто создает собственный образец шифрования, — либо гений, либо глупец». Учитывая количество веб-сайтов в мире, сложно представить такое количество гениев.
  • ,
  • ,
  • ,
  • ,
  • ,

    Несколько комментариев  (всего 224)   http://habrahabr.ru/post/145454/

    +10
      iXCray # 
    DEFINE("TBP_SALT", "Соль. Ключ. Называйте, как хотите. Чем длиннее, тем лучше, как обычно. Ограничений по алфавиту нет.");

DEFINE("TBP_SALT_p1", substr(
 md5(TBP_SALT),
 min(
 abs(strlen(TBP_SALT)%32-15),
 abs(strlen(TBP_SALT)%32-32)
 ),
 max(
 abs(strlen(TBP_SALT)%32-15),
 abs(strlen(TBP_SALT)%32-32)
 )
 ));
DEFINE("TBP_SALT_p2", substr(
 md5(strrev(TBP_SALT)),
 min(
 abs(strlen(TBP_SALT)%30-15),
 abs(strlen(TBP_SALT)%32-26)
 ),
 max(
 abs(strlen(TBP_SALT)%32-15),
 abs(strlen(TBP_SALT)%32-26)
 )
 ));

function TBP_PWD($v)
{
 return md5(
 TBP_SALT_p1.
 md5(
 substr(TBP_SALT, 0, strlen(TBP_SALT)/3).
 $v.
 substr(TBP_SALT, 2*strlen(TBP_SALT)/3, strlen(TBP_SALT)-1)
 )
 .TBP_SALT_p2);
}
    +8
      iXCray # ↑
    Случайно нажал кнопку отправки.

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

    Хранение ключа — вопрос совершенно отдельной темы. Я просто хотел привести пример, как можно чуть лучше, чем тривиально, усложнить жизнь злоумышленнику с GPU.
    +6
      nazarpc # ↑
    Вы не учли, что длинны хеша md5() на сегодняшний день для хорошей защиты недостаточно по причине существования коллизий, и брутфорсом можно подобрать если не настоящий пароль, то тот, который имеет такой же md5 хеш, думаю, автор и об этом в том числе говорит.
    Нужен не только более сложный алгоритм в плане вычислений, но и большая длина конечного хеша.
    +10
      mihaild # ↑
    Ага. 128 бит.
    2^128
    Перебираем по миллиарду (~2^30) паролей в секунду. Получаем 2^98 секунд. Гугл подсказывает, что это ~10^22 лет. Возраст Вселенной — примерно 10^10 лет. Т.е. получаем, что на подбор пароля с таким же хешем нам понадобится всего лишь триллион сроков существования Вселенной. Говорить не о чем:)
    +8
      InSys # ↑
    Я думаю человек выше имел ввиду, что существует вероятность того, что для каждого пароля существуют коллизии.

    И, к сожалению, есть вероятность того, что для вашего супер длинного пароля в минимум 30 символов найдется коллизия, которая будет намного короче (например в 1 байт), и будет случайно найденна при брутофорсе.

    А насчет длинны, то все банальнее. Чем длиннее хеш — тем меньше вероятность того, что такая коллизия существует или будет случайно найденна при брутофорсе.
    0
      mihaild # ↑
    Ну да. md5 псевдослучайна, и вроде бы никаких эффективных способов ее обратить на текущий момент неизвестно. Значит, нет ничего лучше, чем просто перебирать разные строки и сравнивать их хеш с имеющимся.
    Вероятность совпадения для каждой фиксированной строки есть 2^{-128}. Т.е. в среднем придется перебрать 2^{128}. Это очень, очень долго.
    Конечно, среди паролей длиной в 30 символов есть такие, чьи хеши совпадают с хешами каких-то более коротких паролей. Почти наверняка есть и с хешем, совпадающим с хешем однобуквенного пароля. Но вероятность наткнуться на такой пренебрежимо мала.
    +25
      AlexRex # ↑
    Не могу не процитировать древний баян: «edonkey — крупнейшая сеть для восстановления файлов по их md5-хэшу»
    +2
      kingpin # ↑
    Вы забываете, что есть так называемый «парадокс дней рождений», который парадоксом на самом деле не является. В соответствии с ним для нахождения коллизии нам требуется перебрать лишь квадратный корень от длины ключа [случайных] сообщений, чтобы наткнуться на коллизию со значением, которое вы мне предоставили. Т. е. при длине в хэша 128 бит я переберу не 2^128 строк, а всего лишь sqrt(2^128) == 2^64, что тоже не так уж и мало, но уже достаточно, чтобы успешно осуществить перебор. К тому же никто не запрещает распараллелить перебор на большом количество ядер/машин. Например, одна пойдет перебирать с начала, вторая – с конца.
    +1
      mihaild # ↑
    ru.wikipedia.org/wiki/%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%BE%D0%BA%D1%81_%D0%B4%D0%BD%D0%B5%D0%B9_%D1%80%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F

    Отлично, распараллелите на миллиард ядер. Тогда Вам понадобится всего лишь тысяча сроков существования Вселенной)
    0
      esc # ↑
    На миллиарде ядер, которые могут выполнять по миллион переборов в секунду, нужно будет всего 5 часов.
    +1
      mihaild # ↑
    10^9 ядер
    10^6 операций в секунду
    5 часов < 10^5 секунд
    10^20 < 2^70 вариантов
    А для нахождения пароля, дающего такой же 128-битный хеш, что и наш, надо в среднем 2^128 попыток. Вы немного обсчитались.
    0
      esc # ↑
    в секунду выходит 10^15 операций. или 3.6 * 10^18 в час
    2^64 = 1.8*10^19

    Делим первое на второй, получаем 5.124. Для нахождения пароля, как говорили выше, достаточно 2^64 попыток (в большинстве случаев).
    +1
      mihaild # ↑
    Ссылку на википедию Вы проигнорировали. Прочитайте, что такое парадокс дней рождения и для чего на самом деле достаточно 2^64. Если будут вопросы — спрашивайте, попробую объяснить:)
    0
      esc # ↑
    Я исходил и условия что такие достаточно;) В любом случае, я считаю что проблема надумана и соль вполнее ее решает (может быть в комбинированном варианте). Проблема подбора коллизии. Пароль гораздо проще получить другими способами, чем пытаться посчитать коллизию.
    +1
      TheShock # ↑
    Проблема в следующем:

    При условии, что злоумышленник знает алгоритм хеширования, соль и имеет базу хешей все пароли до 8-ми символов включительно он может с лёгкостью подобрать на современном домашнем железе.

    Я не могу понять, зачем люди приплели сюда всякие дни рождения и всё остальное.
    0
      esc # ↑
    Что он сможет подобрать?
    Может я не понимаю, но допустим hash=md5(md5(pass)+salt). Можно узнать, какой pass даст по этой формуле с такой-же солью нужный хеш. Но если соль поменять, то pass уже не подойдет. Т.е. можно будет залогиниться только на этот-же сайт, где взять хеши.

    Пароли не скомпрометированы, результат пары дней работы кластера это возможность входа в один аккаунт. При том, что как-то с этого-же сайта уже стянули базу и код (соль). Как-то не очень осмысленно. Наверное, проще соль поместить в таком месте, где ее сложно достать, чем переходить на медленные хеши.
    0
      TheShock # ↑
    У нас есть формула:
    hash=md5(md5(pass)+salt)

    Из этой формулы у нас известны — salt, hash и алгоритм.
    Неизвестная одна — pass. Мы подбираем пароль. допустим он у нас «sex123». Теперь у нас есть пароль пользователя. Даже если сервер поменял соль:
    hash2=md5(md5(pass)+salt2)
    Мы уже знаем пароль пользователя — он не меняется.
    0
      esc # ↑
    Ну да, я не учел, что в случае короткого пароля, он первым и вылезет при поиске коллизии) Тем не менее — не проще ли спрятать соль? Не хранить ее на диске в открытом виде, а качественно шифруя внутри некого сервиса генерации хешей, который работает в виде бинарного файла. Такой сервис может запускаться долго (шифровать соль по какому-то 2048бит ключу среди кучи мусорных данных), но после запуска иметь соль в памяти для быстрого доступа.
    0
      mihaild # ↑
    security through obscurity
    0
      esc # ↑
    А вы считаете, что долгий хеш будет так уж сложно подобрать ботнетом?
    0
      mihaild # ↑
    Я считаю, что при наличии нормального пароля подбирать будет долго и быстрый хеш. Конечно, если производительность вырастет еще во столько же раз, во сколько она выросла с изобретения компьютеров — 128 битов может уже оказаться мало. Но на текущий момент и в ближайшей перспективе перебор 2^128 вариантов является нерешаемой задачей, даже если Вы задействуете всю существующую на планете электронику.
    0
      esc # ↑
    2^128 это минимум 20 символов пароля (24, если использовать только base64 символы). Согласитесь, заставлять пользователей массового сервиса использовать даже половину от такой сложности пароля, это не очень решаемая задача. Все равно, будут использовать sex123 и дале медленные хеши будут так-же уязвимы, как и быстрые (чуть с большими затратами).

    А если сделать сильно медленный хеш, то сервис сам задолбается его считать, серверов не напасешься (еще и с видеокартами).
    0
      mihaild # ↑
    Ну да, пользователей с плохими паролями спасти вряд ли возможно.
    0
      mihaild # ↑
    Брутфорс имеет смысл только для простых паролей — коротких либо словарных. Вероятность того, что два разных простых пароля дадут с данной солью один и тот же хеш — исчезающе мала.
    0
      mihaild # ↑
    Я исходил и условия что такие достаточно

    Расшифруйте, пожалуйста:)

    Что именно Вы понимаете под подбором коллизии — нахождение какого-нибудь прообраза по данному хешу, или нахождение пары разных строк с одинаковыми хешами?
    Первое требует в среднем проверки 2^128 вариантов.
    Второе может быть реализовано с помощью атаки дней рождения и генерации 2^64 хешей — среди этих хешей скорее всего будут хотя бы два одинаковых. Но чем нам поможет нахождение этих двух строк?
    0
      esc # ↑
    Я просто посчитал, сколько времени нужно будет для перебора 2^64 вариантов, не более.
    0
      mihaild # ↑
    А, ну да. Если внезапно нам достаточно перебрать 2^64 вариантов, то всё делается быстро. А если 2^0 — то еще быстрее.
    Ветка начиналась с «брутфорсом можно подобрать если не настоящий пароль, то тот, который имеет такой же md5 хеш». И для этого надо 2^128 вариантов.
    0
      esc # ↑
    Ну по теме брутфорса — надо соль прятать, тогда не смогут брутфорсом поломать хеш;) Вероятность того, что сольют не только базу, но и грамотно спрятанный хеш, очень небольшая.
    0
      mihaild # ↑
    habrahabr.ru/post/145454/#comment_4889740
    0
      esc # ↑
    давайте я не буду тут постить ссылку на мой ответ к тому комментарию;)
    0
      Godless # ↑
    Поддерживаю. Причем есть же ботнеты, которые брутят разные хэши паролей толпой в том числе и на гпу.
    0
      sic # ↑
    это здесь не причем. парадокс дней рождения применим к нахождению случайных коллизий, и по последним данным это можно сделать значительно быстрее, чем за 2^64… что-то около 2^20. чтобы найти прообраз хеш-значения, все равно потребуется перебирать диапазон, пропорциональный выходному диапазону хеш-функции (и то, при условии ее сюрьективноcти).
Просмотров: 615 | Добавил: Breger | Рейтинг: 0.0/0
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Copyright MyCorp © 2024