Comments 95
Чего хорошего в md5 без соли?
Можете подсказать статьи или советы на хранение паролей в базе, в том числе хотелось бы сравнение устойчивости распознавания хешей?
Вот такие ссылки надо в конце статьи делать, спасибо.
Желтые заголовки, громкие крики, но не поучают)
Желтые заголовки, громкие крики, но не поучают)
где гарантия, что я не заставлю сервер не выполнить ваш файл «enter.php», а просто прочитать его, или найти в вашем сайте ещё какую дырку и получить исходный код файла
Мда.
А где гарантия, что я не взломаю ваш ДЦ и не украду ваш сервер?
Если хакер получил БД на чтение это уже эпический ппц. Вопрос только в том, как он его получил.
Я не понимаю как он может получить возможность выполнения произвольных команд на моём проекте. С учетом того, что я не жопорукий.
Я не понимаю как он может получить возможность выполнения произвольных команд на моём проекте.
Понимание может возникнуть по следам расследования взлома. А может и не возникнуть — дыра так и останется открытой. Разумеется, я не телепат оценивать чью-либо квалификацию дистанционно, да и не всеведущий анонимус, чтобы перечислить все способы обойти защиту, но было бы рациональней учитывать любую возможность (тем более, что окружающий мир — тоже меняется, и то, что казалось невозможным вчера, сегодня вдруг оказывается неприятно доступным). И в последнюю очередь стоит расслабляться, если пробегают мысли «уж я то я защищён».
Понимание может возникнуть по следам расследования взлома. А может и не возникнуть — дыра так и останется открытой. Разумеется, я не телепат оценивать чью-либо квалификацию дистанционно, да и не всеведущий анонимус, чтобы перечислить все способы обойти защиту, но было бы рациональней учитывать любую возможность (тем более, что окружающий мир — тоже меняется, и то, что казалось невозможным вчера, сегодня вдруг оказывается неприятно доступным). И в последнюю очередь стоит расслабляться, если пробегают мысли «уж я то я защищён».
Всё это понятно. Баги в ORM/человеческий фактор. Я лишь указал, что аргументы по ссылке не такие уж и аргументы.
В конце концов просьбу в обосновании любого довода можно свести к закону Мерфи.
Мне лично абсолютно параллельно, что увели 500900 аккаунтов на ресурсе(будь это хоть Google), больше волнует как они это сделали. Может там у ребят не фильтровалась одна чертова sql`ка и суперхакер случайно натолкнулся. Я так однажды получил full-access к одному серьному магазино из-за бага в API.
В конце концов просьбу в обосновании любого довода можно свести к закону Мерфи.
Мне лично абсолютно параллельно, что увели 500900 аккаунтов на ресурсе(будь это хоть Google), больше волнует как они это сделали. Может там у ребят не фильтровалась одна чертова sql`ка и суперхакер случайно натолкнулся. Я так однажды получил full-access к одному серьному магазино из-за бага в API.
В конце концов просьбу в обосновании любого довода можно свести к закону Мерфи.
Можно, конечно, и на Мерфи сослаться, причём не обязательно с отговоркой про случайность — при систематическом «тестировании» сервиса ботами, при тотальной проверке всех возможных путей, из простой вероятности это уже превращается в предельный случай — так или иначе найдут. Но и закон Мерфи — даже не знаю, у самого был случай: небольшой сайт, ничего сложного, всё что можно вылизано от и до, всё перепроверено — читаю как-то логи, смотрю — SQL, повторил этот запрос — успешная SQL-инъекция, оказалось кто-то с первой попытки (других подобных запросов не было) нашёл на сайте единственную формочку, где параметры валидировались некорректно. Но я ведь был уверен. С тех пор я не уверен никогда — уверенность дорогое удовольствие. Кстати, и на хабре недавно пробегала интересная статья на похожу тему.
Был и другой случай — нашёл однажды свой дев-сервер в гугле — забыл поставить дайджест-авторизацию (точнее думал, что уже стоит). Было много неприятного в кеше.
Невероятность многих событий — слишком переоценивается. И признаться, иногда очень хочется оценить свой труд повыше — греет оно как-то душу. Но «плохое» случается не по «закону подлости», а по закону неизбежности — рано или поздно найдут то, о чём раньше не мог и подумать, а теперь уже не можешь и исправить.
Можно, конечно, и на Мерфи сослаться, причём не обязательно с отговоркой про случайность — при систематическом «тестировании» сервиса ботами, при тотальной проверке всех возможных путей, из простой вероятности это уже превращается в предельный случай — так или иначе найдут. Но и закон Мерфи — даже не знаю, у самого был случай: небольшой сайт, ничего сложного, всё что можно вылизано от и до, всё перепроверено — читаю как-то логи, смотрю — SQL, повторил этот запрос — успешная SQL-инъекция, оказалось кто-то с первой попытки (других подобных запросов не было) нашёл на сайте единственную формочку, где параметры валидировались некорректно. Но я ведь был уверен. С тех пор я не уверен никогда — уверенность дорогое удовольствие. Кстати, и на хабре недавно пробегала интересная статья на похожу тему.
Был и другой случай — нашёл однажды свой дев-сервер в гугле — забыл поставить дайджест-авторизацию (точнее думал, что уже стоит). Было много неприятного в кеше.
Невероятность многих событий — слишком переоценивается. И признаться, иногда очень хочется оценить свой труд повыше — греет оно как-то душу. Но «плохое» случается не по «закону подлости», а по закону неизбежности — рано или поздно найдут то, о чём раньше не мог и подумать, а теперь уже не можешь и исправить.
Комментарий конечно хорош, но выводы из него сделаны неправильные. Понятно что против простых паролей бороться никак нельзя (ну кроме как проверкой сложности сразу при вводе пароля, но если у вас не банк то пользователи будут очень недовольны), но, мне кажется, суть не в том чтобы защитить пароли всех клиентов от взлома, а чтобы МАКСИМАЛЬНО постараться защитить их.
А для этого (учитывая скорости перебора паролей на GPU) нужно не извращаться с хешами, а использовать bcrypt, scrypt или PDBKF2.
А для этого (учитывая скорости перебора паролей на GPU) нужно не извращаться с хешами, а использовать bcrypt, scrypt или PDBKF2.
Как так «против простых паролей бороться никак нельзя»… Разве добавление соли не спасает, не делает пароль непростым?
1) постоянная соль, одна на проект
2) рандомная соль, своя для каждого ппроля (хранится в БД — странный способ, учитывая что по сценарию базу у нас увели)
3) соль на основе пароля (берём энный байт...)
1) постоянная соль, одна на проект
2) рандомная соль, своя для каждого ппроля (хранится в БД — странный способ, учитывая что по сценарию базу у нас увели)
3) соль на основе пароля (берём энный байт...)
Так, давайте разбираться.
Вариант 1 наиболее плох. Принято считать, что злоумышленник не только увел у вас БД, но и имеет доступ к коду. То есть хранится у вас соль в БД или в коде — принципиальной разницы нет. Но если у вас одна соль и она известна злоумышленнику — это собственно аналогично отсутсвию соли вообще, потому что за 1 проход брутфорса можно проверить сразу все хеши в БД.
Если же соль переменная — это лучше, так как злоумышленнику придется вычислять хеш для каждого пользователя.
Большой разницы рандомная ли там соль при этом или как то зависит от пароля/логина нет — но по канону принято использовать рандомную соль. :)
Другое дело что даже со случайной солью современные брутфорсеры на GPU могут перебирать парочку — другую миллиардов хешей в секунду (Для MD5). То есть 10 символьный цифровой пароль будет вскрыт секунд за 10 — и тут не спасет никакая соль.
Используя более сложные хеши процесс можно замедлить раз в 10. Ну пусть в 100 — но и тогда мы получим 6 часов — тоже вполне себе нормальное время. Плюс скорость GPU все время растет и растет быстро (пока, по крайней мере).
Поэтому люди придумали более сложные способы хеширования. Bcrypt нарример можно настроить чтобы он на современном компьютере вычислял хеш скажем 100 мс — то есть 10 хешей в сек. Пусть злоумышленник ускорит перебор на GPU в 1000 раз — до 10000 хешей в секунду. Тогда 10 символьный цифровой пароль будет ломаться 1 000 000 секунд = чуть меньше двух лет грубо. :)
От пароля «1234» и это не спасет, но уже лучше.
Вариант 1 наиболее плох. Принято считать, что злоумышленник не только увел у вас БД, но и имеет доступ к коду. То есть хранится у вас соль в БД или в коде — принципиальной разницы нет. Но если у вас одна соль и она известна злоумышленнику — это собственно аналогично отсутсвию соли вообще, потому что за 1 проход брутфорса можно проверить сразу все хеши в БД.
Если же соль переменная — это лучше, так как злоумышленнику придется вычислять хеш для каждого пользователя.
Большой разницы рандомная ли там соль при этом или как то зависит от пароля/логина нет — но по канону принято использовать рандомную соль. :)
Другое дело что даже со случайной солью современные брутфорсеры на GPU могут перебирать парочку — другую миллиардов хешей в секунду (Для MD5). То есть 10 символьный цифровой пароль будет вскрыт секунд за 10 — и тут не спасет никакая соль.
Используя более сложные хеши процесс можно замедлить раз в 10. Ну пусть в 100 — но и тогда мы получим 6 часов — тоже вполне себе нормальное время. Плюс скорость GPU все время растет и растет быстро (пока, по крайней мере).
Поэтому люди придумали более сложные способы хеширования. Bcrypt нарример можно настроить чтобы он на современном компьютере вычислял хеш скажем 100 мс — то есть 10 хешей в сек. Пусть злоумышленник ускорит перебор на GPU в 1000 раз — до 10000 хешей в секунду. Тогда 10 символьный цифровой пароль будет ломаться 1 000 000 секунд = чуть меньше двух лет грубо. :)
От пароля «1234» и это не спасет, но уже лучше.
1. — ?! Ну есть у нас соль — как это поможет вычислить/брутфористь md5(salt+pwd)? Прямым перебором?
Вы будете смеяться — но да. Посмотрите слайды к свежему докладу по этому поводу.
Особенно впечатляет вот эта табличка —
Я уже молчу про перебор по словарю.
Особенно впечатляет вот эта табличка —
Я уже молчу про перебор по словарю.
37-й комментарий, в качестве ответа на 24-й и 36-й, ИМХО, не менее ценный: «System security should not depend on the secrecy of the implementation or its components» (Безопасность системы не должна зависеть от секретности реализации или элементов). Почему-то об этом очень часто забывают.
А по поводу описанных конструкций типа md5(md5('пароль').'соль') для повышения защищенности обычного md5('пароль'.'соль'), так существует же специально созданный для таких целей алгоритм HMAC, где в качестве сообщения будет выступать пароль, а в качестве ключа — соль.
А по поводу описанных конструкций типа md5(md5('пароль').'соль') для повышения защищенности обычного md5('пароль'.'соль'), так существует же специально созданный для таких целей алгоритм HMAC, где в качестве сообщения будет выступать пароль, а в качестве ключа — соль.
Верно. А если еще вычислять HMAC много раз для затруднения брутфорса мы получим стандарт «PBKDF2» :)
Самое главное здесь — не надо изобретать велосипед с неизвестными свойствами, когда есть проверенные алгоритмы с известными характеристиками.
В частности, PHP позволяет без лишних телодвижений использовать bcrypt:
где $cost — т.н. стоимость вычислений алгоритма. Может быть от 04 до 31. Чем больше значение, тем дольше будет вычисляться хэш. В частности, на моем Intel® Core™ i3-2310M CPU @ 2.10GHz × 4, 4 ГБ ОП, ОС ArchLinux x64, со стоимостью 4, в секунду вычисляется примерно, по грубой оценке, 525 значений. Стоимость 11 дает уже около 5 значений хэш-функции в сукунду. Общее правило: увеличение стоимости на 1 снижает производительность функции вдвое.
Для сравнения, MD5 дает примерно 1729332 значения в секунду, а HMAC с алгоритмом MD5 дает 625117 значений в секунду.
Вы можете грубо оценить производительность алгоритмов на своем компьютере, используя этот простой скрипт:
В частности, PHP позволяет без лишних телодвижений использовать bcrypt:
$bcrypt = crypt($pass, '$2a$'.$cost.'$'.$salt);
где $cost — т.н. стоимость вычислений алгоритма. Может быть от 04 до 31. Чем больше значение, тем дольше будет вычисляться хэш. В частности, на моем Intel® Core™ i3-2310M CPU @ 2.10GHz × 4, 4 ГБ ОП, ОС ArchLinux x64, со стоимостью 4, в секунду вычисляется примерно, по грубой оценке, 525 значений. Стоимость 11 дает уже около 5 значений хэш-функции в сукунду. Общее правило: увеличение стоимости на 1 снижает производительность функции вдвое.
Для сравнения, MD5 дает примерно 1729332 значения в секунду, а HMAC с алгоритмом MD5 дает 625117 значений в секунду.
Вы можете грубо оценить производительность алгоритмов на своем компьютере, используя этот простой скрипт:
#!/usr/bin/php
<?php
$pass = 'password';
$salt = '0aB1cD2eF3gH4iJ5kL6mN7';
//md5
$time = microtime(true);
for ($i = 0; $i < 100000; $i++) {
$md5 = md5($pass.$salt);
}
$time = microtime(true) - $time;
echo "MD5: $md5\n";
echo "Time: ", 100000 / $time, " iterations/s\n\n";
//md5 hmac
$time = microtime(true);
for ($i = 0; $i < 100000; $i++) {
$hmac = hash_hmac('md5', $pass, $salt);
}
$time = microtime(true) - $time;
echo "HMAC(md5): $md5\n";
echo "Time: ", 100000 / $time, " iterations/s\n\n";
//bcrypt
for ($cost = 4; $cost <= 31; $cost++) {
$time = microtime(true);
for ($i = 0; $i < 1000; $i++) {
$bcrypt = crypt($pass, '$2a$'.str_pad((string) $cost, 2, '0', STR_PAD_LEFT).'$'.$salt);
}
$time = microtime(true) - $time;
echo "bcrypt($cost): $bcrypt\n";
echo "Time: ", 1000 / $time, " iterations/s\n\n";
}
В коде ошибка: в 25-й строке (echo «HMAC(md5): $md5\n»;) надо $md5 заменить на $hmac.
Я сам являюсь горячим сторонником использования bcrypt, но все таки каким никаким, а стандартом PKCS #5 v2.0 (RFC 2898) является как раз PDKBF2 — так что для некоторых неизвесто что еще является «велосипедом с квадратными колесами». :)
Можно и PDKBF2. Я ж говорю, самое главное здесь — не надо изобретать алгоритм с неизвестными свойствами, когда есть проверенные алгоритмы с известными характеристиками. Если, конечно, изобретатель не является квалифицированным специалистом в области криптографии.
Просто ведь начинают выдумывать всякие md5(pass + md5(md5(pass + salt) + salt)), да еще и считают эти конструкции ну просто мега-защищенными…
Просто ведь начинают выдумывать всякие md5(pass + md5(md5(pass + salt) + salt)), да еще и считают эти конструкции ну просто мега-защищенными…
Ну. Есть и противоположное мнение :)
25-й комментарий там сильно лучше, имхо =)
Комментарий 24 упускает из виду то, что давно изобретено — вычислительно-сложные хеш-функции. Описанные, например, в PBKDF2.
Почитайте "How To Safely Store A Password".
В MD5 с солью тоже хорошего мало.
У меня лет 7 назад был такой случай:
чел закрывал работу программы мастер-паролем.
Мастер-паролем хранился в файле. Вместо того чтобы придумать сколь угодно простенькое шифрование он решил записывать пароль plain-текстом, но задом наперёд.
А в качестве мастер-пароля он использовал слово-палиндром!
чел закрывал работу программы мастер-паролем.
Мастер-паролем хранился в файле. Вместо того чтобы придумать сколь угодно простенькое шифрование он решил записывать пароль plain-текстом, но задом наперёд.
А в качестве мастер-пароля он использовал слово-палиндром!
Весело лето начинается.
Надеюсь, они не лягут сейчас. Когда я писал о взломе ЛастПасс, все дружно рубанулись менять пароли, в результате чего накрылась временно еще и возможность залогиниться, чтобы поменять пароль.
А вообще, немного порадовался, что постоянно пользуюсь всего какими-то тремя-четырьмя сервисами…
Надеюсь, они не лягут сейчас. Когда я писал о взломе ЛастПасс, все дружно рубанулись менять пароли, в результате чего накрылась временно еще и возможность залогиниться, чтобы поменять пароль.
А вообще, немного порадовался, что постоянно пользуюсь всего какими-то тремя-четырьмя сервисами…
Не тот сайт, от которого надо срочно менять пароль.
Если он один на все сайты, то скорее всего не этот сайт окажется в верху списка «срочно поменять пароль».
Вполне достаточно иметь два пароля — один для мусора типа ластфм, линкедина и прочих мусоросетей, и один для аккаунтов которые действительно чувствительны к потере инфы, типа личного Gmail, где может быть все что угодно, от лицензий на продукты до паролей на корпоративные аккаунты.
В Gmail для этого используется отличная двухэтапная аутентификация.
Говорите, пожалуйста, за себя. «Вполне достаточно» и «всякий мусор» — очень субьективные понятия. Кому-то будет «вполне достаточно» одного логина, без паролей вообще. Кому-то акаунт на Фейсбуке будет важнее онлайн-банкинга.
Тем временем факт остаётся фактом: два пароля лучше одного, но хуже трёх.
У меня на каждый сайт/сервис/команию уникальный пароль. Хранятся в незашифрованном виде в голове. Способ хорошо описан тут: habrahabr.ru/post/145166/
Тем временем факт остаётся фактом: два пароля лучше одного, но хуже трёх.
У меня на каждый сайт/сервис/команию уникальный пароль. Хранятся в незашифрованном виде в голове. Способ хорошо описан тут: habrahabr.ru/post/145166/
Знаете, после того как sic доказал, что возможен подбор паролей типа qCkiYSJ625, мне все эти комбинаторные методы кажутся ненадежными.
пока, все-таки это скорее исключение, а не правило, что такие пароли находятся. Но, на будущее, конечно уже стоит иметь в виду, при вычислительной мощности всего в сотни раз большей моего компьютера — это станет делом обыденным.
Почитал с удовольствием, спасибо за статью.
Но эта статья совершенно не противоречит факту, что уникальный пароль на каждый сервис — безопаснее. Это правда в 100% случаев.
К тому же способ, которым пользуюсь я, не делает пароль менее надёжным — можно придумать пароль любой сложности, и всё равно его усложнить, добавив к нему кастомные префиксы, суффиксы и окончания, как-то зависящие от домена, сгенерированные по известному только вам «алгоритму». Алгоритм можно придумывать настолько сложный, насколько у вас есть фантазии.
Менее надёжным от этого уж точно ничего не станет, а вот угнав пароль от одного сервиса, доступ к другому очень усложнится.
Но эта статья совершенно не противоречит факту, что уникальный пароль на каждый сервис — безопаснее. Это правда в 100% случаев.
К тому же способ, которым пользуюсь я, не делает пароль менее надёжным — можно придумать пароль любой сложности, и всё равно его усложнить, добавив к нему кастомные префиксы, суффиксы и окончания, как-то зависящие от домена, сгенерированные по известному только вам «алгоритму». Алгоритм можно придумывать настолько сложный, насколько у вас есть фантазии.
Менее надёжным от этого уж точно ничего не станет, а вот угнав пароль от одного сервиса, доступ к другому очень усложнится.
«Известный только вам» алгоритм увеличивает сложность пароля незначительно. При условии, что один из таких паролей стал известен злоумышленнику, остальные пароли (с другими префиксами и суффиксами) автоматически становятся менее надежными. И их, в принципе, неплохо было бы тоже сменить.
«Известный только вам» алгоритм увеличивает сложность пароля незначительно.
Вы не поняли. Пароль должен быть сложным сам по себе. Идея такого «алгоритма изменения пароля» не в том, чтобы сделать пароль сложнее, а в том, чтобы сделать его уникальным. При этом пароль автоматически становится сложее, а вот значительно или нет — зависит уже от вашей фантазии. Но даже при полном её отсутствии, результат всегда будет надёжнее, чем оригинал.
При условии, что один из таких паролей стал известен злоумышленнику, остальные пароли (с другими префиксами и суффиксами) автоматически становятся менее надежными.
Совершенно не факт! Во-первых, потому, что компьютеры не умеют логически мыслить.
А во-вторых, можно придумать такой алгоритм, который полностью видоизменит пароль до такой степени, что на двух разных сайтах в вашем пароле не будет совпадать вообще ни однин символ. Тут всё, опять-таки, упирается в вашу личную фантазию и параною.
Впрочем, о чём мы тут спорим? Я лишь заявил, что уникальный пароль на каждый сайт — безопаснее одного пароля на все сайты. Думаю, с этим вы спорить не будете.
Дальше я привёл пример, как можно организовать уникальный пароль на каждый сайт, и легко помнить их все.
Способ работает от «добавить к паролю первые две буквы домена», до математических вычислений, которые вы сможете выполнить только при наличии графического калькулятора. Главное понить, что нужно делать.
Всегда есть группа юзеров, использующих однообразные маски паролей, поэтому для них критична потеря любого такого пароля.
Конечно, ОЧЕНЬ вряд ли, что злые хакеры будут тратить время на подбор других паролей такого юзера, но здоровую паранойю никто не отменял.
Конечно, ОЧЕНЬ вряд ли, что злые хакеры будут тратить время на подбор других паролей такого юзера, но здоровую паранойю никто не отменял.
Да на ластфм уже давно(4 часа :D ) объява висит с просьбой сменить пароль. Сменил благополучно)
А где сами хэши то?
в блоге lastpass есть другая интересная запись, что по следам LinkedIn, благополучно утекла база eHarmony, якобы все тем же русским! (кому же еще?) хакерам
И что с этого? Интересно кому нужен пароль от моего Last Fm аккаунта?
Блин, вот поэтому приходится регистировать на всех сайтах с простейшим паролем, кто знает может они воообще в открытом виде его хранят.
Каким образом это увеличивает безопасность?
Я так понимаю, что этот простейший пароль не подходит к почте и прочим важным местам.
Да, это было бы логично, но тут вопрос в другом: почему использование простого пароля стало неизбежностью?
Ведь не факт, что раньше взломают именно тот сайт, где твой пароль наружу. Если пароль сложен, а аккаунт действительно не слишком ценный — его могут и не забрутфорсить — за ненадобностью. А использовать слишком простой пароль — это уже гарантировать взлом по любому направлению, даже если на всех сайтах (ну хотя бы в этой сказке) и хороший алгоритм защиты.
Ведь не факт, что раньше взломают именно тот сайт, где твой пароль наружу. Если пароль сложен, а аккаунт действительно не слишком ценный — его могут и не забрутфорсить — за ненадобностью. А использовать слишком простой пароль — это уже гарантировать взлом по любому направлению, даже если на всех сайтах (ну хотя бы в этой сказке) и хороший алгоритм защиты.
Это все правильно, только придумывать и помнить 100500 разных хороших паролей не слишком удобно. Мозги не резиновые. Поэтому там, где это не критично, люди используют одинаковый простой пароль, а сложные оставляют для важной инфы. Да, я в курсе про разные хранилки паролей, но это тоже далеко не всегда удобно.
Собственно, об увеличении безопасности в результате использования простых паролей речи и не было. Это просто удобнее.
Собственно, об увеличении безопасности в результате использования простых паролей речи и не было. Это просто удобнее.
А вдруг у вас на почте тот же пароль
Ага! Шансона ещё какого-нибудь наскроблят! :)
Вот что значит у русских хакеров начались летние каникулы :D
Давайте уже пароли от google, а то соцсети, понимаешь всякие :)
Интересный комментарий на реддите (извиняюсь). Парень который заправляет DEFCON cracking contest, рассказал что слив был еще в 2011. База хешей появилась на одном из кряко-форумов и впоследствии была удалена. Утекло 17,3 миллиона уникальных MD5-хешей из которых расшифровано 95% (как минимум этим парнем). В довесок приводится небольшой список самых часто используемых паролей:
cat ./wordlist/lastfm.dict | tr A-Z a-z | sed -e 's/[0-9]//g' | sort | egrep -i .{4} | uniq -c | sort -nr | more
9558 lastfm
8260 last
4792 love
4746 alex
3450 mike
2921 june
2750 chris
2727 music
2691 blue
2646 password
2534 qwerty
2515 july
2495 angel
2466 john
2423 matt
2286 pass
2228 james
2200 april
2174 david
2132 jack
2056 nick
1998 daniel
1923 anna
cat ./wordlist/lastfm.dict | tr A-Z a-z | sed -e 's/[0-9]//g' | sort | egrep -i .{4} | uniq -c | sort -nr | more
9558 lastfm
8260 last
4792 love
4746 alex
3450 mike
2921 june
2750 chris
2727 music
2691 blue
2646 password
2534 qwerty
2515 july
2495 angel
2466 john
2423 matt
2286 pass
2228 james
2200 april
2174 david
2132 jack
2056 nick
1998 daniel
1923 anna
Ссылка на само обсуждение.
Пароль lastfm на сайте lastfm — это, конечно, гениально.
Возможно это тенденция… vkontakte, twitter, facebook… Зачем помнить пароль от сервиса? :)
Статья недавно была, как формировать пароль из доменного имени: habrahabr.ru/post/145166/ Здесь та же идея, только реализация попроще :)
Это нормально для разового использования на сервисе, не содержащем важных данных.
Лично у меня есть подобный простой пароль-заглушка для разовых регистраций в разных местах, там где даже пускать кипасс и генерировать пароль лень, а потеря регистрации ничем не грозит. Last.fm как раз такой сервис, правда аккаунтом там я дорожу, жалко скробблинга, и пароль там как раз сгенеренный.
Лично у меня есть подобный простой пароль-заглушка для разовых регистраций в разных местах, там где даже пускать кипасс и генерировать пароль лень, а потеря регистрации ничем не грозит. Last.fm как раз такой сервис, правда аккаунтом там я дорожу, жалко скробблинга, и пароль там как раз сгенеренный.
password аж на 10 месте? о_О
Зашел на ластфм, просят поменять пароль т.е. если слив был аж в 2011 году, то получается, что они об этом узнали только сейчас, минимум через 6 месяцев, всё это время можно было постоянно сливать пароли, ужас, ужас.
Кто-то уже выложил хэши
hacktalk.net/eharmony.txt
hacktalk.net/eharmony.txt
Как раз собирался обновить пароль на всех сайтах (пора бы уже), да всё руки не доходили. Спасибо хакерам!
Не солишь MD5 — Давай досвидания!
У меня на ластфме было паролем словарное слово, которое и так во всех словарях должно быть. Соответственно, от утечки паролей я не теряю вообще ничего %)
Жаль, что мало кто описывает обратную сторону.
Представим себе небольшой стартап, который надо запустить здесь и сейчас! Тратится минимум кадров и сил на это, главное успеть запустить. При этом выбирается md5() для шифрования паролей.
Портал разрастается, юзеров все больше и больше, и уже за несколько млн.
Встал вопрос о защите паролей. Нельзя взять и добавить каждому юзеру соль. Это или костыль, типа двойных проверок
1) проверяем с солью — все ок — пускаем
2) проверяем с солью — bad — проверяем без соли — ok -> обновляем пароль в базе, выставляя хэш с солью
Или так же костыль, типа перехэширования паролей с солью, а при логине — хэш от пароля, хэш от хэша в пред. шаге с солью
Особенно такие решения тяжело принимаются в больших организациях.
Но это конечно надо, никто не спорит. Но попробуйте сами, работая над подобным крупным проектом.
Представим себе небольшой стартап, который надо запустить здесь и сейчас! Тратится минимум кадров и сил на это, главное успеть запустить. При этом выбирается md5() для шифрования паролей.
Портал разрастается, юзеров все больше и больше, и уже за несколько млн.
Встал вопрос о защите паролей. Нельзя взять и добавить каждому юзеру соль. Это или костыль, типа двойных проверок
1) проверяем с солью — все ок — пускаем
2) проверяем с солью — bad — проверяем без соли — ok -> обновляем пароль в базе, выставляя хэш с солью
Или так же костыль, типа перехэширования паролей с солью, а при логине — хэш от пароля, хэш от хэша в пред. шаге с солью
Особенно такие решения тяжело принимаются в больших организациях.
Но это конечно надо, никто не спорит. Но попробуйте сами, работая над подобным крупным проектом.
Думаю, если объяснить понятно последствия простого md5 и указать на репутацию — переезд на новое хеширование будет воспринят хорошо.
Ну а чем плохи двойные проверки?
На Реддите, где обсуждалась эта тема (про утечку паролей Lastfm) кто то поинтересовался как обстоят дела с єтим на Реддите и в ответ получил ссылку на исходный код, в котором так и сделано — сейчас используется bcrypt, если нет — проверяется sha-1 с солью и потом sha-1 без соли, которые использовались до этого.
И ничего, все довольны, безопасность на высоте.
На Реддите, где обсуждалась эта тема (про утечку паролей Lastfm) кто то поинтересовался как обстоят дела с єтим на Реддите и в ответ получил ссылку на исходный код, в котором так и сделано — сейчас используется bcrypt, если нет — проверяется sha-1 с солью и потом sha-1 без соли, которые использовались до этого.
И ничего, все довольны, безопасность на высоте.
Можно просто сделать:
и пройтись по старым паролям.
my_super_secure_hash_method ( $salt_and_pepper, md5 ( $password ) );
и пройтись по старым паролям.
Загляньте в исходники скробблера и прекратите молоть чепуху. Соль есть. Солью является имя пользователя.
Я могу показаться занудой, но как доверять всем этим «облакам» если даже такие крупные игроки как last.fm и myspace не могут защитить своих пользоваталей. Пока не будет какого-то единого, надежного способа авторизироваться на сайте, прохожу облака мимо
Недавно пришло сообщение от Libre.fm
Они упомянули что недавно утекли пароли у last.fm, linkedin и сказали что сбросили всем пользователям пароли на случай если вдруг они использовали тот-же пароль что и на тех пострадавших сайтах.
Мне кажется что просто и у них слили пароли вот они и сбросили всем.
Они упомянули что недавно утекли пароли у last.fm, linkedin и сказали что сбросили всем пользователям пароли на случай если вдруг они использовали тот-же пароль что и на тех пострадавших сайтах.
Мне кажется что просто и у них слили пароли вот они и сбросили всем.
Sign up to leave a comment.
По следам LinkedIn благополучно утекла база и Last.fm