Комментарии 286
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);
}
Случайно нажал кнопку отправки.
Комментарий к коду: мало того, что секрет получается подсоленный с двух сторон кусками ключа, так еще слева и справа доклеиваются md5-подобные куски, длина которых также зависит от ключа. Таким образом, даже подобрав первый раунд md5, злоумышленнику придется сначала отыскать, где именно в строке лежит второй md5 с подсоленным секретом.
Хранение ключа — вопрос совершенно отдельной темы. Я просто хотел привести пример, как можно чуть лучше, чем тривиально, усложнить жизнь злоумышленнику с GPU.
Комментарий к коду: мало того, что секрет получается подсоленный с двух сторон кусками ключа, так еще слева и справа доклеиваются md5-подобные куски, длина которых также зависит от ключа. Таким образом, даже подобрав первый раунд md5, злоумышленнику придется сначала отыскать, где именно в строке лежит второй md5 с подсоленным секретом.
Хранение ключа — вопрос совершенно отдельной темы. Я просто хотел привести пример, как можно чуть лучше, чем тривиально, усложнить жизнь злоумышленнику с GPU.
Вы не учли, что длинны хеша md5() на сегодняшний день для хорошей защиты недостаточно по причине существования коллизий, и брутфорсом можно подобрать если не настоящий пароль, то тот, который имеет такой же md5 хеш, думаю, автор и об этом в том числе говорит.
Нужен не только более сложный алгоритм в плане вычислений, но и большая длина конечного хеша.
Нужен не только более сложный алгоритм в плане вычислений, но и большая длина конечного хеша.
Ага. 128 бит.
2^128
Перебираем по миллиарду (~2^30) паролей в секунду. Получаем 2^98 секунд. Гугл подсказывает, что это ~10^22 лет. Возраст Вселенной — примерно 10^10 лет. Т.е. получаем, что на подбор пароля с таким же хешем нам понадобится всего лишь триллион сроков существования Вселенной. Говорить не о чем:)
2^128
Перебираем по миллиарду (~2^30) паролей в секунду. Получаем 2^98 секунд. Гугл подсказывает, что это ~10^22 лет. Возраст Вселенной — примерно 10^10 лет. Т.е. получаем, что на подбор пароля с таким же хешем нам понадобится всего лишь триллион сроков существования Вселенной. Говорить не о чем:)
Я думаю человек выше имел ввиду, что существует вероятность того, что для каждого пароля существуют коллизии.
И, к сожалению, есть вероятность того, что для вашего супер длинного пароля в минимум 30 символов найдется коллизия, которая будет намного короче (например в 1 байт), и будет случайно найденна при брутофорсе.
А насчет длинны, то все банальнее. Чем длиннее хеш — тем меньше вероятность того, что такая коллизия существует или будет случайно найденна при брутофорсе.
И, к сожалению, есть вероятность того, что для вашего супер длинного пароля в минимум 30 символов найдется коллизия, которая будет намного короче (например в 1 байт), и будет случайно найденна при брутофорсе.
А насчет длинны, то все банальнее. Чем длиннее хеш — тем меньше вероятность того, что такая коллизия существует или будет случайно найденна при брутофорсе.
Ну да. md5 псевдослучайна, и вроде бы никаких эффективных способов ее обратить на текущий момент неизвестно. Значит, нет ничего лучше, чем просто перебирать разные строки и сравнивать их хеш с имеющимся.
Вероятность совпадения для каждой фиксированной строки есть 2^{-128}. Т.е. в среднем придется перебрать 2^{128}. Это очень, очень долго.
Конечно, среди паролей длиной в 30 символов есть такие, чьи хеши совпадают с хешами каких-то более коротких паролей. Почти наверняка есть и с хешем, совпадающим с хешем однобуквенного пароля. Но вероятность наткнуться на такой пренебрежимо мала.
Вероятность совпадения для каждой фиксированной строки есть 2^{-128}. Т.е. в среднем придется перебрать 2^{128}. Это очень, очень долго.
Конечно, среди паролей длиной в 30 символов есть такие, чьи хеши совпадают с хешами каких-то более коротких паролей. Почти наверняка есть и с хешем, совпадающим с хешем однобуквенного пароля. Но вероятность наткнуться на такой пренебрежимо мала.
Не могу не процитировать древний баян: «edonkey — крупнейшая сеть для восстановления файлов по их md5-хэшу»
Вы забываете, что есть так называемый «парадокс дней рождений», который парадоксом на самом деле не является. В соответствии с ним для нахождения коллизии нам требуется перебрать лишь квадратный корень от длины ключа [случайных] сообщений, чтобы наткнуться на коллизию со значением, которое вы мне предоставили. Т. е. при длине в хэша 128 бит я переберу не 2^128 строк, а всего лишь sqrt(2^128) == 2^64, что тоже не так уж и мало, но уже достаточно, чтобы успешно осуществить перебор. К тому же никто не запрещает распараллелить перебор на большом количество ядер/машин. Например, одна пойдет перебирать с начала, вторая – с конца.
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
Отлично, распараллелите на миллиард ядер. Тогда Вам понадобится всего лишь тысяча сроков существования Вселенной)
Отлично, распараллелите на миллиард ядер. Тогда Вам понадобится всего лишь тысяча сроков существования Вселенной)
На миллиарде ядер, которые могут выполнять по миллион переборов в секунду, нужно будет всего 5 часов.
10^9 ядер
10^6 операций в секунду
5 часов < 10^5 секунд
10^20 < 2^70 вариантов
А для нахождения пароля, дающего такой же 128-битный хеш, что и наш, надо в среднем 2^128 попыток. Вы немного обсчитались.
10^6 операций в секунду
5 часов < 10^5 секунд
10^20 < 2^70 вариантов
А для нахождения пароля, дающего такой же 128-битный хеш, что и наш, надо в среднем 2^128 попыток. Вы немного обсчитались.
в секунду выходит 10^15 операций. или 3.6 * 10^18 в час
2^64 = 1.8*10^19
Делим первое на второй, получаем 5.124. Для нахождения пароля, как говорили выше, достаточно 2^64 попыток (в большинстве случаев).
2^64 = 1.8*10^19
Делим первое на второй, получаем 5.124. Для нахождения пароля, как говорили выше, достаточно 2^64 попыток (в большинстве случаев).
Ссылку на википедию Вы проигнорировали. Прочитайте, что такое парадокс дней рождения и для чего на самом деле достаточно 2^64. Если будут вопросы — спрашивайте, попробую объяснить:)
Я исходил и условия что такие достаточно;) В любом случае, я считаю что проблема надумана и соль вполнее ее решает (может быть в комбинированном варианте). Проблема подбора коллизии. Пароль гораздо проще получить другими способами, чем пытаться посчитать коллизию.
Проблема в следующем:
При условии, что злоумышленник знает алгоритм хеширования, соль и имеет базу хешей все пароли до 8-ми символов включительно он может с лёгкостью подобрать на современном домашнем железе.
Я не могу понять, зачем люди приплели сюда всякие дни рождения и всё остальное.
При условии, что злоумышленник знает алгоритм хеширования, соль и имеет базу хешей все пароли до 8-ми символов включительно он может с лёгкостью подобрать на современном домашнем железе.
Я не могу понять, зачем люди приплели сюда всякие дни рождения и всё остальное.
Что он сможет подобрать?
Может я не понимаю, но допустим hash=md5(md5(pass)+salt). Можно узнать, какой pass даст по этой формуле с такой-же солью нужный хеш. Но если соль поменять, то pass уже не подойдет. Т.е. можно будет залогиниться только на этот-же сайт, где взять хеши.
Пароли не скомпрометированы, результат пары дней работы кластера это возможность входа в один аккаунт. При том, что как-то с этого-же сайта уже стянули базу и код (соль). Как-то не очень осмысленно. Наверное, проще соль поместить в таком месте, где ее сложно достать, чем переходить на медленные хеши.
Может я не понимаю, но допустим hash=md5(md5(pass)+salt). Можно узнать, какой pass даст по этой формуле с такой-же солью нужный хеш. Но если соль поменять, то pass уже не подойдет. Т.е. можно будет залогиниться только на этот-же сайт, где взять хеши.
Пароли не скомпрометированы, результат пары дней работы кластера это возможность входа в один аккаунт. При том, что как-то с этого-же сайта уже стянули базу и код (соль). Как-то не очень осмысленно. Наверное, проще соль поместить в таком месте, где ее сложно достать, чем переходить на медленные хеши.
У нас есть формула:
Из этой формулы у нас известны — salt, hash и алгоритм.
Неизвестная одна — pass. Мы подбираем пароль. допустим он у нас «sex123». Теперь у нас есть пароль пользователя. Даже если сервер поменял соль:
hash=md5(md5(pass)+salt)Из этой формулы у нас известны — salt, hash и алгоритм.
Неизвестная одна — pass. Мы подбираем пароль. допустим он у нас «sex123». Теперь у нас есть пароль пользователя. Даже если сервер поменял соль:
hash2=md5(md5(pass)+salt2)
Мы уже знаем пароль пользователя — он не меняется.
Ну да, я не учел, что в случае короткого пароля, он первым и вылезет при поиске коллизии) Тем не менее — не проще ли спрятать соль? Не хранить ее на диске в открытом виде, а качественно шифруя внутри некого сервиса генерации хешей, который работает в виде бинарного файла. Такой сервис может запускаться долго (шифровать соль по какому-то 2048бит ключу среди кучи мусорных данных), но после запуска иметь соль в памяти для быстрого доступа.
security through obscurity
А вы считаете, что долгий хеш будет так уж сложно подобрать ботнетом?
Я считаю, что при наличии нормального пароля подбирать будет долго и быстрый хеш. Конечно, если производительность вырастет еще во столько же раз, во сколько она выросла с изобретения компьютеров — 128 битов может уже оказаться мало. Но на текущий момент и в ближайшей перспективе перебор 2^128 вариантов является нерешаемой задачей, даже если Вы задействуете всю существующую на планете электронику.
2^128 это минимум 20 символов пароля (24, если использовать только base64 символы). Согласитесь, заставлять пользователей массового сервиса использовать даже половину от такой сложности пароля, это не очень решаемая задача. Все равно, будут использовать sex123 и дале медленные хеши будут так-же уязвимы, как и быстрые (чуть с большими затратами).
А если сделать сильно медленный хеш, то сервис сам задолбается его считать, серверов не напасешься (еще и с видеокартами).
А если сделать сильно медленный хеш, то сервис сам задолбается его считать, серверов не напасешься (еще и с видеокартами).
Брутфорс имеет смысл только для простых паролей — коротких либо словарных. Вероятность того, что два разных простых пароля дадут с данной солью один и тот же хеш — исчезающе мала.
Я исходил и условия что такие достаточно
Расшифруйте, пожалуйста:)
Что именно Вы понимаете под подбором коллизии — нахождение какого-нибудь прообраза по данному хешу, или нахождение пары разных строк с одинаковыми хешами?
Первое требует в среднем проверки 2^128 вариантов.
Второе может быть реализовано с помощью атаки дней рождения и генерации 2^64 хешей — среди этих хешей скорее всего будут хотя бы два одинаковых. Но чем нам поможет нахождение этих двух строк?
Я просто посчитал, сколько времени нужно будет для перебора 2^64 вариантов, не более.
А, ну да. Если внезапно нам достаточно перебрать 2^64 вариантов, то всё делается быстро. А если 2^0 — то еще быстрее.
Ветка начиналась с «брутфорсом можно подобрать если не настоящий пароль, то тот, который имеет такой же md5 хеш». И для этого надо 2^128 вариантов.
Ветка начиналась с «брутфорсом можно подобрать если не настоящий пароль, то тот, который имеет такой же md5 хеш». И для этого надо 2^128 вариантов.
Отлично, распараллелите на миллиард ядер. Тогда Вам понадобится всего лишь тысяча сроков существования Вселенной)
Не стоит тратить время, доказывая невозможность того, что люди уже делают.
Тебе что-ли дать пару разных .sh скриптов с одинаковыми md5 ключами, чтобы ты поверил?
Не стоит тратить время, доказывая невозможность того, что люди уже делают.
Тебе что-ли дать пару разных .sh скриптов с одинаковыми md5 ключами, чтобы ты поверил?
Нет. Мне дать отличный от моего .sh скрипт, у которого будет то же md5 хеш:)
Вот скрипт:
Вот скрипт:
Промазал, нажал отправить:(
Прошу другой скрипт, у которого будет такой же md5, как у этого)
while [ `date +%s` -lt 1577833200 ]; do echo 'Обращение md5 на случайном входе - задача нерешаемая при нынешних мощностях'; done
Прошу другой скрипт, у которого будет такой же md5, как у этого)
Вы это — habrahabr.ru/post/113127/ — читали, конечно же?:)
Я это, конечно же, читал. Но я не прошу Вас предъявить пару разных строк с одинаковыми хешами. Я прошу предъявить строку, отличную от моей, у которой такой же хеш.
Изначально речь была именно об этом:
Изначально речь была именно об этом:
И, к сожалению, есть вероятность того, что для вашего супер длинного пароля в минимум 30 символов найдется коллизия, которая будет намного короче (например в 1 байт), и будет случайно найденна при брутофорсе.
Ситуация примерно такая: kingpin предложил метод, не подходящий к изначальной задаче. Он был неправ. Но дальше ты начал говорить о том, что данный метод невозможно использовать из-за огромных временных затрат. Это неверно, о чём я и сообщил. Метод работает вполне быстро (особенно после нескольких технологических прорывов, касающихся конкретно MD5).
Поддерживаю. Причем есть же ботнеты, которые брутят разные хэши паролей толпой в том числе и на гпу.
это здесь не причем. парадокс дней рождения применим к нахождению случайных коллизий, и по последним данным это можно сделать значительно быстрее, чем за 2^64… что-то около 2^20. чтобы найти прообраз хеш-значения, все равно потребуется перебирать диапазон, пропорциональный выходному диапазону хеш-функции (и то, при условии ее сюрьективноcти).
А с чего вы взяли, что на сервисе не шифруются какие-либо данные пользователя его паролем? В этом случае другой пароль с таким же хэшем бесполезен.
В целом вы правы, я немного разогнался с этим утверждением, но некоторые размышления на эту тему всё же напишу.
Скрытый текст
За это время вы переберете все вообще существующие комбинации.
Я подсчитал, что большая ферма видеокарт (современный суперкомпьютер) может уложиться в возраст Вселенной, а если посчитать, сколько комбинаций он сможет высчитать за год — это примерно 0,00 000 001% от всех возможных комбинаций в природе. Да, это мало, но это от всех вообще возможных комбинаций.
Конечно, это всё сказки (пока что), но мне кажется, что в обозримом будущем такой стремительный рост мощностей компьютера позволит делать подобные вычисления не только на суперкомпьютерах, но и на более доступных вещах (уже сейчас практикуются такие вещи, как вычисления на видеокартах через интернет), а раз хотя бы миллиардную часть процента (цифра выше) хешей можно будет расшифровать — это уже нельзя использовать в сферах с повышенной требовательностью к безопасности, ибо миллиардная часть от ничем не ограниченного количества возможных комбинаций паролей — это уже существенно.
Я подсчитал, что большая ферма видеокарт (современный суперкомпьютер) может уложиться в возраст Вселенной, а если посчитать, сколько комбинаций он сможет высчитать за год — это примерно 0,00 000 001% от всех возможных комбинаций в природе. Да, это мало, но это от всех вообще возможных комбинаций.
Конечно, это всё сказки (пока что), но мне кажется, что в обозримом будущем такой стремительный рост мощностей компьютера позволит делать подобные вычисления не только на суперкомпьютерах, но и на более доступных вещах (уже сейчас практикуются такие вещи, как вычисления на видеокартах через интернет), а раз хотя бы миллиардную часть процента (цифра выше) хешей можно будет расшифровать — это уже нельзя использовать в сферах с повышенной требовательностью к безопасности, ибо миллиардная часть от ничем не ограниченного количества возможных комбинаций паролей — это уже существенно.
А где хранить информацию? Атомов вселенной недостаточно
Ответить не могу, но почему-то вспомнил Билла Гейтса и 64 Кб
Количество атомов в наблюдаемой Вселенной составляет по разным оценкам от 4*1079 до 1081
Количество атомов в наблюдаемой Вселенной составляет по разным оценкам от 4*1079 до 1081
Случайно речь не про 640кб и цитата 1981 года? Если да, то это глубокое заблуждение:
No! That makes me so mad I can't believe it! Do you realize the pain the industry went through while the IBM PC was limited to 640K? The machine was going to be 512K at one point, and we kept pushing it up. I never said that statement–I said the opposite of that.
Gates talks
No! That makes me so mad I can't believe it! Do you realize the pain the industry went through while the IBM PC was limited to 640K? The machine was going to be 512K at one point, and we kept pushing it up. I never said that statement–I said the opposite of that.
Gates talks
И вы ему верите?
Помните, телемост с америкой и случай с «в СССР секса нет». Потом та дама тоже утверждала, что говорила она ровно противоположное. Однако, свидетели ещё живы и, при желании, можно найти видео (кстати, сказала она и не ту фразу, которую ей приписывают, но и не ту, на которой она настаивала постфактум. Реальный вариант ещё смешнее).
Так что я бы не полагался на отмазки дяди Билла.
Помните, телемост с америкой и случай с «в СССР секса нет». Потом та дама тоже утверждала, что говорила она ровно противоположное. Однако, свидетели ещё живы и, при желании, можно найти видео (кстати, сказала она и не ту фразу, которую ей приписывают, но и не ту, на которой она настаивала постфактум. Реальный вариант ещё смешнее).
Так что я бы не полагался на отмазки дяди Билла.
Там дама спросила даму, есть ли у них [т.е., у нас] такое же обилие секса в рекламе. Дама ответила даме, мол, нет [у нас в рекламе] никакого секса [как и рекламы] и мы категорически против этого [что такое реклама?].
Т.е., в принципе, можно понять, что она имела в виду, что сказала и что хотела сказать. :)
Всё верно, — она говорила ровно противоположное. %)
Т.е., в принципе, можно понять, что она имела в виду, что сказала и что хотела сказать. :)
Всё верно, — она говорила ровно противоположное. %)
Угу. Только она сказала «ровно противоположное» и тому, что утверждала постфактум :). Вы помните, потом она утверждала, что сказала тогда «в ссср секса нет, а есть любовь и дружба». Ни слова ни о телевидении, ни о рекламе.
А на телемосте все всё правильно поняли. Поржали, потом сквозь смех поправили, — в СССР секс есть, нет рекламы. Американцам, кстати, этот выкрик из зала не перевели, они потрясённо молчали, потом кто-то тихонько спросил что-то вроде, — а откуда у вас дети беруться :)
Всё правильно. Я это и привёл с целью демонстрации того, что последующие утверждения автора высказывания вполне могут отличаться как от того, что им приписывает молва, так и от того, что он в действительности сказал. Поэтому утверждениям Гейтса о том, что сказал Гейтс в начале времён вера ровно такая же, как и исходной урбан-легенд. Нужен независимый источник.
А на телемосте все всё правильно поняли. Поржали, потом сквозь смех поправили, — в СССР секс есть, нет рекламы. Американцам, кстати, этот выкрик из зала не перевели, они потрясённо молчали, потом кто-то тихонько спросил что-то вроде, — а откуда у вас дети беруться :)
Всё правильно. Я это и привёл с целью демонстрации того, что последующие утверждения автора высказывания вполне могут отличаться как от того, что им приписывает молва, так и от того, что он в действительности сказал. Поэтому утверждениям Гейтса о том, что сказал Гейтс в начале времён вера ровно такая же, как и исходной урбан-легенд. Нужен независимый источник.
только что пересмотрел отрывок телемоста, по контексту понятно что нет «секса» на телевидении… да и рекламы практически не было…
Из нас троих: alekciy, dime и Билла Гейтса на указанный конфе был только последний. Более того, обсуждаемая фраза ему и принадлежит. Так, что ему, как автору, наверное виднее из нас троих, что он там имеел в виду. Поэтому да, верю. Тем паче отлично знаю, как могут искажаться фразы при вырывании их из контекста.
Ну-у-у. Я же специально про «секса нет» упомянул.
Из нас четверых вас, меня, госпожи Ивановой (или как её там — пусть будет Ивановой) и Билла Гейтса, только госпожа Иванова была на том телешоу. Я его видел по телеку, вы — не знаю, а дядя Билл точно не смотрел.
Собираем вместе — госпожа Иванова утверждает, что упомянутую фразу ей приписали. И утверждает, что она сказала иное (фигня про любовь и дружбу).
Я — действительно приписали. Но и то, что она утверждает сейчас тоже не то, что она тогда говорила! И то, что прозвучало в реальности, всё же ближе к народной молве, нежели к её последующим утверждениям Проверить можно по сохранившимся записям.
Вы — ???
Билл — ему пофиг.
Итого — никому верить нельзя (ц) /но иногда можно свидетелям — свидетельские показания к истине оказались ближе, нежели показания ответчика./
Из нас четверых вас, меня, госпожи Ивановой (или как её там — пусть будет Ивановой) и Билла Гейтса, только госпожа Иванова была на том телешоу. Я его видел по телеку, вы — не знаю, а дядя Билл точно не смотрел.
Собираем вместе — госпожа Иванова утверждает, что упомянутую фразу ей приписали. И утверждает, что она сказала иное (фигня про любовь и дружбу).
Я — действительно приписали. Но и то, что она утверждает сейчас тоже не то, что она тогда говорила! И то, что прозвучало в реальности, всё же ближе к народной молве, нежели к её последующим утверждениям Проверить можно по сохранившимся записям.
Вы — ???
Билл — ему пофиг.
Итого — никому верить нельзя (ц) /но иногда можно свидетелям — свидетельские показания к истине оказались ближе, нежели показания ответчика./
Я про конкретную фразу в 640кб, давайте сюда не будем приплетать Иванову. Эта два абсолютно разных случая с абсолютно разными людьми.
А чем они разные? Прямая аналогия.
Человеку приписано (либо он действительно так сказал) нечто, в чём ему сейчас неприятно признаваться, либо выглядит вообще полной глупостью. Человек пытается оправдаться выдвигая собственную версию. Она не совпадает с приписываемой и, скорее всего, не совпадает и с реальной. Кто кроме самого Билла подтверждает его утверждения постфактум? Кто, кроме Ивановой подтверждает её утверждения постфактум?
Человеку приписано (либо он действительно так сказал) нечто, в чём ему сейчас неприятно признаваться, либо выглядит вообще полной глупостью. Человек пытается оправдаться выдвигая собственную версию. Она не совпадает с приписываемой и, скорее всего, не совпадает и с реальной. Кто кроме самого Билла подтверждает его утверждения постфактум? Кто, кроме Ивановой подтверждает её утверждения постфактум?
>И вы ему верите?
Я ему не только верю, но и благодарен. Благодарен за то, что он с дикими усилиями выбил из IBM, которая делала собственно компьютеры (а что, есть дураки, которые думают, что эти 634Kb пошли из софта?), эти самые 640 килобайт. Если бы не он, жили бы с 500 килобайтами.
Что он сказал (в 1981 году, спустя лет 6 лет после), так это, что он надеялся, что сумел оттянуть время, когда памяти перестанет хватать, на 10 лет, но хватило только на 6.
Я ему не только верю, но и благодарен. Благодарен за то, что он с дикими усилиями выбил из IBM, которая делала собственно компьютеры (а что, есть дураки, которые думают, что эти 634Kb пошли из софта?), эти самые 640 килобайт. Если бы не он, жили бы с 500 килобайтами.
Что он сказал (в 1981 году, спустя лет 6 лет после), так это, что он надеялся, что сумел оттянуть время, когда памяти перестанет хватать, на 10 лет, но хватило только на 6.
тут еще стоить учесть, что с каждым годом производительность компьютеров растет, а что еще более важно, стоимость FLOPS падает за каждый год почти в два раза (http://en.wikipedia.org/wiki/FLOPS). и такой «суперкомпьютер» значительно проще будет иметь одному пользователю через несколько лет.
Закон Мура в действии
на самом деле там 2123.4, так что время немного уменьшится. Дело в том, что вычисленные, пусть и на видеокартах данные (таблицы) нужно где-то хранить, с этим пока не так гладко.
www.springerlink.com/content/d7pm142n58853467
www.springerlink.com/content/d7pm142n58853467
Если вспомнить про парадокс дней рождений то на оакажется, что на самом деле достаточно ~ sqrt(2^128) = 2^64 итераций чтобы найти коллизию. Это примерно ~500 лет, то есть имея достаточные средства на железо можно построить вполне рабочую систему для поиска коллизий.
Кстати, пару лет назад я слышал про проект, в котором подключали компьюетры всех желающих для поиска как раз хешей (не уверен что это был MD5).
Чтобы защититься от этой атаки достаточно использовать хеш-функцию с большей длиной хеша. Например SHA-256
Кстати, пару лет назад я слышал про проект, в котором подключали компьюетры всех желающих для поиска как раз хешей (не уверен что это был MD5).
Чтобы защититься от этой атаки достаточно использовать хеш-функцию с большей длиной хеша. Например SHA-256
2^64 итераций потребуется чтобы найти два СЛУЧАЙНЫХ блока с одинаковым хешем, это ни в коем случае не поможет вычислить коллизию для заданного значения. И если уж говорить о таком случае то ни о каких 500 годах и речи нет. 15 секунд на пентиуме 4. habrahabr.ru/post/113127/ (соори за саморекламу).
Парадокс дней рождения заключается, что в выборке размером в корень из числа возможных вариантов скорее всего будут коллизии. Но он никак не помогает в нахождении прообраза для фиксированного хеша (или даже для какого-нибудь из фиксированного миллиарда хешей).
Да, до полного перебора далеко. Но автор md5crypt утверждает что любой 8ми символьный пароль, зашифрованный md5crypt, уже сейчас может быть вскрыт за пару дней. Если учесть что md5crypt как минимум в 1000 раз медленнее простого md5, получается при простом хешировании через md5 любой восьмисимвольный пароль можно вскрыть за полчаса. :)
Понятно, что такой брутфорсер пока недоступен массам взломщиков, но это, согласитесь, неприятно.
Понятно, что такой брутфорсер пока недоступен массам взломщиков, но это, согласитесь, неприятно.
что ж я тогда над гибридным GPU-брутфорсером бился, ежели 8 символов можно за полчаса вскрыть. Да, в случае алфавита из символов одного регистра — так, но это несколько странно, использовать пароль из 8 символов, без спецзнаков. Тогда, вероятно это просто слово из словаря, которое можно найти за секунды.
Ну вы в общем то, надеюсь, понимаете что утверждение «пароль из 8 символов, без спецзнаков. Тогда, вероятно это просто слово из словаря, которое можно найти за секунды» в общем и целом неверно?
Я даже рискну предположить что большинство паролей именно такие, но далеко они не все словарные — врядли у кого есть словарь на 302231454903657293676544 паролей.
Про полчаса я конечно был не прав, но Камп ссылается именно на это
И это в общем то не предел, скорости GPU растут.
Я даже рискну предположить что большинство паролей именно такие, но далеко они не все словарные — врядли у кого есть словарь на 302231454903657293676544 паролей.
Про полчаса я конечно был не прав, но Камп ссылается именно на это
И это в общем то не предел, скорости GPU растут.
ну и вы, надеюсь, представляете, что словарный пароль — не только тот, который лежит в некотором файле из 3022… паролей, а еще тот, который легко декомпозируется на несколько (скажем до трех) строк из словаря среднего размера. Для подобной техники не трудно написать программу, а оставшиеся 2-3 процента паролей в случае массового аудита не так интересны (это в общем-то даже целая задача, придумать пароль из 8 маленьких символов, который нельзя разумно декомпозировать по стокилобайтному словарю).
Вот Вам решение этой задачи:)
from random import choice
from string import lowercase
print ''.join([choice(lowercase) for i in range(8)])
Я так понял, что автор предполагал все таки более интелектуальную декомпозицию, по аналогии с описанной в habrahabr.ru/post/122633/
слово «разумно» вы проигнорировали :)
Простите, даже специально перечитывал несколько раз ваше сообщение, но не уловил сути. В теории — декомпозируйте любой словарь хоть сколько угодно раз вы и близко не приблизитесь к цифре в 3022… паролей. А если говорить о реальности — какой процент реальных паролей <= 8 символов является словарным — то все зависит от словаря с одной стороны и от паролей с другой. Тут можно долго теоретизировать — реальных цифр все равно взять неоткуда.
Ну почему неоткуда? В открытом доступе есть куча слитых паролей.
И было высказано утверждение «это в общем-то даже целая задача, придумать пароль из 8 маленьких символов, который нельзя разумно декомпозировать по стокилобайтному словарю». Приведенный мной код решает эту задачу)
И было высказано утверждение «это в общем-то даже целая задача, придумать пароль из 8 маленьких символов, который нельзя разумно декомпозировать по стокилобайтному словарю». Приведенный мной код решает эту задачу)
Выскажу тоже предположение — что ваши что мои слова это пустое сотрясание воздуха. В теории — это 302231454903657293676544 паролей даже без цифр и в теории же ничтожная часть паролей словарны. Есть желание проверить практику — можете заняться проверкой, я буду лучше использовать хеши понадежнее, помедленнее и предназначенные для хеширования паролей, благо это ничего не стоит.
Еще раз. sic утверждал, что придумать словарь из 8 символов, не декомпозирующийся по словарю — задача сложная. Я указал, что это не так.
А откуда Вы взяли именно число 2^78, если не секрет?) Это явно гораздо больше, чем 8символьных паролей (которых, очевидно, меньше 2^64).
А откуда Вы взяли именно число 2^78, если не секрет?) Это явно гораздо больше, чем 8символьных паролей (которых, очевидно, меньше 2^64).
А если брать пароль, брать от него SHA2, делить SHA2 на 3 части, каждую часть в md5 и склеивать через три символа (1 символ из первого хэша второй из второго третий из третьего)?
Если количество символов не меняется — это только защита от радужных таблиц, но не от коллизий и полного перебора.
Как вы собираетесь перебирать кашу из трех склееных хэшей? Более того можно задать правило по которому они будут перемешиваться.
Видимо, также как и вытащил твой хеш, хацкер вытащит твой алгоритм.
Крайне не рекомендуется что-то выдумывать в области безопасности, тем более, такой бред.
Лучше следовать рекомендациям, придуманным умными людьми, и делать это аккуратно.
Крайне не рекомендуется что-то выдумывать в области безопасности, тем более, такой бред.
Лучше следовать рекомендациям, придуманным умными людьми, и делать это аккуратно.
Думать нужно не о мешанине, а о расходе ресурсов потенциального хакера. Уж лучше 100 раз делать SHA с солью, чем заниматься ерундой.
А чтоб собственный сервер не сдох при авторизации, делать первые Х итераций на стороне клиента, а У на стороне сервера. Соотношение Х/У зависит от того что важнее доступ к сервису или пароль конечного пользователя.
А чтоб собственный сервер не сдох при авторизации, делать первые Х итераций на стороне клиента, а У на стороне сервера. Соотношение Х/У зависит от того что важнее доступ к сервису или пароль конечного пользователя.
Или использовать OTP.
Далее — в вопросах разработки и оценки безопасности систем хорошо было бы руководствоваться чем-то вроде en.wikipedia.org/wiki/Kerckhoffs's_principle.
С этой точки зрения ваше
> даже подобрав первый раунд md5, злоумышленнику придется сначала отыскать, где именно в строке лежит второй md5 с подсоленным секретом.
это security by obscurity, которое никакой security не является вообще.
И рассматривать скорее худший случай, когда о вашей системе всё известно. В этом случае посоленные одинаковой солью пароли менее стойки, чем посоленные рандомными и своими для каждого из паролей.
С этой точки зрения ваше
> даже подобрав первый раунд md5, злоумышленнику придется сначала отыскать, где именно в строке лежит второй md5 с подсоленным секретом.
это security by obscurity, которое никакой security не является вообще.
И рассматривать скорее худший случай, когда о вашей системе всё известно. В этом случае посоленные одинаковой солью пароли менее стойки, чем посоленные рандомными и своими для каждого из паролей.
Хочу привести ссылку на комент недавней статьи, где есть хорошая ссылка на другой комент
habrahabr.ru/post/145448/#comment_4887222
Тем кому лень. Нет надёжного метода, причина — короткие и простые пароли юзеров.
habrahabr.ru/post/145448/#comment_4887222
Тем кому лень. Нет надёжного метода, причина — короткие и простые пароли юзеров.
Соль должна быть рандомная и уникальная для каждого из паролей.
Все пляски вокруг вырезания подстроки из md5 от соли и добавления к паролю АБСОЛЮТНО никакой криптостойкости не прибавляют.
Все пляски вокруг вырезания подстроки из md5 от соли и добавления к паролю АБСОЛЮТНО никакой криптостойкости не прибавляют.
Согласен. Можно так же менять соль и хеш при каждой успешной авторизации.
Это ничего не изменит.
Разве? Пи атаке на коллизиях, если подбор коллизии занимает неделю, а хэш меняется каждый день, то смысла искать коллизии нет, только восстанавливать оригинальное значение пароля.
Ну я, вообще говоря, говорил о позиции с точки зрения пользователя и защищённости его пароля от узнавания.
Далее — если вы взломщик и получили какое-то мгновенное значение соли и хэша — то опять же факт что эта соль была изменена за секунду до взлома, и будет изменена через секунду после точно так же ничего не изменит, потому что у вас уже есть мгновенное значение.
Далее — если вы взломщик и получили какое-то мгновенное значение соли и хэша — то опять же факт что эта соль была изменена за секунду до взлома, и будет изменена через секунду после точно так же ничего не изменит, потому что у вас уже есть мгновенное значение.
При факте взлома — принудительная смена пароля. Да и можно, ли говорить о безопастности, если хакер уже всё знает :).
Мы говорим о защите пароля пользователя, потому как есть ненулевой шанс, что он его использовал где-то ещё.
Мы говорим о повышении криптостойкости, при подсаливании пароля. Подсаливание отметает радужные таблицы и колизии (в случае с непрямым md5). От атаки в лоб не спасёт ни какое шифрование. Всё зависит от ресурсов, которыми распологает потенциальный взломщик. Если у него дата-центр, то там как ни шифруй…
p.s. панацеи нет, есть только время взлома, с оговоркой на необходимые ресурсы.
p.s. панацеи нет, есть только время взлома, с оговоркой на необходимые ресурсы.
Пожалуйста, перечитайте всю ветку сначала.
Вы предложили менять соль после каждой авторизацию. Я сказал что это не имеет никакого смысла. М?
Вы предложили менять соль после каждой авторизацию. Я сказал что это не имеет никакого смысла. М?
Если хакер знает хеш, но незнает алгоритм — это заметно увеличит криптостойкость. Или я не прав?
Начали за здравие…
Ещё раз: вы предложили менять соль — это ничего не изменит.
Далее: Незнание алгоритма процесс усложнит, верно, но в вопросах оценки безопасности системы принято оценивать худшие случаи, когда мы полагаем, что у злоумышленника есть всё, до чего в принципе возможно дотянуться.
Ещё раз: вы предложили менять соль — это ничего не изменит.
Далее: Незнание алгоритма процесс усложнит, верно, но в вопросах оценки безопасности системы принято оценивать худшие случаи, когда мы полагаем, что у злоумышленника есть всё, до чего в принципе возможно дотянуться.
Ссори за нубский вопрос и за спасибо за терпение :), но какой тогда вообще смысл в защите информации, если у хакера уже есть всё, до чего возможно дотянутся?
Смысл в том (я повторяю это уже во второй раз), чтобы сделать процесс получения исходного пароля пользователя экономически невыгодным.
А зачем ему пароль? У него уже есть вся информация.
Затем, что этот же пароль пользователь может использовать, к примеру, на пейпале. Или на гмейле. (это я тоже уже говорил, хоть это и очевидно)
Спасибо, что разжевали…
Было бы интересно узнать, какой способ защиты вы предложите.
Я в этой самой ветке уже предлагал в самом начале. Видимо всё придётся повторять дважды: использовать рандомную соль, для каждого пароля свою
Вы же выше писали, что
Тогда получается зачем вообще солить? Кормим брутфорсу соль и сидим так же ждём.
в вопросах оценки безопасности системы принято оценивать худшие случаи, когда мы полагаем, что у злоумышленника есть всё, до чего в принципе возможно дотянуться.
Тогда получается зачем вообще солить? Кормим брутфорсу соль и сидим так же ждём.
О боже мой, солить для того, чтобы нельзя было использовать радужные таблицы. А разная соль нужна, чтобы каждый пароль пришлось брутить отдельно.
«чтобы каждый пароль пришлось брутить отдельно» и как это спасёт пароль? Зачем кому-то брутить всю базу юзеров? Всегда достаточно одного.
Отсюда получается, что уникальность соли — рута не спасёт. Как и любого другого юзера.
Я устал повторять очевидные вещи, но я всё таки сделаю это в последний раз: соль призвана не защитить на 100% пароль (защита системы от взлома вообще никак к соли не относится), а сделать брутфорс экономически невыгодным.
Пароли для важных аккаунтов должны быть достаточно длинными (знаков 15) и составленными из букв разного регистра, цифр и спецсимволов.
Вкупе всё сказанное выше делает перебор невозможным в этом столетии.
Пароли для важных аккаунтов должны быть достаточно длинными (знаков 15) и составленными из букв разного регистра, цифр и спецсимволов.
Вкупе всё сказанное выше делает перебор невозможным в этом столетии.
«Пароли для важных аккаунтов должны быть достаточно длинными (знаков 15) и составленными из букв разного регистра, цифр и спецсимволов».
Да только не каждому это объяснишь. И к уникальности соли это никак не отсноситься. Если взломщик знает, соль и хеш жертвы, то ему всё равно какая соль у пользователя на строчку ниже или выше. Он запустит бот сеть и далее будет с чувством выполненного долга мирно похрапывать.
Да только не каждому это объяснишь. И к уникальности соли это никак не отсноситься. Если взломщик знает, соль и хеш жертвы, то ему всё равно какая соль у пользователя на строчку ниже или выше. Он запустит бот сеть и далее будет с чувством выполненного долга мирно похрапывать.
Я не понимаю, к чему вы клоните. Я рассказал зачем нужна соль и как лучше всего её применять.
> И к уникальности соли это никак не отсноситься. Если взломщик знает, соль и хеш жертвы, то ему всё равно какая соль у пользователя на строчку ниже или выше
Если жертва конкретный человек — да. Если жертвы — все пользователи из дампа, тогда не всё равно (я это уже повторил здесь минимум дважды, это третий раз).
Так или иначе — в капитана мне играть надоело. По существу у вас есть что сказать?
> И к уникальности соли это никак не отсноситься. Если взломщик знает, соль и хеш жертвы, то ему всё равно какая соль у пользователя на строчку ниже или выше
Если жертва конкретный человек — да. Если жертвы — все пользователи из дампа, тогда не всё равно (я это уже повторил здесь минимум дважды, это третий раз).
Так или иначе — в капитана мне играть надоело. По существу у вас есть что сказать?
Ну раз на то пошло, то видимо придётся роль капитана очевидности принять на себя.
— «Если у хакера есть база юзеров с хешами и солью, то ему ненужно ломать всю базу, достаточно одного юзера, который имеет права админа. Поэтому уникальная соль никакой пользы, в данном случае не даёт.»
Если же расматривать такую ситауцию в которой, взломщик не имеет прямого доступа к базе и не может узнать соль любого другого пользователя кроме своего, то да ваш вариант сработает. Но! В 90% случаев хеш и соль будет храниться в БД и скорее всего в одной таблице, поэтому узнать хеш без соли — мало вероятный сценарий.
— «Если у хакера есть база юзеров с хешами и солью, то ему ненужно ломать всю базу, достаточно одного юзера, который имеет права админа. Поэтому уникальная соль никакой пользы, в данном случае не даёт.»
Если же расматривать такую ситауцию в которой, взломщик не имеет прямого доступа к базе и не может узнать соль любого другого пользователя кроме своего, то да ваш вариант сработает. Но! В 90% случаев хеш и соль будет храниться в БД и скорее всего в одной таблице, поэтому узнать хеш без соли — мало вероятный сценарий.
Я и не говорил про узнавание хэша без соли, не знаю даже с чего вы это взяли.
Соль должна быть рандомной, она не должна быть секретной.
Я могу повторить в четвертый раз: назначение соли — уберечь от применения радужных таблиц.
> Если же расматривать такую ситауцию в которой, взломщик не имеет прямого доступа к базе и не может узнать соль любого другого пользователя кроме своего, то да ваш вариант сработает
Он сработает и с известной рандомной солью. Пожалуйста, перечитайте тред снова. А потом немного подумайте.
Повторю прошлый вопрос: по существу обсуждаемого топика (не придумывая, что я сказал) у вас есть что сказать?
Соль должна быть рандомной, она не должна быть секретной.
Я могу повторить в четвертый раз: назначение соли — уберечь от применения радужных таблиц.
> Если же расматривать такую ситауцию в которой, взломщик не имеет прямого доступа к базе и не может узнать соль любого другого пользователя кроме своего, то да ваш вариант сработает
Он сработает и с известной рандомной солью. Пожалуйста, перечитайте тред снова. А потом немного подумайте.
Повторю прошлый вопрос: по существу обсуждаемого топика (не придумывая, что я сказал) у вас есть что сказать?
Я смотрю вы людите всё считать, тогда перечитайте еще раз, что я вам пытаюсь донести. Соль не должны быть секретной? А какой толк от такой соли? Вы играете словами как жанглёр в цирке. Я вам пытаюсь донести, что знание соли, хеша и алгоритма никак не защитит от брутфорса.
Для защиты от радужных таблиц достаточно и одной соли.
И рассматривать варианты, когда хакер знает всё — бессмысленно.
Чтобы реально усложнить жизнь взломщику нужно сделать так, чтобы кол-во ключевых элементов необходимых для брутфорса было как можно больше. Чтобы это произошло нужно приблизить к нулю кол-во констант в выражении «хеш+соль+алгоритм=пароль». Следовательно алгоритм, как и соль, должен быть тоже переменной. Тем самым мы снижаем вероятность обладания сразу всеми состовляющими, «с точки зрения пользователя и защищённости его пароля от узнавания».
«Подальше спрячешь — поближе возмешь»
Для защиты от радужных таблиц достаточно и одной соли.
И рассматривать варианты, когда хакер знает всё — бессмысленно.
Чтобы реально усложнить жизнь взломщику нужно сделать так, чтобы кол-во ключевых элементов необходимых для брутфорса было как можно больше. Чтобы это произошло нужно приблизить к нулю кол-во констант в выражении «хеш+соль+алгоритм=пароль». Следовательно алгоритм, как и соль, должен быть тоже переменной. Тем самым мы снижаем вероятность обладания сразу всеми состовляющими, «с точки зрения пользователя и защищённости его пароля от узнавания».
«Подальше спрячешь — поближе возмешь»
> Я смотрю вы людите всё считать, тогда перечитайте еще раз, что я вам пытаюсь донести. Соль не должны быть секретной? А какой толк от такой соли? Вы играете словами как жанглёр в цирке. Я вам пытаюсь донести, что знание соли, хеша и алгоритма никак не защитит от брутфорса.
Я НИГДЕ НЕ ГОВОРИЛ, ЧТО МОЖНО ЗАЩИТИТЬСЯ ОТ БРУТФОРСА
Толкт от соли (абсолютно не принципиально, секретной или не секретной) — защита от радужных таблиц.
> Для защиты от радужных таблиц достаточно и одной соли.
Недостаточно.
Повторю себя же: «Если у вас на руках база в 800М юзеров — то брутить каждого по отдельности или всех за раз — разница колоссальная.»
> Тем самым мы снижаем вероятность обладания сразу всеми состовляющими, «с точки зрения пользователя и защищённости его пароля от узнавания».
Я говорил не о теории вероятностей, я говорил о криптостойкости.
Я устал повторять одно и то же. Думайте что хотите. Если это прекратит этот бессмысленный диалог (в котором я повторяю одно и то же, а вы пытаетесь подход security by obscurity возвести в абсолют) и вы наконец угомонитесь писать вещи, которые вообще не о теме разговора — то «я неправ». Окей?
Я НИГДЕ НЕ ГОВОРИЛ, ЧТО МОЖНО ЗАЩИТИТЬСЯ ОТ БРУТФОРСА
Толкт от соли (абсолютно не принципиально, секретной или не секретной) — защита от радужных таблиц.
> Для защиты от радужных таблиц достаточно и одной соли.
Недостаточно.
Повторю себя же: «Если у вас на руках база в 800М юзеров — то брутить каждого по отдельности или всех за раз — разница колоссальная.»
> Тем самым мы снижаем вероятность обладания сразу всеми состовляющими, «с точки зрения пользователя и защищённости его пароля от узнавания».
Я говорил не о теории вероятностей, я говорил о криптостойкости.
Я устал повторять одно и то же. Думайте что хотите. Если это прекратит этот бессмысленный диалог (в котором я повторяю одно и то же, а вы пытаетесь подход security by obscurity возвести в абсолют) и вы наконец угомонитесь писать вещи, которые вообще не о теме разговора — то «я неправ». Окей?
Смысл в том (я повторяю это уже во второй раз), чтобы сделать процесс получения исходного пароля пользователя экономически невыгодным.
Всё верно. Рандомная соль вкупе с медленнэм алгоритмом хеширования этот процесс таковым и делает (это я повторяю в третий раз).
Вы издеваетесь?
Вы издеваетесь?
Или я пропустил первые два раза или Вы всегда с трёх начинаете считать.
Про рандомные я говорил много раз, про медленный алгоритм — вам лично сказал как минимум один раз: habrahabr.ru/post/145454/#comment_4890716
Окей, пускай не в третий, во второй.
У вас кроме этого есть что сказать? Предлагаю начать докапываться до пунктуации и орфографии.
Окей, пускай не в третий, во второй.
У вас кроме этого есть что сказать? Предлагаю начать докапываться до пунктуации и орфографии.
Я хотел тем самым обратить ваше внимание, что вы изменяете суть сказанного не в первый раз. И заметье, что в том комментарии Вы это говорили уже три раза. Я сомневаюсь, что вы вообще умеете считать.
Я не изменял сути сказанного. Пожалуйста, укажите на моменты, когда я «изменил суть сказанного». Я последователен в этом диалоге и повторяю те же тезисы из раза в раз. А вы кидаетесь от одного к другому.
Перечитайте весь тред, в этот раз «внимательно».
Хочу особо отметить, что тред начался с вашей фразы о смене соли каждый раз. Вы от этого своего предложения уже открестились что ли?
Перечитайте весь тред, в этот раз «внимательно».
Хочу особо отметить, что тред начался с вашей фразы о смене соли каждый раз. Вы от этого своего предложения уже открестились что ли?
От медленного алгоритма скорее сервер помрёт.
У вас сервер помрёт раньше от нагрузки, до того момента, как вы сможете набрать аудиторию, чтобы она (аудитория) своими авторизациями создала сколь-нибудь видимую на общем фоне нагрузку.
Это уже несколько раз (и мной, и другими людьми) обсуждалось в этом тредике. Перечитайте все обсуждения, чтобы не пришлось повторять всё по нескольку раз и в этом случае.
Это уже несколько раз (и мной, и другими людьми) обсуждалось в этом тредике. Перечитайте все обсуждения, чтобы не пришлось повторять всё по нескольку раз и в этом случае.
Вообщем бесмысленный разговор. Я свою позицию высказал. Пытался объяснить своё виденье до Вас, но весь диалого постоянно сводиться к монологу о кол-ве повторений себя же. Может стоит отложить калькулятор в сторону и людям будет проще найти взаимопонимание?
*своё виденье для Вас
Давайте отложим.
Выскажите тезисно свои мысли.
То что я уже видел от вас:
1. Нужно менять соль после авторизации — смысла не имеет
2. Соль не защищает от брутфорса — не защищает, и не должна по определению. Она его усложняет, но не делает невозможным.
3. Рандомная соль не защищает пользователей — перекликается с пунктом 2. Соль не должна защищать на 100%, она должна делать процесс невыгодным. Рандомная соль это позволяет делать.
У вас есть что ещё сказать?
Выскажите тезисно свои мысли.
То что я уже видел от вас:
1. Нужно менять соль после авторизации — смысла не имеет
2. Соль не защищает от брутфорса — не защищает, и не должна по определению. Она его усложняет, но не делает невозможным.
3. Рандомная соль не защищает пользователей — перекликается с пунктом 2. Соль не должна защищать на 100%, она должна делать процесс невыгодным. Рандомная соль это позволяет делать.
У вас есть что ещё сказать?
Вы как всегда упустили добрый кусок смысла.
ключевых элементов необходимых для брутфорса было как можно больше. Чтобы это произошло нужно приблизить к нулю кол-во констант в выражении «хеш+соль+алгоритм=пароль». Следовательно алгоритм, как и соль, должен быть тоже переменной.
ключевых элементов необходимых для брутфорса было как можно больше. Чтобы это произошло нужно приблизить к нулю кол-во констант в выражении «хеш+соль+алгоритм=пароль». Следовательно алгоритм, как и соль, должен быть тоже переменной.
Я оцениваю the worst case, когда злоумышленнику известно всё.
Весь этот пост посвящён ситуации минимизации после утечки ВСЕГО, ЧЕГО ТОЛЬКО ВОЗМОЖНО.
А то, о чём говорите вы, называется security through obscurity и секьюрити на самом деле является мало.
Вы готовы/хотите продолжить обсуждение в ключе «злоумышленнику известно всё»? (именно в этом ключе и обсуждается безопасность в этом посте и именно этому он и был посвящён)
Весь этот пост посвящён ситуации минимизации после утечки ВСЕГО, ЧЕГО ТОЛЬКО ВОЗМОЖНО.
А то, о чём говорите вы, называется security through obscurity и секьюрити на самом деле является мало.
Вы готовы/хотите продолжить обсуждение в ключе «злоумышленнику известно всё»? (именно в этом ключе и обсуждается безопасность в этом посте и именно этому он и был посвящён)
Вы классический софист. Специально для вас название поста «Автор md5crypt просит им больше не пользоваться». Могу пояснить еще раз пост вообще не про «способы использования md5 в ситации полной утечки». Пост сообщает, что нужно искать новые методы шифрования/хеширования.
Названия сути не меняет. Вы предлагаете придумать способ медленного шифрования, я же предлагаю просто увеличить, кол-во неизвестных до максимума. О чем, кстати, и говорит нам автор md5crypt, предлагая возможные векторы дальнейшего развития. Только лишь я делаю ставку на то, что хакер не сможет узнать все компоненты хеширования (алгоритм, соль и хеш), а вы делаете ставку на ресурсоёмкость алгоритма.
p.s. может кстати порекомендуете, какой-нибудь алгоритм?
А то, о чём говорите вы, называется security through obscurity и секьюрити на самом деле является мало.
Названия сути не меняет. Вы предлагаете придумать способ медленного шифрования, я же предлагаю просто увеличить, кол-во неизвестных до максимума. О чем, кстати, и говорит нам автор md5crypt, предлагая возможные векторы дальнейшего развития. Только лишь я делаю ставку на то, что хакер не сможет узнать все компоненты хеширования (алгоритм, соль и хеш), а вы делаете ставку на ресурсоёмкость алгоритма.
p.s. может кстати порекомендуете, какой-нибудь алгоритм?
Вообщем вывод из нашего диалога следующий нужна золотая середина. Вопрос как её найти?
> Вы предлагаете придумать способ медленного шифрования
Не я, но и автор md5crypt
Цитата из топика:
> Только лишь я делаю ставку на то, что хакер не сможет узнать все компоненты хеширования (алгоритм, соль и хеш), а вы делаете ставку на ресурсоёмкость алгоритма.
Вы надеетесь, что хакер не сможет узнать. Это и есть through obscurity. А я на это не полагаюсь. Я не говорю, что нужно писать как попало — естественно защищаться от утечек данных/кода нужно, но я обсуждаю возможность защиты от последствий утечки, принимая это за случившийся факт.
> p.s. может кстати порекомендуете, какой-нибудь алгоритм?
en.wikipedia.org/wiki/Bcrypt и побольше раундов
В соседних комментариях это обсуждалось.j
Не я, но и автор md5crypt
Цитата из топика:
> Только лишь я делаю ставку на то, что хакер не сможет узнать все компоненты хеширования (алгоритм, соль и хеш), а вы делаете ставку на ресурсоёмкость алгоритма.
Вы надеетесь, что хакер не сможет узнать. Это и есть through obscurity. А я на это не полагаюсь. Я не говорю, что нужно писать как попало — естественно защищаться от утечек данных/кода нужно, но я обсуждаю возможность защиты от последствий утечки, принимая это за случившийся факт.
> p.s. может кстати порекомендуете, какой-нибудь алгоритм?
en.wikipedia.org/wiki/Bcrypt и побольше раундов
В соседних комментариях это обсуждалось.j
> — «Если у хакера есть база юзеров с хешами и солью, то ему ненужно ломать всю базу, достаточно одного юзера, который имеет права админа. Поэтому уникальная соль никакой пользы, в данном случае не даёт.»
Удачного вам взлома. В случае правильного пароля — будете перебирать тысячи лет. В случае неправильного — вам никто и не говорил, что применение соли на 100% защитит от узнавания.
Я говорил (уже раза три, я начинаю сомневаться, что вы вообще умеете читать), что применение соли и медленного хеширующего алгоритма делает процесс подбора экономичесик невыгодным. Соль и защита данных от воровства НИКАК не связаны.
Пожалуйста, перестаньте отвечать в эту ветвь, по 4 или 5 раз повторять одно и то же мне уже терпения не хватит.
Удачного вам взлома. В случае правильного пароля — будете перебирать тысячи лет. В случае неправильного — вам никто и не говорил, что применение соли на 100% защитит от узнавания.
Я говорил (уже раза три, я начинаю сомневаться, что вы вообще умеете читать), что применение соли и медленного хеширующего алгоритма делает процесс подбора экономичесик невыгодным. Соль и защита данных от воровства НИКАК не связаны.
Пожалуйста, перестаньте отвечать в эту ветвь, по 4 или 5 раз повторять одно и то же мне уже терпения не хватит.
Если у вас на руках база в 800М юзеров — то брутить каждого по отдельности или всех за раз — разница колоссальная.
У него может быть только read only доступ, а хочется провести пару транзакций.
Мы ведь (и это я повторяю во второй раз) говорим о защите пароля пользователя, а не о сферической защите от сферического непонятно чего.
Уже обсуждалось: habrahabr.ru/post/136580/#comment_4544628
Если мы будем перебирать не подряд, а в случайном порядке (с возможными повторами), то изменения хеша ожидание времени перебора не увеличат.
Пусть у нас всего M возможных паролей. Тогда чтобы наткнуться на данный с вероятностью 1/2 при последовательном переборе нам надо сделать M/2 попыток.
При случайном переборе вероятность наткнуться на данный за K попыток составляет 1 — (1 — 1/M)^K.
1 — (1 — 1/M)^K = 1/2
(1 — 1/M)^K = 1/2
K*ln(1 — 1/M) = -ln(2)
K*(1/M) = ln(2)
K = M*ln(2)
Т.е. нам понадобится примерно 0.7M попыток. Что всгео лишь в полтора раза больше чем при последовательном переборе.
Если мы будем перебирать не подряд, а в случайном порядке (с возможными повторами), то изменения хеша ожидание времени перебора не увеличат.
Пусть у нас всего M возможных паролей. Тогда чтобы наткнуться на данный с вероятностью 1/2 при последовательном переборе нам надо сделать M/2 попыток.
При случайном переборе вероятность наткнуться на данный за K попыток составляет 1 — (1 — 1/M)^K.
1 — (1 — 1/M)^K = 1/2
(1 — 1/M)^K = 1/2
K*ln(1 — 1/M) = -ln(2)
K*(1/M) = ln(2)
K = M*ln(2)
Т.е. нам понадобится примерно 0.7M попыток. Что всгео лишь в полтора раза больше чем при последовательном переборе.
А смысл? Теоретически это даже хуже, т.к. получается большое количество криптотекстов с разной солью и одним и тем же паролем.
В случае умного процесса ломания — это было бы хуже (а умных способов для md5 ещё не придумали ведь?)
А для брута — те же яйца
А для брута — те же яйца
Если система скомпрометирована, а классическая Ева сохраняет каждый сгенерированный хеш, то наличие нескольких хешей с разной солью и одним паролем серьезно влияет на стойкость пароля.
Как им образом? Вот у вас есть на руках соль и результирующий хэш. Не всё ли равно, были ли другие, и есть ли другие? Брутфорс он и в африке брутфорс.
Предположим, что у нас оказались n хешей полученных следующим образом
md5(concat(saltn, password)), а наша цель найти password. Тогда при бруте нам будет достаточно найти совпадение лишь с одним из известных хешей.Совпадение с одним из известных хешей произойдёт только у той пары пароль-соль, из которой он был получен (нам неинтересны коллизии, нам интересен исходный пароль).
Именно поэтому брутфорс займёт абсолютно столько же времени.
Именно поэтому брутфорс займёт абсолютно столько же времени.
Мне кажется, при увеличении n увеличивается и вероятность поймать пару соль-пароль раньше, но тут многое зависит от алгоритма и от способа перебора.
Я понял. Вы считаете, что мы подбираем и соль, и пароль. zerkms — что только пароль, а соль известна.
Я прав?
Я прав?
По-моему, если уже уведен хеш пароля, то подобрать можно чем бы ни шифровал — при помощи базы уже заранее подобранных хешей.
При грамотном хэшировании подобрать можно будет лишь брутфорсом. Если алгоритм хэширования (например, из-за множества итераций) требует значительных вычислительных ресурсов, брутфорс теряет смысл.
НЛО прилетело и опубликовало эту надпись здесь
Алгоритм шифрования выложите. Иначе получается «security by obscurity».
Вот для этого нужна соль.
На мой взгляд сейчас лучше использовать комбинацию из Sha1 Sha512 и Ripemd160.
К тому же не стоит забывать про соль, к каждому паролю должна быть своя, чтоб не дать злоумышленнику, при расшифровке соли, пройтись по базе словарём.
К тому же не стоит забывать про соль, к каждому паролю должна быть своя, чтоб не дать злоумышленнику, при расшифровке соли, пройтись по базе словарём.
А почему не использовать bcrypt? Характеристики его известны, а сложность вычисления можно легко контролировать, наращивая ее по мере увеличения вычислительной мощности компьютеров. В PHP доступен без дополнительных танцев.
Я пользую py-bcrypt с django.
Вот опять какая-то ерунда. Хеш-функция, которая на GPU считается 0.1 секунды? Да обычный сервак уже при 100 пользователях с подобным алгоритмом помрет.
MD5 не взломали (сейчас покажут десяток пруф-ссылок, где утверждается обратное — но, обратите внимание, для очень частного случая)! Для хеширования паролей он ничем не хуже SHA1, RipeMD, Whirpool, etc. И высокая скорость функции хеширования — не минус.
Просто используйте случайные соли, для каждого пользователя свои — у большинства взломщиков на этом интерес к вашей системе и иссякнет.
MD5 не взломали (сейчас покажут десяток пруф-ссылок, где утверждается обратное — но, обратите внимание, для очень частного случая)! Для хеширования паролей он ничем не хуже SHA1, RipeMD, Whirpool, etc. И высокая скорость функции хеширования — не минус.
Просто используйте случайные соли, для каждого пользователя свои — у большинства взломщиков на этом интерес к вашей системе и иссякнет.
Попрошу заметить, при неправильном подходе добавление соли — не панацея. У злоумышленника всего лишь отпадет возможность атаки по словарю и радужным таблицам (и то не всегда, есть онлайн сервисы которые справляются даже с хешами с короткой солью).
Добавление соли к паролю при генерировании хеша призванно увеличить длинну пароля прозрачно для конечного пользователя. Скажем у пользователя пароль в 6 символов (хеш от него легко сбрутить), добавляем соль длиной еще, к примеру, в 10 символов, и получаем общий 16-и символьный пароль, который на данный момент сбрутить в разумные сроки практически невозможно.
Но неправильный подход к реализации губит эту идею на корню. В большинстве (по-крайней мере в 90% изученных мною) веб-приложений хеш и соль хранятся в БД. И если злоумышленнику удалось получить каким-то образом хеши, то ему не составит труда получить оттуда и соль. А далее атака сводится к обычному брутофорсу недостающих симолов, т.е. исходного пароля пользователя.
Правильный подход к использованию соли заключается в следующем. Вы должны не допустить того чтобы злоумышленник смог получить и соль и хеш одновременно. Один из вариантов практической реализации — в БД хранится хеш, в конфиге приложения общая соль для всех хешей. Еще вариант — соль для каждого хеша генерируется от некоторых данных пользователя (например по логину), так чтобы алгоритм генерации остался для злоумышленника неизвестен.
Добавление соли к паролю при генерировании хеша призванно увеличить длинну пароля прозрачно для конечного пользователя. Скажем у пользователя пароль в 6 символов (хеш от него легко сбрутить), добавляем соль длиной еще, к примеру, в 10 символов, и получаем общий 16-и символьный пароль, который на данный момент сбрутить в разумные сроки практически невозможно.
Но неправильный подход к реализации губит эту идею на корню. В большинстве (по-крайней мере в 90% изученных мною) веб-приложений хеш и соль хранятся в БД. И если злоумышленнику удалось получить каким-то образом хеши, то ему не составит труда получить оттуда и соль. А далее атака сводится к обычному брутофорсу недостающих симолов, т.е. исходного пароля пользователя.
Правильный подход к использованию соли заключается в следующем. Вы должны не допустить того чтобы злоумышленник смог получить и соль и хеш одновременно. Один из вариантов практической реализации — в БД хранится хеш, в конфиге приложения общая соль для всех хешей. Еще вариант — соль для каждого хеша генерируется от некоторых данных пользователя (например по логину), так чтобы алгоритм генерации остался для злоумышленника неизвестен.
Второй вариант плох — это security through obscurity (как, кстати, и предложение Кампа сконфигурировать свой алгоритм).
Вы путаете понятия, security through obscurity — это нечто другое.
Я бы не стал утверждать так категорично что второй вариант плох. В данном случае неизвестный алгоритм это такая же соль для злоумышленника только немного в другом виде. Или наличие соли вы тоже считаете security through obscurity?
Я бы не стал утверждать так категорично что второй вариант плох. В данном случае неизвестный алгоритм это такая же соль для злоумышленника только немного в другом виде. Или наличие соли вы тоже считаете security through obscurity?
«use secrecy of design or implementation to provide security» — определение из википедии. «алгоритм генерации остался для злоумышленника неизвестен» — в точности это, казалось бы.
С вами сложно спорить. Я вам об одном, вы мне о другом.
Я, повторюсь, использовать соль в алгоритме — это тоже своего рода сокрытие алгоритма генерации конечного хеша. Вы также считаете это security through obscurity?
Заметьте, никто не задается целью сделать невозможным брут хеша. С помощью соли и неизвестного алгоритма, разработчики пытаются максимально усложнить этот процесс. И при этом, пока и то и другое остается тайной для злоумышленника — этот процесс в конечном счете является бессмысленным.
Я, повторюсь, использовать соль в алгоритме — это тоже своего рода сокрытие алгоритма генерации конечного хеша. Вы также считаете это security through obscurity?
Заметьте, никто не задается целью сделать невозможным брут хеша. С помощью соли и неизвестного алгоритма, разработчики пытаются максимально усложнить этот процесс. И при этом, пока и то и другое остается тайной для злоумышленника — этот процесс в конечном счете является бессмысленным.
Вообще-то соль предназначена как раз убрать возможность подборки по радужным таблицам. Со всеми проблемами хорошо справляется хеш вида md5($salt.md5($password)). Остаются только коллизии. При создании защиты хранимого ключа надо руководствоваться правилом, что злоумышленник потенциально имеет доступ ко ВСЕЙ информации, т.е. и к конечному хешу, и к соли, и к алгоритму. Чуть выше правильно написали про «security through obscurity». Особые параноики могут использовать более 1 соли, к примеру.
По поводу коллизий — предположим, что мы шифруем пароль по следующему алгоритму:
Злоумышленник подобрал для получившегося хеша коллизию «с».
Но если он попробует ее ввести в поле «пароль» то на стороне сервера мы проверим
В общем, просветите меня — может я чего не знаю — каким образом найденная коллизия поможет злоумышленнику при таком раскладе?
md5(($salt="a").md5($pass="b"))Злоумышленник подобрал для получившегося хеша коллизию «с».
Но если он попробует ее ввести в поле «пароль» то на стороне сервера мы проверим
md5("a".md5("c")) == md5("a".md5("b")) и обнаружим, что пароль собственно говоря он ввел неверный.В общем, просветите меня — может я чего не знаю — каким образом найденная коллизия поможет злоумышленнику при таком раскладе?
НЛО прилетело и опубликовало эту надпись здесь
А как обнаружим? Вы будете пароль «b» тоже хранить?
Ему нужно будет подобрать коллизию C такую, что последние символы будут составлять валидный хэш, а потом подобрать коллизию к B. То есть нужно подобрать две коллизии. При этом манёвр для первой меньше (не любая найденная коллизия подойдёт), но, с другой стороны, для прямого брутфорса число вариантов перебора снижается в случае сложных паролей (2^128 вариантов хэша соответствует примерно 18-значному паролю из алфавита в 96 символов (печатные символы ASCII).
Тут надо искать коллизию не для md5, а для md5': md5'(x) = md5('a' + md5(x))
Да, с коллизиями я немного погорячился — ночь была.
habrahabr.ru/post/145454/#comment_4889303
habrahabr.ru/post/145454/#comment_4889303
Почему не md5($salt.$password)? Чем ваш вариант лучше? Есть математическое доказательство, что он, минимум, не хуже?
Меньше вероятность его наличия в общедоступных радужных таблицах (если у вас соль не запредельной длины).
А ваш вариант ломается весьма легко. Ваша операция конкатенации — фактически просто удлинение пароля рандомной строкой. А значит, его можно подобрать или радужными таблицами или перебором. Учитывая то, что я написал выше, мы знаем соль и знаем алгоритм. Значит, смешиваем перебираемые пароли с солью по известному алгоритму и соль даже в 20 символов уже не поможет при сравнительно простом пароле у пользователя.
Даже если алгоритм неизвестен, то в приведённом вами варианте используется просто конкатенация строк, при которой уже за пару секунд брутфорса (после подбора хеша) на сайте мы найдём пароль, отрезая по символу с каждой неудачей, а при использовании сложного перемешивания пароля пользователя с солью не спасёт при знании алгоритма.
В моём же варианте время полного перебора при знании всех трёх составляющих (хеш, соль, алгоритм) будет возведено в квадрат по сравнению с вашим.
Вроде ничего не забыл
Даже если алгоритм неизвестен, то в приведённом вами варианте используется просто конкатенация строк, при которой уже за пару секунд брутфорса (после подбора хеша) на сайте мы найдём пароль, отрезая по символу с каждой неудачей, а при использовании сложного перемешивания пароля пользователя с солью не спасёт при знании алгоритма.
В моём же варианте время полного перебора при знании всех трёх составляющих (хеш, соль, алгоритм) будет возведено в квадрат по сравнению с вашим.
Вроде ничего не забыл
Если мы знаем соль — то md5($salt.md5($password)) дает максимум удвоенное время перебора по сравнению с md5($salt.$password). Пусть f(x) = salt+md5(x). Тогда Вы предлагаете взять функцию шифрования md5(f(x)) =: g(x).
Но для нахождения ее прообраза перебором нам не надо искать сначала прообраз относительно md5, а потом относительно f — можно сразу искать прообраз относительно g.
Нахождение прообраза x слова y заключается в переборе x, вычислению функции от них до нахождения совпадения с y. Так как g считается не более чем в два раза дольше, чем md5, то вы увеличили время подбора не более чем вдвое.
Но для нахождения ее прообраза перебором нам не надо искать сначала прообраз относительно md5, а потом относительно f — можно сразу искать прообраз относительно g.
Нахождение прообраза x слова y заключается в переборе x, вычислению функции от них до нахождения совпадения с y. Так как g считается не более чем в два раза дольше, чем md5, то вы увеличили время подбора не более чем вдвое.
1. Ваш внутренний md5 ничего к безопасности не добавляет, его спокойно можно выкинуть.
2. Коллизии тут тем более не причём — найденная коллизия для md5(pass + salt) никак не поможет найти pass (который и надо передавать на сервер).
РЕАЛЬНАЯ проблема этой схемы — это перебор. Да, соль исключает использование таблиц, но md5 прекрасно оптимизируется для GPU и при известной соли найти pass _перебором_ за разумное время — вполне решаемая задача.
2. Коллизии тут тем более не причём — найденная коллизия для md5(pass + salt) никак не поможет найти pass (который и надо передавать на сервер).
РЕАЛЬНАЯ проблема этой схемы — это перебор. Да, соль исключает использование таблиц, но md5 прекрасно оптимизируется для GPU и при известной соли найти pass _перебором_ за разумное время — вполне решаемая задача.
Соль — «123», хеш — «b957f7f130aedb19f85239632b1ff382», длина пароля — 20, английские буквы (заглавные и строчные), хеш = md5(salt+password).
Перебирайте.
Перебирайте.
Делать мне больше нечего:) Ваш лично 20-символьный пароль никому нафиг не сдался. Проблема в том, что речь идёт не о конкретно Вашей безопасности (естественно, Вы можете хоть 1024-символьный придумать и быть спокойным за свою безопасность), а о безопасности с точки зрения владельца сайта, у которого толпы юзеров с гораздо более простыми паролями.
Абсолютное большинство паролей обычных пользователей — а) короткие и б) простые. Примеров в сети масса, если вдруг не верите. И задача состоит в защите именно таких паролей.
Абсолютное большинство паролей обычных пользователей — а) короткие и б) простые. Примеров в сети масса, если вдруг не верите. И задача состоит в защите именно таких паролей.
РЕАЛЬНАЯ проблема — это словарные пароли. И решать ее методом увеличения времени работы алгоритма шифрования не кажется мне хорошей идеей.
Ибо время работы ограничено сверху ресурсами сервиса. Ограничение снизу должно быть таким, чтобы за разумное время по достаточно большому словарю перебрать было нельзя. Получаем довольно узкую полосу.
С учетом роста производительности мы постоянно будем из нее вылетать.
Ибо время работы ограничено сверху ресурсами сервиса. Ограничение снизу должно быть таким, чтобы за разумное время по достаточно большому словарю перебрать было нельзя. Получаем довольно узкую полосу.
С учетом роста производительности мы постоянно будем из нее вылетать.
Если мудро распорядиться временем жизни авторизационной куки большой разницы в нагрузке вы не увидите.
А со словарными паролями можно бороться только методом их запрещения при вводе что
а) вызовет недовольство пользователей
б) будет не очень эффективно или потребует постоянного обновления словаря.
А со словарными паролями можно бороться только методом их запрещения при вводе что
а) вызовет недовольство пользователей
б) будет не очень эффективно или потребует постоянного обновления словаря.
Тут Вы правы, конечно. Но с простотой юзерских паролей мы вряд ли что-то можем сделать со своей стороны.
Ну вообще говоря внутренний md5 таки добавляет к безопасности — он увеличивает время перебора в 2 раза :-)
Только не x*2, а x^2.
habrahabr.ru/post/145454/#comment_4889357
habrahabr.ru/post/145454/#comment_4889357
Ну, я изначально писал именно про соль, а коллизии упомянул потому что это проблема md5 в целом, их наличие у алгоритма хеширования. Ну и вообще в 5 утра соображается плохо.
Короче вывод: используйте wirlpool.
Короче вывод: используйте wirlpool.
вот как раз одна соль на всех пользователей (в конфиге) — это плохо, против брутфорса почти ничего не дает, если мы ее вытащим (а это довольно-таки вероятно, если уже есть доступ к БД). Хотя можно конечно брать md5(f(salt,userid). password), но тогда еще лучше просто завести отдельный внутренний сервер авторизации.
Главное, что просто разных достаточно длинных солей для разных пользователей достаточно, чтобы массовый перебор перестал быть эффективным. В случае же, если атака целевая, на какого-то одного пользователя, то
— обычно проще использовать социальный инженеринг, атаки другого вида
— а если пользователь грамотен, то и его пароль, вероятно сложен.
Главное, что просто разных достаточно длинных солей для разных пользователей достаточно, чтобы массовый перебор перестал быть эффективным. В случае же, если атака целевая, на какого-то одного пользователя, то
— обычно проще использовать социальный инженеринг, атаки другого вида
— а если пользователь грамотен, то и его пароль, вероятно сложен.
Я бы добавил, что данный подход — не панацея ещё и потому, что противоречит важнейшему принципу Киркхгоффса.
В нашем случае, оно сводится к тому, что, получив (выкрав) исходники, злоумышленник узнает алгоритм генерации «соли» и сведёт задачу к достаточно простой вычислительной задаче: GPU-перебору словарь + известная соль.
В нашем случае, оно сводится к тому, что, получив (выкрав) исходники, злоумышленник узнает алгоритм генерации «соли» и сведёт задачу к достаточно простой вычислительной задаче: GPU-перебору словарь + известная соль.
У вас эти 100 пользователей будут постоянно логиниться и регистрироваться, что бы мигом заваливать сервер? Скажем хеш будет считаться секунду, и вы как пользователь ресурса будете перелогиниваться скажем раз в неделю, тогда получаем, что такой сервер спокойно выдержит 7*24*60*60≃600к пользователей. По мне так более чем неплохой запас.
Разумеется некоторые проблемы могут возникнуть если на сервере начнёт регистрироваться больше одного пользователя в секунду, но в этом случае спасёт либо многоядерный сервер (всё-равно при такой популярности надо будет апгрейдить сервер), либо временное уменьшение сложности на время пиковой нагрузки. С ддосами же можно бороться введением каптчи на множество попыток логина с одного IP и при увеличенной нагрузке, либо опять же временным уменьшением сложности хеша.
Разумеется некоторые проблемы могут возникнуть если на сервере начнёт регистрироваться больше одного пользователя в секунду, но в этом случае спасёт либо многоядерный сервер (всё-равно при такой популярности надо будет апгрейдить сервер), либо временное уменьшение сложности на время пиковой нагрузки. С ддосами же можно бороться введением каптчи на множество попыток логина с одного IP и при увеличенной нагрузке, либо опять же временным уменьшением сложности хеша.
и 90% ресурсов (в широком смысле — денег, железа, людей) пойдет на то, чтобы обеспечить эту «крутую» функцию авторизации, а не на основную задачу сервера. Да и расчет у вас не жизненный, вот напишу я, допустим, на хабре, что открылся новый очень крутой сервис, и вдруг, правда людям интересно станет — и 1000 посетителей в минуту не будет пределом. А потом все равно интерес потеряют и будут редко ходить, а крутое железо, купленное для авторизации будет простаивать.
Да нет, правда же не рационально.
Да нет, правда же не рационально.
Так никто же вас не заставляет выполнять рекомендации буква в букву, вы спокойно можете уменьшить время расчёта хеша до 0.1-0.01 секунды изменив всего одну константу. Мне тоже кажется пассаж про 0.1 секунду на лучшем GPU излишне параноидальным, тем не менее использование bcrypt'а со встроенной солью с числом раундов 10 (0.1 секунды на моём ноутбуке) мне кажется более надёжным и оправданным нежели использование md5 с накрученным поверх своим или чужим солением. Думаю вы согласитесь, что для взломщиков для взломщиков есть большая разница побрутфорсить или атаковать по словарю день-два или же ждать больше года.
> Да обычный сервак уже при 100 пользователях с подобным алгоритмом помрет.
Если каждую секунду на нём авторизуется сотня человек — помрёт. Такая интенсивность, подозреваю, есть у нескольких десятков проектов во всём мире. И у них есть «необычные» сервера для таких задач.
Если каждую секунду на нём авторизуется сотня человек — помрёт. Такая интенсивность, подозреваю, есть у нескольких десятков проектов во всём мире. И у них есть «необычные» сервера для таких задач.
8,6 млн посетителей в сутки явно больше чем у десятка проектов. Причём скорее всего для достижения 100 запросов в секунду уникальных посетителей должно быть не 8,6 млн, а меньше — неоднократные авторизации в течении дня, плюс неоднородность активности по времени суток. 360 тыс человек в час явно у большего числа проектов, чем 8,6 млн в сутки.
Даже после такого заявления автора md5 вряд ли потеряет популярность в силу своей распространенности, к тому же правильно подсоленные md5 вполне сгодятся для защиты от брутфорса в 99.9% случаев.
Как показывает практика, большая часть уязвимостей кроется вовсе не в проблеме md5, некомпетентность, безответственность и безалаберность — главные источники уязвимостей, и от этого не защищены в том числе и крупные ресурсы.
Как показывает практика, большая часть уязвимостей кроется вовсе не в проблеме md5, некомпетентность, безответственность и безалаберность — главные источники уязвимостей, и от этого не защищены в том числе и крупные ресурсы.
НЛО прилетело и опубликовало эту надпись здесь
В скрипте кроме того будет еще и алгоритм создания хэша, что тоже затрудняет подбор.
НЛО прилетело и опубликовало эту надпись здесь
Одинаковая для всех пользователей соль плоха тем, что у пользователей с одинаковым паролем будет одинаковый результирующий хеш, поэтому даже не зная соли можно будет провести атаку опираясь на самые частые хеши, т.е. например указывать всякие qwerty и password в работающую систему, тем самым можно будет в достаточно краткие сроки подобрать пароль для дочтаточно большого числа аккаунтов.
НЛО прилетело и опубликовало эту надпись здесь
Главное не забыть при изменении ника, мыла и т. п. обновлять и хэш солёного пароля в базе :)
Для этого нужно будет просить пользователя вводить пароль при изменении мыла ника и пр на чем завязан хэш. В свою очередь на некоторых сервисах при изменении анкеты требуется указание текущего пароля, что в свою очередь может говорить о том, что некотарая сущность профиля используется в качестве соли. Соответсвенно это может намекать взломщику в какую сторону копать.
Можно сделать проверку и требовать уникальности пароля:)
«Пароль 123456 уже используется пользователем %USERNAME%, выберите другой пароль»
«Пароль 123456 уже используется пользователем %USERNAME%, выберите другой пароль»
А имя то зачем сообщать?
Чтобы взломщик не нагружал сервер, подбирая логины пользователей со словарными паролями.
Кажется на last.fm так сделали, менял пароль, а он мне выдал что такой уже используются, хотя я ввел достаточно случайный.
На данный момент, лично мне, самым надёжным вариантом кажется следующий: в конфигах приложения хранится секретный ключ, когда требуется получить соль к секретному ключу примешивается неизменяемая информация пользователя (ник, идентификатор, время регистрации и т.д.) и берётся хеш функция (здесь подойдёт и md5), с этой солью мы хешируем пароль «медленной» хеш функцией, подбирая медленность из соображений желаемого соотношения надёжность/производительность.
Т.е. в итоге соль будет у всех пользователей разная, если злоумышленник получит только базу, то сделать с ней он ничего не сможет, если же он завладеет и базой и секретным ключом, то он не сможет эффективно проводить атаки брутфорсом и по словарю не только из-за разной у всех пользователей соли, но и из-за удручающей медленности конечной хеш-функции.
Т.е. в итоге соль будет у всех пользователей разная, если злоумышленник получит только базу, то сделать с ней он ничего не сможет, если же он завладеет и базой и секретным ключом, то он не сможет эффективно проводить атаки брутфорсом и по словарю не только из-за разной у всех пользователей соли, но и из-за удручающей медленности конечной хеш-функции.
А вообще мне интересно узнать как дела с брутфорсом обстоят у SRP, по идее именно он будет надёжнее всего, т.к. не только нельзя восстановить пароль имея базу и соль у всех пользователей разная, но и как таковой передачи пароля на сервер не происходит. Единственный недостаток, что он требует от клиента отдельных телодвижений, т.е. в случае веба придётся ещё использовать при авторизации клиентский джаваскрипт.
Кстати, соль в php может генерироваться в зависимости от имени пользователя
Как я думаю — хранить и хеш и соль одновременно в БД не есть хорошо, если злоумышленник получит доступ к БД, с большой вероятностью он расшифрует все, что ему нужно имея на руках все данные.
Хранение общей для всех соли отдельно повышает практическую стойкость к целевым атакам перебором на конкретного пользователя, если злоумышленник не получил доступа к соли — ему придётся перебирать значительно большее число вариантов.
Но снижает стойкость к массовым атакам, если злоумышленник получил доступ и к соли — почти эквивалентно тому, что соли нет, особенно учитывая высокую вероятность одинаковых паролей и, как следствие, одинаковых хэшей с общей солью — достаточно подобрать один и получить доступ к аккаунтам многих юзеров использующих пароль типа qwerty.
Можно использовать комбинацию — постоянная соль в конфиге объединятся с индивидуальной солью (случайной, хранимой в базе или значениями/хэшем других уникальных полей — id, ник, мыло и т. п. — хранящихся там). Получаем повышенную практическую стойкость к целевым атакам (злоумышленнику нужно будет получить доступ и к соли, или брутфорсить по большему пространству) и её же к массовым (вероятность совпадения дважды солёного хэша пренебрежимо мала).
Хранение общей для всех соли отдельно повышает практическую стойкость к целевым атакам перебором на конкретного пользователя, если злоумышленник не получил доступа к соли — ему придётся перебирать значительно большее число вариантов.
Но снижает стойкость к массовым атакам, если злоумышленник получил доступ и к соли — почти эквивалентно тому, что соли нет, особенно учитывая высокую вероятность одинаковых паролей и, как следствие, одинаковых хэшей с общей солью — достаточно подобрать один и получить доступ к аккаунтам многих юзеров использующих пароль типа qwerty.
Можно использовать комбинацию — постоянная соль в конфиге объединятся с индивидуальной солью (случайной, хранимой в базе или значениями/хэшем других уникальных полей — id, ник, мыло и т. п. — хранящихся там). Получаем повышенную практическую стойкость к целевым атакам (злоумышленнику нужно будет получить доступ и к соли, или брутфорсить по большему пространству) и её же к массовым (вероятность совпадения дважды солёного хэша пренебрежимо мала).
Не вижу проблемы иметь две соли.
Одна статичная в файле. Вторая динамичная в БД.
Одна статичная в файле. Вторая динамичная в БД.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
It also automatically generate a salt every time… the generated salt is stored in the returned string for convenience
Из описания функции:
An optional salt string to base the hashing on. If not provided, the behaviour is defined by the algorithm implementation and can lead to unexpected results.Т.е. не используете свою соль — получаете непредсказуемый результат. Так что лучше явно указывать алгоритм и использовать собственную соль.
Таким образом, мы обезопасили систему от использования радужных таблиц, обезопасили систему от т.н. сквозного брутфорса (т.е. у нас для каждого пользователя надо запускать отдельный брутфорс).
Что касается наличия т.н. секретной общей части соли, так она никак не добавляет методу защищенности. Считаем, что алгоритм известен (допустим, сам движок лежит в открытом доступе), а общая часть соли не известна. Тогда схема следующая:
— злоумышленник регистрируется на сайте с именем «хакер» и паролем «пароль»
— злоумышленник крадет базу, получает («хакер», соль_для_хакера, хэш)
— запускает брут с параметрами хэш_функция(«пароль», соль_для_хакера + подбираемая_соль)
— спустя некоторое время у злоумышленника есть подбираемая_соль
Далее алгоритм действий хакера такой же, как будто никакой секретной соли нет, т.е. брут для каждого пользователя в отдельности.
Если полагать, что брут каждого конкретного пользователя для хакера является посильной задачей, то нужно автоматически считать, что и брут неизвестной ему части соли также является более чем посильной задачей. Отсюда вывод: секретная соль, хранимая в конфиге, бесполезна.
Потому используйте трудоемкие хэш-функции, которые хотя бы еще некоторое время будет сложно сбрутить!
Только секретную соль можно сделать несловарной, в отличии от пароля каждого конкретного пользователя. Удачи хакеру в подборе случайной строки из 20 буквенно-цифровых символов)
В качестве дополнительного заслона для хакера, почему бы не использовать и такой метод.
Секретная соль сильно осложняет хакеру жизнь. До тех пор, пока она секретная:)
Если же у хакера как часто предполагается есть всё — алгоритм, хеши, соли — то от брутфорса нас не спасет ничто, т.к. хакер сможет просто моделировать проверку обычных юзеров.
Если же у хакера как часто предполагается есть всё — алгоритм, хеши, соли — то от брутфорса нас не спасет ничто, т.к. хакер сможет просто моделировать проверку обычных юзеров.
Фокус заключается в том, что при грамотной настройке сервера и тем более при разносе приложения и БД на разные сервера, вероятность того что вместе с базой стащат ещё и приложение достаточно мала. Т.е. скажем если база была сдамплена через SQL-injection или через доступ к серверу БД, то почти наверняка это означает, что у злоумышленника нет доступа к самому приложению. Поэтому мне кажется что усложнение с секретным ключом в конфигах достаточно весомо и им не стоит пренебрегать.
Мммм. Прочитал комментарии. В оригинале сказано: «если вы не знаете разницу между md5 и md5crypt, то перед тем как читать дальше — узнайте в чем разница»
Странно… Почему до сих пор никто не предложил использовать MD6 вместо MD5? Его ведь еще в 2008 разработали.
«MD6 был впервые представлен на конференции Crypto 2008 в качестве кандидата на стандарт SHA-3. Однако позднее в 2009 на этой же конференции Ривест заявил, что MD6 ещё не готова к тому, чтобы стать стандартом. На официальном сайте MD6 он заявил, что, хотя, формально, заявка не отозвана, в алгоритме ещё остаются проблемы со скоростью и неспособностью обеспечить безопасность в версии с уменьшенным количеством раундов.» © wiki
Ждем кто станет SHA-3.
Ждем кто станет SHA-3.
Насчёт паролей. Что будет, если взять AES-256 и зашифровать пароль, используя его самого в качестве ключа?
Интересная идея, но 95% сайтописателей не справятся. Дело в том, что AES хеш состоит из множества символов, которые «портятся», если их просто сохранить в базе. Поэтому его нужно оборачивать, либо в BASE64, либо сделать из него хеш с помощью того же MD5/SHA. А в отличии от него MD5 ужасно удобен, хоп и и сразу хеш, без возни.
один раз пишется функция «aeshash», которая внешне работает так же, как md5, и всё, никакой «возни»
Ну это вами пишется, а речь была о людях, которые просто не понимают, почему их aes256 хеш не может храниться в виде строки. А такие делают 95% сайтов.
То ли у вас какой-то безудержный снобизм из мира пони, то ли я счастливый человек, что у меня среди знакомых нет настолько тупых людей, о каких идет речь.
А я их тоже не знаю, но меня несколько раз в месяц просят разобраться, почему не работает какой-то плагин от сайта, или почему все работало-работало, а теперь не работает и серверное ПО не обновлялось. Поверьте, насмотрелся этого кода, такие вещи пишут, волосы дыбом.
Я год учился во владимирском гос. университете на «Факультете информационных технологий». Там половина преподавателей «настолько тупые», не говоря уже о студентах.
Сделать какой нить примитивный bin2hex — это высшая магия? Мдас…
Вы видимо говорите за php и программистов на нем. Дело в том, что любой из алгоритмов возвращает набор битов. Так уж получилось, что функция md5 возвращает их строкой в шестнадцатиричной системе, а mcrypt_encrypt строкой и без конвертирования, И тут, думаю, 95% программистов с вами не согласятся, что это задача для них непосильная.
mysql_real_escape_string(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $key, $text)) — вы считаете, что 95% с этим не справятся?
О чем вы говорите, если рекурсивная функция стала мемом? У людей нет не то, что профильного образования, у них нет профильного мышления.
Во всех книжках написано md5, поэтому будут использовать именно ее, потому что удобна и не надо читать доки и во что-то преобразовывать.
З.Ы. Лучше использовать base64_encode, вместо mysql_real_escape_string
Во всех книжках написано md5, поэтому будут использовать именно ее, потому что удобна и не надо читать доки и во что-то преобразовывать.
З.Ы. Лучше использовать base64_encode, вместо mysql_real_escape_string
Выходит я не такой же быдлокодер и отношусь к топ5% :)
Чем лучше? Для гипотетической возможности сменить базу даных?
Чем лучше? Для гипотетической возможности сменить базу даных?
Дело в том, что эта строчка, на самом деле, бинарные данные. Хранить их следует в BLOB, что несколько накладно. Как только к ним будет применена кодировка UTF-8 или ASCII, мы изуродуем хеш. Более того, мне иногда требуется зайти в аккаунт пользователя с его разрешения, для этого мне надо сохранить его хеш и соль, т.е. скопировать из базы, перебить, а затем вернуть все обратно. С такими чувствительными к кодировке данными, у меня это не получится.
Именно поэтому все файлы сертификатов хранятся в Base64, пользователь может их свободно открывать в любом редакторе, копировать и вставлять, а этим данным плевать на кодировку.
Именно поэтому все файлы сертификатов хранятся в Base64, пользователь может их свободно открывать в любом редакторе, копировать и вставлять, а этим данным плевать на кодировку.
Нет, сталкивался с машинами, где mcrypt_encrypt не стоит, также сталкивался со сборками PHP, под которые нет совместимой dll-ки mcrypt.dll
Любой хороший блочный шифр можно превратить в хеш функцию. Другое дело что в случае с AES есть ряд проблем, главная из которых — низкая разрядность выходного значения, всего 128 бит, это мало для хеш функции в 2012 г.
Ну и AES можно быстро аппаратно вычислять — это только на руку взломщикам.
Ну и AES можно быстро аппаратно вычислять — это только на руку взломщикам.
Но зачем? Более того шифрование пароля означает то, что получив доступ к шифрованным паролям и зная алгоритм его можно расшифровать. Такого не произойдет в случае надежного хеширования.
Соль должна быть рандомной для каждого юзера. Тогда:
1. Заранее сгенерированные злоумышленником таблицы хешей идут лесом.
2. Юзеры с одинаковым паролем получат разный хеш.
Дальше научно не обоснованное имхо:
Хранить соль в базе, рядом с хешем — нормально.
hash(pass + salt) — достаточно. Всякие вариации — ничего в итоге не дают. Я имею ввиду hash(hash(pass) + hash(salt)) и прочие.
Перец — не нужен.
Все любят говорить «не используй md5/sha1/etc». Один товарищ на StackOverflow выложил md5 хеш и попросил взломать его. Все потеоретизировали-потеоретизировали и не взломали. Что показательно. Интересно, что этот вопрос зачем-то удалили.
По поводу множества итераций я не уверен. С одной стороны — это много где используется. Меня смущает, что если на вход первой итерации подается неограниченное количество вариантов, т.е. могут быть любые символы, то на вход второй итерации — уже строго ограниченое (a-z0-9 для md5) и так далее мы «сужаем диапазон». Я в этом не силен поэтому воспринимайте это как домыслы.
Еще одна фантазия про коллизии. Если хешировать бесконечно долго (в цикле) 2 разных строки, то в какой-то момент возникнет коллизия и хеши совпадут. Т.е. изначально hash(str1) != hash(str2), но на 100500й итерации они станут равны. Мне кажется что hash(str1) == hash(str2) намного менее вероятно чем hash(str1) == hash(str2) на n-ой итерации. Опять же, из-за того, что в первом случае str1 и str2 абсолютно случайны, а на n-ой итерации «случайны в определенном диапазоне».
Кто-нибудь рассеет мои домыслы-заблуждения?
1. Заранее сгенерированные злоумышленником таблицы хешей идут лесом.
2. Юзеры с одинаковым паролем получат разный хеш.
Дальше научно не обоснованное имхо:
Хранить соль в базе, рядом с хешем — нормально.
hash(pass + salt) — достаточно. Всякие вариации — ничего в итоге не дают. Я имею ввиду hash(hash(pass) + hash(salt)) и прочие.
Перец — не нужен.
Все любят говорить «не используй md5/sha1/etc». Один товарищ на StackOverflow выложил md5 хеш и попросил взломать его. Все потеоретизировали-потеоретизировали и не взломали. Что показательно. Интересно, что этот вопрос зачем-то удалили.
По поводу множества итераций я не уверен. С одной стороны — это много где используется. Меня смущает, что если на вход первой итерации подается неограниченное количество вариантов, т.е. могут быть любые символы, то на вход второй итерации — уже строго ограниченое (a-z0-9 для md5) и так далее мы «сужаем диапазон». Я в этом не силен поэтому воспринимайте это как домыслы.
Еще одна фантазия про коллизии. Если хешировать бесконечно долго (в цикле) 2 разных строки, то в какой-то момент возникнет коллизия и хеши совпадут. Т.е. изначально hash(str1) != hash(str2), но на 100500й итерации они станут равны. Мне кажется что hash(str1) == hash(str2) намного менее вероятно чем hash(str1) == hash(str2) на n-ой итерации. Опять же, из-за того, что в первом случае str1 и str2 абсолютно случайны, а на n-ой итерации «случайны в определенном диапазоне».
Кто-нибудь рассеет мои домыслы-заблуждения?
Если сделать каждому юзеру свою рандомную соль, то где ее хранить так, чтобы в случае утечки хешей не утекли и соли? В отдельной базе?
В той же базе. Рядом с хешем.
Принято исходить из предположения, что «Враг знает систему». Т.е. если Вы предполагаете, что злоумышленник получил доступ к базе, то предполагайте, также, что он имеет доступ ко всему. Если исходить из этих предпосылок, то становится очевидным, что хранить соль где-то в исходниках, другой базе или генерить ее «хитрым способом» ничем не лучше. Злоумышленник все так же имеет к ней доступ. И опасность еще заключается в том, что у Вас создается ложное чувство защищенности.
Я выше дал ссылку про перец. Там есть кое-что по этой теме.
Принято исходить из предположения, что «Враг знает систему». Т.е. если Вы предполагаете, что злоумышленник получил доступ к базе, то предполагайте, также, что он имеет доступ ко всему. Если исходить из этих предпосылок, то становится очевидным, что хранить соль где-то в исходниках, другой базе или генерить ее «хитрым способом» ничем не лучше. Злоумышленник все так же имеет к ней доступ. И опасность еще заключается в том, что у Вас создается ложное чувство защищенности.
Я выше дал ссылку про перец. Там есть кое-что по этой теме.
Почитать еще можно здесь:
The necessity of hiding the salt for a hash
Is it okay to store salts with hashes?
The necessity of hiding the salt for a hash
Is it okay to store salts with hashes?
На самом деле, оно стабилизируется на некотором множестве, на котором md5 действует как перестановка. Размер такого множества считать лень, но вроде бы оно почти наверняка очень большое.
Я могу немного рассеять/сгустить.
По поводу MD5 — проглядите доклад по ссылке которую дал Камп — 2012.sharcs.org/slides/sprengers.pdf
Понятно что хороший и длинный пароль по хешу забрутить нельзя. Но если буквенноцифровой 8ми символьный хеш можно забрутить за 2 дня — это уже не хорошо. В соседеней теме обсуждают утечку хешей на Lastfm (несоленый MD5) — утечка была еще в 2011 и за год удалось забрутить 95% паролей.
Про количество итераций — на вход нужно давать бинарное значение, не hex.
Про коллизии — на Хабре есть статья, исследовалось это явление, теоретически и экспериментально. Для 128 бит хеша можно выполнять до 130 000 итераций без особого снижения криптостойкости. Дальше больше — для 512 — много много миллиардов итераций.
По поводу MD5 — проглядите доклад по ссылке которую дал Камп — 2012.sharcs.org/slides/sprengers.pdf
Понятно что хороший и длинный пароль по хешу забрутить нельзя. Но если буквенноцифровой 8ми символьный хеш можно забрутить за 2 дня — это уже не хорошо. В соседеней теме обсуждают утечку хешей на Lastfm (несоленый MD5) — утечка была еще в 2011 и за год удалось забрутить 95% паролей.
Про количество итераций — на вход нужно давать бинарное значение, не hex.
Про коллизии — на Хабре есть статья, исследовалось это явление, теоретически и экспериментально. Для 128 бит хеша можно выполнять до 130 000 итераций без особого снижения криптостойкости. Дальше больше — для 512 — много много миллиардов итераций.
Спасибо. Интересно что в докладе написано:
Advantage: MD5-crypt still usable
Про ЛастФМ. Пароли не соленые, поэтому сделав md5(«lastfm») и поискав этот хеш в базе, нашли сразу 9558 паролей (цифры отсюда). Получается они их пачками подбирали. И мне кажется, что как раз 95% по простому словарю и подобрали. Все сходится.
Я ни в коем случае не призываю никого использовать «только md5, только хардкор!», но мне кажется «слухи о его смерти слегка преувеличены».
Advantage: MD5-crypt still usable
Про ЛастФМ. Пароли не соленые, поэтому сделав md5(«lastfm») и поискав этот хеш в базе, нашли сразу 9558 паролей (цифры отсюда). Получается они их пачками подбирали. И мне кажется, что как раз 95% по простому словарю и подобрали. Все сходится.
Я ни в коем случае не призываю никого использовать «только md5, только хардкор!», но мне кажется «слухи о его смерти слегка преувеличены».
Ну так ситуация с Lastfm показывает реальную ситуацию с паролями. Если MD5 позволяет за год слить 95% паролей пользователей, и не позволяет даже на современном уровне развития технологии безопасно хранить 8ми символьные буквенноцифровые пароли
то может кто то другой и захочет его использовать — но не я. :)
то может кто то другой и захочет его использовать — но не я. :)
правильно сделали, что удалили пост товарища на Стэковерфлоу. Что именно он хотел показать? Что умеет придумывать хорошие пароли? Да кому он сдался такой умный? Вопрос не в том, чтобы подобрать один сложный пароль, а в том, как усложнить подбор простых паролей.
> По поводу множества итераций я не уверен. С одной стороны — это много где используется. Меня смущает, что если на вход первой итерации подается неограниченное количество вариантов, т.е. могут быть любые символы, то на вход второй итерации — уже строго ограниченое (a-z0-9 для md5) и так далее мы «сужаем диапазон». Я в этом не силен поэтому воспринимайте это как домыслы.
Почему это md5 на выходе даёт ограниченное множество (a-z0-9)? Это вы откуда взяли вообще? md5 работает с блоками битов. Автор в статье специально указал, что она для тех, кто видит разницу между md5 и md5crypt.
> Еще одна фантазия про коллизии. Если хешировать бесконечно долго (в цикле) 2 разных строки, то в какой-то момент возникнет коллизия и хеши совпадут. Т.е. изначально hash(str1) != hash(str2), но на 100500й итерации они станут равны. Мне кажется что hash(str1) == hash(str2) намного менее вероятно чем hash(str1) == hash(str2) на n-ой итерации. Опять же, из-за того, что в первом случае str1 и str2 абсолютно случайны, а на n-ой итерации «случайны в определенном диапазоне».
Я не одобряю «хешировать бесконечно долго (в цикле) 2 разных строки». Рассмотрите bcrypt (http://ru.wikipedia.org/wiki/Bcrypt) — там на каждой последующей итерации хэшируется результат предыдущей итерации со строкой, которая есть результат хитрой функции над солью, сложностью и др.
Почему это md5 на выходе даёт ограниченное множество (a-z0-9)? Это вы откуда взяли вообще? md5 работает с блоками битов. Автор в статье специально указал, что она для тех, кто видит разницу между md5 и md5crypt.
> Еще одна фантазия про коллизии. Если хешировать бесконечно долго (в цикле) 2 разных строки, то в какой-то момент возникнет коллизия и хеши совпадут. Т.е. изначально hash(str1) != hash(str2), но на 100500й итерации они станут равны. Мне кажется что hash(str1) == hash(str2) намного менее вероятно чем hash(str1) == hash(str2) на n-ой итерации. Опять же, из-за того, что в первом случае str1 и str2 абсолютно случайны, а на n-ой итерации «случайны в определенном диапазоне».
Я не одобряю «хешировать бесконечно долго (в цикле) 2 разных строки». Рассмотрите bcrypt (http://ru.wikipedia.org/wiki/Bcrypt) — там на каждой последующей итерации хэшируется результат предыдущей итерации со строкой, которая есть результат хитрой функции над солью, сложностью и др.
Автор статьи намеренно лукавит, либо не разбирается в теме.
Комбинация известных хэш-функций не есть изобретение собственного образца шифрования. Последовательно сочетать их можно сколько угодно, от этого хуже точно не будет.
К тому же хэширование и шифрование вообще разные вещи.
Комбинация известных хэш-функций не есть изобретение собственного образца шифрования. Последовательно сочетать их можно сколько угодно, от этого хуже точно не будет.
К тому же хэширование и шифрование вообще разные вещи.
>Автор md5crypt просит им больше не пользоваться
Обещаю больше не пользоваться автором md5crypt.
Обещаю больше не пользоваться автором md5crypt.
Если кто-то поимел доступ к БД и спионерил таблицу с паролями, то ИМХО проблема у этого сервиса отнюдь не в md5 =)
Куда действеннее было бы "не используйте пароли вида «1234567890», думая что 10 символов — это охренеть сложно". И тому подобные)
Куда действеннее было бы "не используйте пароли вида «1234567890», думая что 10 символов — это охренеть сложно". И тому подобные)
Вспомнилась статьи habrahabr.ru/post/137316/ и habrahabr.ru/post/113127/
Почему бы не использовать простой цикл с md5, увеличив кол-во итераций шифрования. На сколько я понял bсrypt так и рабоает.
p.s. конечно не пресное шифрование, а с засаливанием
вы изобрели PBKDF2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автор md5crypt просит больше не пользоваться его скремблером