Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
2автор:
думать надо.
В действительности при взломе хеша нам важен не оригинальный пароль, а поиск коллизии
почитайте определение коллизии для начала ;)
согласен, что в md5 встречаются коллизии. используйте хотя бы sha1 или sha*(256,512).
даже если добавить к тому же md5 строчку "_\*34dfklююю", его хрен подберешь
думать надо.
В действительности при взломе хеша нам важен не оригинальный пароль, а поиск коллизии
почитайте определение коллизии для начала ;)
согласен, что в md5 встречаются коллизии. используйте хотя бы sha1 или sha*(256,512).
даже если добавить к тому же md5 строчку "_\*34dfklююю", его хрен подберешь
ОФФ: Денис, завел новый аккаунт? )не узнал
Пароль не подберешь, совпадения хеша запросто.
Илья, если бы ты прошелся по ссылке на Rainbowcrack.com, то увидел, что там есть базы для паролей зашифрованных по алгоритмам LanMan (авторизация в Windows), NT LanMan (авторизация в Windows NT, в том числе сетевых доменах), MD2, MD4, MD5, SHA1, RIPEMD-160, Cisco PIX (большинство маршрутизаторов), MySQL 3.23, MySQL SHA1 (базы данных).
Илья, если бы ты прошелся по ссылке на Rainbowcrack.com, то увидел, что там есть базы для паролей зашифрованных по алгоритмам LanMan (авторизация в Windows), NT LanMan (авторизация в Windows NT, в том числе сетевых доменах), MD2, MD4, MD5, SHA1, RIPEMD-160, Cisco PIX (большинство маршрутизаторов), MySQL 3.23, MySQL SHA1 (базы данных).
Пароль не подберешь, совпадения хеша запросто.
не так уж и запросто ;) если есть база с украденными хешами, можно подобрать какой-то небольшой процент совпадений при условии, что в наличие есть мощная распределенная система вычислений, даже если используются оптимальные структуры хранения данных.
пока Rainbowcrack.com - это всего лишь проект, пытающийся срубить немного денег
не так уж и запросто ;) если есть база с украденными хешами, можно подобрать какой-то небольшой процент совпадений при условии, что в наличие есть мощная распределенная система вычислений, даже если используются оптимальные структуры хранения данных.
пока Rainbowcrack.com - это всего лишь проект, пытающийся срубить немного денег
Илья, какие украденные хешы? Их можно расчитать самостоятельно. Да, объем работы большой, но он все равно конечный. А значит или такие базы уже есть или скоро будут.
ну а как подбирать пароль? ;) вводишь начальный хэш, значение которого тебе надо,
а система ищет совпадения и возращает результат. хэш, значение которого тебе надо, ты где возьмешь? ;)
в базах будут только "чистые" хэши без всяких дополнительных данных.
а нормальные программисты не будут писать авторизационные системы, использую лишь стандартные средства
а система ищет совпадения и возращает результат. хэш, значение которого тебе надо, ты где возьмешь? ;)
в базах будут только "чистые" хэши без всяких дополнительных данных.
а нормальные программисты не будут писать авторизационные системы, использую лишь стандартные средства
Это если точно знать алгоритм создания хэша. Если используется "соль" то искать соответствевие неизвестно чему неизвестно как созданному...
Насчет конечный - посмотрите выкладки. Даже при использовании кириллицы объем базы для md5 гигантский.
Насчет конечный - посмотрите выкладки. Даже при использовании кириллицы объем базы для md5 гигантский.
пока можно подобрать таким образом только очень простые пароли горе-пользователей.
гораздо проще выудить пароль другими методами (соц.инженерия)
гораздо проще выудить пароль другими методами (соц.инженерия)
А можно коротко и понятно, для далёких, небольшой курс математики по теме?
в двух словах не расскажешь.. почитайте "Структуры и алгоритмы обработки данных" и "Кодирование"
Нет, нет, вообще сам принцип, как вообще и что такое хэш пароля :) Хотя пойду в вики посмотрю.
Кэш - специальная ф-ция у которой нету обратной. Тоесть вы делаете cacheGenerator('somepassword') а она вам - некоторую строку. Прикол в том, что имея строку вы не получите обратно 'somepassword'. Поэтому и на сервисах часто не высылают вам пароль а вы просто задаете новый (при восстановлении).
2автор:
А вообще попробуйте подобрать хоть один пароль более-менее злого админа - у вас ничего не получится. А пароль админа - вот оно главное где :)
2автор:
А вообще попробуйте подобрать хоть один пароль более-менее злого админа - у вас ничего не получится. А пароль админа - вот оно главное где :)
Недавно на хабре проскакивала ссылка на поисковик по хешам в стиле гугла. Выглядит симпатично и в базе 49,207,518 md5/sha1 хешей.
Это не для рекламы, просто приведенные в статье поисковики поскромнее.
Это не для рекламы, просто приведенные в статье поисковики поскромнее.
Ну по идее, если использовать "соль", то все не так уж страшно. Но надо только хранить в секрете алгоритм, по которому эта "соль" накладывается.
> надо только хранить в секрете алгоритм
Не стоит полагаться на секретность алгоритма. Не просто так в современном криптоанализе предполагают, что злоумышленнику полностью известен алгоритм, но неизвестен ключ. Да и набросанный «на коленке» заумный алгоритм может на деле оказаться уязвимым, лучше использовать стандартные (не спрашивайте какие, не знаю).
Не стоит полагаться на секретность алгоритма. Не просто так в современном криптоанализе предполагают, что злоумышленнику полностью известен алгоритм, но неизвестен ключ. Да и набросанный «на коленке» заумный алгоритм может на деле оказаться уязвимым, лучше использовать стандартные (не спрашивайте какие, не знаю).
в общем пароль в виде хэша хранить вполне безопасно. главное - какой метод хэширования вы будете использовать и какие дополнительные меры применять.
подобрать/взломать можно что угодно. есть закономерность между временем и средствами, чего-то всегда не хватает ;)
подобрать/взломать можно что угодно. есть закономерность между временем и средствами, чего-то всегда не хватает ;)
Вопрос на самом деле в другом.
В unixlike, например пароли хранятся в shadow в виде md5. Действительно, подобрать комбинацию символов, имеющую md5, равную сохраненной, нетрудно. Только немного долго. Но базы хэшей и распараллеливание вычислений решают проблему. Вопрос в другом. чтение shadow возможно только при наличии доступа с id=0, т.е. рута. Если доступ такого уровня получен, то на какой нам сдались пароли пользователей с id>0?
Согласен, ситуации существуют, но все-же не проще ли создать нового пользователя, поменять пароль существующему или еще что-то.
Та-же история с паролями пользователей в СУБД веб-сайта. Если злоумышленник получил доступ на выполнение sql-запросов, то бояться, что он расшифрует пароли немного поздновато.
На мой взгляд, хэширование паролей защищает только от не в меру любопытных админов. И в этом его цель.
Кстати никто не мешает видоизменить алгоритм расчёта так, чтобы он выдавал md5-подобную ерунду. Поиск таких хэшей по базе ничего не даст, придется копировать алгоритм и считать заново.
В unixlike, например пароли хранятся в shadow в виде md5. Действительно, подобрать комбинацию символов, имеющую md5, равную сохраненной, нетрудно. Только немного долго. Но базы хэшей и распараллеливание вычислений решают проблему. Вопрос в другом. чтение shadow возможно только при наличии доступа с id=0, т.е. рута. Если доступ такого уровня получен, то на какой нам сдались пароли пользователей с id>0?
Согласен, ситуации существуют, но все-же не проще ли создать нового пользователя, поменять пароль существующему или еще что-то.
Та-же история с паролями пользователей в СУБД веб-сайта. Если злоумышленник получил доступ на выполнение sql-запросов, то бояться, что он расшифрует пароли немного поздновато.
На мой взгляд, хэширование паролей защищает только от не в меру любопытных админов. И в этом его цель.
Кстати никто не мешает видоизменить алгоритм расчёта так, чтобы он выдавал md5-подобную ерунду. Поиск таких хэшей по базе ничего не даст, придется копировать алгоритм и считать заново.
Хеширование - это дополнительная защита для тех пользователей, которые используют один пароль для доступа к разным ресурсам. Если хакер разрабатывает конкретного юзера, то он может искать дыры во всех сервисах, которыми пользует этот юзер, чтобы собрать о нём максиум информации - включая варианты паролей, которые тот выбирает. Собрав несколько таких паролей очень часто можно подобрать пароль к другому сервису, который просто взломать пока не удалось (gmail, например).
Ведь неважно введем мы пароль 76854 или Fhndkts если md5('76854') будет совпадать с md5('наша_секретная_строка'.'Fhndkts').
Это почему? Ведь система будет проверять md5('наша_секретная_строка'.'76854'), т.е. совпадать должны именно md5('наша_секретная_строка'.'76854') == md5('наша_секретная_строка'.'Fhndkts').
Действительно. Только это ничего не меняет? Все равно совпадения возможны.
только паролем всё же защищают не очень ценные данные. вернее даже, паролем вообще ничего не защищают. Связка ил логина и пароля всего лишь средство аутентификации, то есть однозначного опознания вас, как владельца информации. Да и то, к слову, очень примитивное. Те же *Token-ы гораздо лучше реализуют эту функциональность. Но всем пользователям сайта свисток не дашь, а работать как-то надо.
А раз так, то и париться не о чем.
Если вам действительно нужно сохранить важные данные, то вы будете пользоваться алгоритмами не хэширования, а криптования, а ваша машина вряд ли будет выставлена в сеть на потеху бот-сетям и брутфорсерам.
А раз так, то и париться не о чем.
Если вам действительно нужно сохранить важные данные, то вы будете пользоваться алгоритмами не хэширования, а криптования, а ваша машина вряд ли будет выставлена в сеть на потеху бот-сетям и брутфорсерам.
вообще говоря не понял, почему md5(md5(строка)) получить так же просто
Хранение md5 вместо пароля достаточно сильно повышает безопасность в некоторых случаях.
Другое дело что многие из обозначенных "начинающих разработчиков", которые об этом говорят, а так же те кто их слушает, не всегда точно понимают каким образом. Они слишком полагаются на это волшебное "шифрования", а некоторыми своими действиями просто уничтожают всякий эффект от него.
Однако, заметка, ИМХО, бред. Ни в какую современную базу все варианты не влезут.
Даже с учетом существования баз с md5 частовстречающихся паролей, они никак не помогут для md5(md5). Для такого варианта нужно иметь такую же отдельную базу. Для md5(md5(md5)) третью.
Другое дело что многие из обозначенных "начинающих разработчиков", которые об этом говорят, а так же те кто их слушает, не всегда точно понимают каким образом. Они слишком полагаются на это волшебное "шифрования", а некоторыми своими действиями просто уничтожают всякий эффект от него.
Однако, заметка, ИМХО, бред. Ни в какую современную базу все варианты не влезут.
Даже с учетом существования баз с md5 частовстречающихся паролей, они никак не помогут для md5(md5). Для такого варианта нужно иметь такую же отдельную базу. Для md5(md5(md5)) третью.
Двойной md5 для простых паролей в базах есть.
Введите например на passcracking.com хещ d9b1d7db4cd6e70935368a1efb10e377
Введите например на passcracking.com хещ d9b1d7db4cd6e70935368a1efb10e377
Практически любой, даже начинающий разработчик, скажет вам, что пароли в базе надо хранить только в виде хеша (например md5).
Практически любой, даже начинающий разработчик, скажет вам, что пароли надо хранить только в виде SHA1. Уязвимость MD5 к коллизиям известна давно. MD5 не выдерживает критики при выборе алгоритма хэширования.
Практически любой, даже начинающий разработчик, скажет вам, что пароли надо хранить только в виде SHA1. Уязвимость MD5 к коллизиям известна давно. MD5 не выдерживает критики при выборе алгоритма хэширования.
Уязвимость не вообще, а на частных случаях.
Аналогично для sha1.
Аналогично для sha1.
Тогда почему бы не использовать Whirlpool?
Если вы ничего не понимаете в криптовании - так и скажите.
В настоящее время для MD5 можно породить два исходника с одинаковой контрольной суммой. Это значит что враг у вас на фирме может немного безобидно модифицировать файл так, что его знакомый сможет сделать трояна с той же MD5-суммой. Да, проблема. Если у вас неизвестно кто релизы выпускает. В случае с паролями эта преобразуется в возможность специально создать такой хитрый пароль, который через базы не пробивается, но к которому подбирается коллизия. Ну знаете. Есть много других способов накакать самому себе в карман...
В настоящее время для MD5 можно породить два исходника с одинаковой контрольной суммой. Это значит что враг у вас на фирме может немного безобидно модифицировать файл так, что его знакомый сможет сделать трояна с той же MD5-суммой. Да, проблема. Если у вас неизвестно кто релизы выпускает. В случае с паролями эта преобразуется в возможность специально создать такой хитрый пароль, который через базы не пробивается, но к которому подбирается коллизия. Ну знаете. Есть много других способов накакать самому себе в карман...
>> Вот и как теперь хранить пароль?
Очень просто. Как хранили - так и хранить. И не заморачиваться на эту тему.
Важнее обеспечить защищенность самих данных в вашей БД. Т.е. исключить несанкционированный доступ к ней. Потому как если ваши данные заполучили злоумышленники, то тут только одно средство поможет. Тотальная смена паролей + поиск и латание "дыры".
И вообще, нельзя придумать абсолютное средство защиты. Можно лишь сделать взлом экономически (или как-то еще) не выгодным, усложнив его до определенной степени. В большенстве случаев обычного хеширования достаточно.
Очень просто. Как хранили - так и хранить. И не заморачиваться на эту тему.
Важнее обеспечить защищенность самих данных в вашей БД. Т.е. исключить несанкционированный доступ к ней. Потому как если ваши данные заполучили злоумышленники, то тут только одно средство поможет. Тотальная смена паролей + поиск и латание "дыры".
И вообще, нельзя придумать абсолютное средство защиты. Можно лишь сделать взлом экономически (или как-то еще) не выгодным, усложнив его до определенной степени. В большенстве случаев обычного хеширования достаточно.
md5(sha1(md5(sha1())))
если подберёте быстрее, чем за год — памятник гарантирован
если подберёте быстрее, чем за год — памятник гарантирован
Криптография - штука странная, если не понимаешь что делаешь, то лучше не комбинировать разные алгоритмы. С одной стороны такой подход в несколько раз замедлил скорость подбора пароля. С другой - никто не даст Вам гарантию, что таким трюков Вы сами себя не обдурили, значительно снизив кол-во возможных вариантов последнего хеша и, тем самым, значительно ускорив подбор, даже относительно одиночного md5().
Если не принимать во внимание:
Главный системный администратор компании "ЮКОС" заявил, что на современном уровне развития IT-технологий понадобится 10 лет для получения пароля доступа к их базам данных. Специалистам силовых структур потребовалось 6 минут, из них 3 - на привязывание скотчем к стулу...
то мне кажется что хэш для md5(input."123").sha1(input."456") поиск по базе, даже с известным алгоритмом не даст ровным счетом ничего.
Однако даст возможность спокойно перебирать все пароли не обращаясь к сайту.
Главный системный администратор компании "ЮКОС" заявил, что на современном уровне развития IT-технологий понадобится 10 лет для получения пароля доступа к их базам данных. Специалистам силовых структур потребовалось 6 минут, из них 3 - на привязывание скотчем к стулу...
то мне кажется что хэш для md5(input."123").sha1(input."456") поиск по базе, даже с известным алгоритмом не даст ровным счетом ничего.
Однако даст возможность спокойно перебирать все пароли не обращаясь к сайту.
Интересный по моему топик) Навевает на вот какую мысль. Если, допустим, кто-то украл базу данных с паролями в зашифрованном виде, ему требуется расшифровать пароли с целью использования их в незаконных целях.
К примеру, большой процент использует пароли от 5 до 6 символов. Всего количество вариантов паролей латинница+цифры(без учета регистра)=36^5+36^6=2237248512
Если расчитывать MD5() со скоростью 1 расчет за 0.0001 сек, то составить таблицу хешей из всех паролей займет примерно 2.5 дня.
Допустим, злоумышленник заразил вирусом 100 компьютеров, при этом он может распределить расчеты на 20 групп, чтобы 5 компьютеров обрабатывали один набор исходя из вероятности, что хотя бы 1 из 5 успешно выполнит расчеты, пока зараженный юзер не поймет, что его используют (или просто не выключит компьютер).
После всех расчетов зараженным компьютерам остается считывать очеред хешей из базы злоумышленника, и одна из 20 групп вернет результат, если пароль состоял из 5-6 символов.
Значит у злоумышленника есть очень реальные шансы завладеть личной информацией как минимум 10% взломанной базы, что его вполне удовлетворит.
Получается, что хоть и полезность алгоритма шифрования зависит обратнопропорционально от скорости его выполнения (чем быстрее можно зашифровать слово, тем лучше), при этом этот же полезный факт делает данный алгоритм менее защищенный. Вдруг в скором будущем прямой перебор всех вариантов станет вполне обычной задачей.
В итоге может быть такая ситуация, что современные методы придется в будущем менять не из-за их несовершенства, а дабы наоборот, сделать их "хуже" - увеличить время, необходимое для расчетов - делая его незначительным для единичного расчета и значительным - для множественных)
К примеру, большой процент использует пароли от 5 до 6 символов. Всего количество вариантов паролей латинница+цифры(без учета регистра)=36^5+36^6=2237248512
Если расчитывать MD5() со скоростью 1 расчет за 0.0001 сек, то составить таблицу хешей из всех паролей займет примерно 2.5 дня.
Допустим, злоумышленник заразил вирусом 100 компьютеров, при этом он может распределить расчеты на 20 групп, чтобы 5 компьютеров обрабатывали один набор исходя из вероятности, что хотя бы 1 из 5 успешно выполнит расчеты, пока зараженный юзер не поймет, что его используют (или просто не выключит компьютер).
После всех расчетов зараженным компьютерам остается считывать очеред хешей из базы злоумышленника, и одна из 20 групп вернет результат, если пароль состоял из 5-6 символов.
Значит у злоумышленника есть очень реальные шансы завладеть личной информацией как минимум 10% взломанной базы, что его вполне удовлетворит.
Получается, что хоть и полезность алгоритма шифрования зависит обратнопропорционально от скорости его выполнения (чем быстрее можно зашифровать слово, тем лучше), при этом этот же полезный факт делает данный алгоритм менее защищенный. Вдруг в скором будущем прямой перебор всех вариантов станет вполне обычной задачей.
В итоге может быть такая ситуация, что современные методы придется в будущем менять не из-за их несовершенства, а дабы наоборот, сделать их "хуже" - увеличить время, необходимое для расчетов - делая его незначительным для единичного расчета и значительным - для множественных)
В след раз пожалуйста, коментируйте по делу, а не на обум лишь бы написать, ведь мой комментарий просто описал возможную ситуацию.
Или если уж уверенно что-то утверждаете, то лучше проверить. (не в обиду). Я вот прежде чем это написать, проверил: у меня расчитывается не дольше а наоборот - на порядок быстрее. ~1.8^10-5 (0.000018)
Или если уж уверенно что-то утверждаете, то лучше проверить. (не в обиду). Я вот прежде чем это написать, проверил: у меня расчитывается не дольше а наоборот - на порядок быстрее. ~1.8^10-5 (0.000018)
а если хранится хеш md5($pass.$string), где строка в 20 символов?
Делаете sha1(md5($string . $salt)) и кладете в базу. Даже если базу украдут, я уверен, получить пароль будет крайне сложно.
Все это актуально только для популярных алгоритмов. 512-битные хэши вполне справляются со своей задачей, особенно если каким-либо образом модифицированы по сравнению со своей стандартной реализацией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Так ли безопасно хранение пароля в виде хеша