Comments 139
А как, если не секрет, в результате DDOS-атаки воруют пароли?
и получается на free-lance.ru они хранятся в открытом виде? или их собираются расшифровывать?
ни кто расшифровывать хеши не будет. достаточно сравнить с хешами часто используемых паролей.
это скорее не «расшифровать», а «подобрать» :)
сопоставить
сбрутить
согласен, так более научно звучит )
Тогда уж "найти коллизию".
Я надеюсь что на таком сайте как фриланс какую нибудь экстравагантную «соль» все таки добавляют.
вы востанавливали пароль там до взлома? Как сейчас не знаю а раньше они были не зашифрованы.
На почту они отправляют пароль в открытом виде =/
Шухарт и не писал, что пароли украдены во время DDoS-атаки.
Ну, я на самом деле не совсем корректно написал с самого начала. Потом подправил текст. Так что претензия вполне обоснованная :)
Изначально фраза звучала двусмысленно: «Многие уже, наверное, знают о том, что в ночь с 21 по 22 марта сайт free-lance.ru был подвержен DDoS-атаке. Есть мнение, что в результате «утекла» вся пользовательская база вместе с логинами/паролями».
Сейчас стало значительно понятнее, спасибо.
Сейчас стало значительно понятнее, спасибо.
Сменил. Пусть и был относительно безопасный, но сменил на более сложный. Ибо аккаунт здесь мне стал дорог.
Утечка паролей с фриланса и простые пароли на Хабре — две разные проблемы.
В топике, чтобы два раза не вставать, подняты обе проблемы и предложено изящное их решение :)
В топике, чтобы два раза не вставать, подняты обе проблемы и предложено изящное их решение :)
Еще упомянута третья, на мой взгляд самая важная ввиду неочевиднсти, проблема — совпадение паролей на разных ресурсах.
На самом деле это и есть первая, потому что сама по себе утечка паролей с фриланса нас, грубо говоря, мало касается. А вот тот факт, что пароли могут совпадать (и, я уверен, у многих совпадают), озвучен вполне доходчиво.
Эм… Кажется, меня не поняли. Я говорил про неочевидность для людей с одинаковыми паролями того, что такая практика может вызвать проблемы.
А, в глобальном масштабе :) Да, увы, это проблема крайне актуальна. И, что самое обидное, никто, кроме самих пользователей, решить ее не сможет.
И везде все равно поставят один и тот же пароль, правда немного другой.
Человек, который хотя бы попытается реализовать подобную систему, достоин хорошего подзатыльника как минимум. А тот, который реализует — недельных пыток щекоткой.
А если серьезно, то жестко решать за пользователя, какой у него будет пароль, не давая при этом его сменить, — крайняя степень невежества. Такое допустимо в исключительных случаях.
А если серьезно, то жестко решать за пользователя, какой у него будет пароль, не давая при этом его сменить, — крайняя степень невежества. Такое допустимо в исключительных случаях.
может это была просто DoS атака через запрос к бд? т.е. доступ к БД есть, дамп уже слит, и напоследок решили положить базу.
«но мы не сможем его полноценно защитить, если пользователь этому препятствует, устанавливая пароль вида «123456» или «qwerty»»
Препятствуйте пользователю устанавливать такие пароли ;)
Препятствуйте пользователю устанавливать такие пароли ;)
MD5 не панацея, если не уметь им пользоваться.\
Да и вообще MD5 мёртв, да здравствует SHA-512.
Да и вообще MD5 мёртв, да здравствует SHA-512.
Да нет, MD5 действительно не очень жив, про rogue-ca читали? Вполне успешная атака на MD5.
А парень тот может быть хорошим безопасником теперь стал, фанатизм — это полезно :-)
А парень тот может быть хорошим безопасником теперь стал, фанатизм — это полезно :-)
Мне интересно, а если вдруг одна перемычка окислится, когда он будет запускать комп.
Самоуничтожение? :)
Самоуничтожение? :)
Спасибо. Добавил еще две цифры к паролю.
Для поддержания мирового равновесия убрал две цифры из пароля.
Всё-равно контрольная сумма мира не сойдется.
Возможно убранные Kraeved и добавленные welovedoit цифры одинаковы, да и вообще мир подвержен коллизиям…
42 :-)
Неа. Даже если они одинаковые были — не сойдется. Они ведь находились в разных местах. Hash(«ABC»)!=Hash(«CAB») для любой более-менее адекватной хеш-функции.
Не факт — положение цифр может быть и одинаковым, если учитывать, что мы живём в многомерном пространстве. А собственно порядок цифр в обоих случаях мог совпадать. Мыслям тоже свойственны колизии. Например, если попросить вас закрыть глаза и подумать о инструменте, то большая вероятность что вы подумаете о красном молотке. :)
Хм… я почему-то сначала о скрипке подумал, потом о инструментальном профилировании в Visual Studio, потом прочитал о молотке и вспомнил что еще и такие инструменты бывают :)
А о порядке — это да, я ошибся. Если в базе данных мира эти два пароля шли подряд без разделительных байтов и цифры были убраны в конце одного и добавлены в начале другого пароля, то да, сойдется.
А о порядке — это да, я ошибся. Если в базе данных мира эти два пароля шли подряд без разделительных байтов и цифры были убраны в конце одного и добавлены в начале другого пароля, то да, сойдется.
я тоже добавил 2 цифры! теперь у меня пароль из целых 3 цифр!!!
Хаброюзеры, обратите внимание, о вас заботятся. ;)
Одинаковые пароли в двух разных системах — не секурно =)
Минусующие, объясните пожалуйста, почему вы с этим не согласны
Я не минусовал, но объясню: часто приходится регаться на разных рандомных сайтах, для галочки.
На этот случай есть дефолтовый лёгкий пароль.
Кой-то чёрт дёрнул меня когла-то зарегать себе аккаунт на фрилансру, блин, теперь придётся поменять пароль в паре мест, где аккаунт мне стал более-менее дорог.
На этот случай есть дефолтовый лёгкий пароль.
Кой-то чёрт дёрнул меня когла-то зарегать себе аккаунт на фрилансру, блин, теперь придётся поменять пароль в паре мест, где аккаунт мне стал более-менее дорог.
Да, я прекрасно понимаю когда для всяких одноразовых сайтов используется один и тот же пароль, сохранять или запоминать разные пароли для сотен сайтов — бредово.
Но аккаунты на хабре и фрилансе я бы к обычным не отнес (первый — в связи с нелегкодоступностью, второй — так как обычно это все таки бизнес, какой-никакой)
Но аккаунты на хабре и фрилансе я бы к обычным не отнес (первый — в связи с нелегкодоступностью, второй — так как обычно это все таки бизнес, какой-никакой)
System notice: Вы не можете задать пароль 123456, этот пароль уже используется пользователем hacker на mail.ru
Одинаковые пароли на разные сервисы?! Это надо исключительно доверять абсолютно всем сервисам, где зарегистрирован и верить, что ни один из них не провтыкает твой пароль и и не использует его в корыстных целях. Я как-то себе такого пофигизма позволить не могу — во многих ведь областях деньги крутятся. А Вы как?
Для всех говносайтов у меня один пароль,
Для нормальных сайтов — цифры и буквы с капчи при регистрации.
Для нормальных сайтов — цифры и буквы с капчи при регистрации.
Капачи ж короткие (4-6 символов), не?
А запоминать как? Записывать где то тоже несекьюрно.
Кстати, а на самом free-lance.ru деньги крутятся или там только «служба занятости»?
Интересно, что примерно в этот же период была DDOS-атака на 4pda.ru Возможно есть связь?
Насколько я понимаю, подобные случаи — хорошая иллюстрация, почему лучше хранить «соленые» хэши паролей (т.е. пару salt, md5(salt + passwd) вместо просто md5(passwd)).
а вдруг с базой утащили и соль?
Ессесно утащили.
Дело в том, что соль затрудняет использование rainbow tables.
Дело в том, что соль затрудняет использование rainbow tables.
Соль может быть «вшита» в код.
(чихает) у меня аллергия на константы в коде.
Соль в коде, конечно, полезна, но это не отменяет случайной соли для каждого юзера в базе.
Соль в коде, конечно, полезна, но это не отменяет случайной соли для каждого юзера в базе.
Случайная, это как random(1000000) чтоли?
Хе-хе. Как я догадался.
Вихрь Мерсенна (Mersenne twister) — это генератор псевдослучайных чисел (ГПСЧ), разработанный в 1997 японскими учёными Макото Мацумото (松本 眞) и Такудзи Нисимура (西村 拓士).… этот генератор не является криптостойким, что ограничивает его использование в криптографии.
… Вихрь Мерсенна реализован в библиотеке gLib и стандартных библиотеках для PHP, Python и Руби.
© ru.wikipedia.org/wiki/Вихрь_Мерсенна
Вихрь Мерсенна (Mersenne twister) — это генератор псевдослучайных чисел (ГПСЧ), разработанный в 1997 японскими учёными Макото Мацумото (松本 眞) и Такудзи Нисимура (西村 拓士).… этот генератор не является криптостойким, что ограничивает его использование в криптографии.
… Вихрь Мерсенна реализован в библиотеке gLib и стандартных библиотеках для PHP, Python и Руби.
© ru.wikipedia.org/wiki/Вихрь_Мерсенна
Вообще, очень хороший вариант иметь соль в коде. При утечки БД, расшифровка паролей стновится очень тяжелой задачей.
Случайная соль для каждого юзера… одно другому не мешает, можете почитать комментарии ниже :-)
Случайная соль для каждого юзера… одно другому не мешает, можете почитать комментарии ниже :-)
Так соль должна быть случайная для каждого пароля.
Так что взломщику для взлома пароля будет требоваться не просто база md5 от известных паролей, а база md5 от известных паролей для всех возможных солей — а это будут на порядок большие объемы данных (в зависимости от битности соли).
Так что взломщику для взлома пароля будет требоваться не просто база md5 от известных паролей, а база md5 от известных паролей для всех возможных солей — а это будут на порядок большие объемы данных (в зависимости от битности соли).
Соль не может быть случайной для каждого пользователя, иначе как сверять пароль?
Ну как — очень просто. В базе лежат тройки:
user salt md5(salt+passwd)
соответсвенно если какой-то user ввел пароль, то берем salt из таблички, солим введенный пользователем пароль, берем md5 и сравниваем со значением в табличке.
user salt md5(salt+passwd)
соответсвенно если какой-то user ввел пароль, то берем salt из таблички, солим введенный пользователем пароль, берем md5 и сравниваем со значением в табличке.
Ну тогда соль вместе с базой и утечёт. Уж лучше где-нибудь не в базе спрятать функцию, генерирующую соль по user_id.
Не вижу ничего плохого в том, чтобы прятать соль в базе. Если соль содержит в себе хоть несколько символов (например 3-4), то тогда размер базы разных md5(salt+passwd) для взломщика будет настолько чрезмерным, что смысла взламывать не будет.
Ну для этого и md5(fixed_salt + user_id + passwd) достаточно вроде, не вижу особого смысла хранить соль в бд.
Ну да, пожалуй можно и так, хоть это и чуть менее секьюрно, но видимо несущественно.
почему это менее секьюрно? Если соль хранится в базе то это не усложняет «перебор», а доступные по размерам hdd rainbow расчитываются видеокартами за дни. соль в базе сегодня почти бесмысленна. функция генерирующая соль по user_id лучше, т.к. можно иметь доступ к базе и не иметь доступа к исходникам.
Изобретаете особую домашнюю криптографию? ;-)
Лично я вроде не изобретаю ничего, а какие-то по-моему очевидные вещи говорю :)
Вы будете спорить с тем, что user_id менее случаен чем соль?..
Про fixed_salt в сорцах можно согласиться. Кстати, я бы предложил делать hash(peruser_salt + password + fixed_salt), т.е. fixed_salt ставить на последнее место. Почему? Хэши обычно проходят по строке в прямом порядке, т.е. для всех строк после прохода fixed_salt состояние будет одинаковым. Читал про так называемые атаки «с общим префиксом»…
Хотя это уже уходит в теоретизирование. :-)
Про fixed_salt в сорцах можно согласиться. Кстати, я бы предложил делать hash(peruser_salt + password + fixed_salt), т.е. fixed_salt ставить на последнее место. Почему? Хэши обычно проходят по строке в прямом порядке, т.е. для всех строк после прохода fixed_salt состояние будет одинаковым. Читал про так называемые атаки «с общим префиксом»…
Хотя это уже уходит в теоретизирование. :-)
Ну, если у атакующего есть вся база данных, то user_id и «случайная» соль, хранящаяся в этой же базе, одинаково «случайны», так сказать :)
А вообще я и не собирался ни с чем спорить — возможно, Вы меня просто где-то не так поняли. Ничего плохого в случайно соли, естественно, нет, вот только если она утекает вместе с хэшами (и известно, как она используется), то и толку с неё я особо не вижу.
А вообще я и не собирался ни с чем спорить — возможно, Вы меня просто где-то не так поняли. Ничего плохого в случайно соли, естественно, нет, вот только если она утекает вместе с хэшами (и известно, как она используется), то и толку с неё я особо не вижу.
Нет, случайны они по-разному.
То, что вы не видите с неё толку — не говорит о том, что его нет. Хотя, возможно, вы знаете что-то, чего не знаю я про эту часть современной прикладной криптографии, например, какие-то конкретные цифры эффективности посола паролей относительно текущих вычислительных мощностей.
То, что вы не видите с неё толку — не говорит о том, что его нет. Хотя, возможно, вы знаете что-то, чего не знаю я про эту часть современной прикладной криптографии, например, какие-то конкретные цифры эффективности посола паролей относительно текущих вычислительных мощностей.
P.S. вы же не говорите, что с хэш-функции нет толку из-за того, что известно, как она устроена? ;-)
Ну и пусть течёт. Она так и задумывалась, как «несекретная» часть.
Может быть, я сказал!
у меня вдруг родилось ощущение что пароли лежали в открытом виде :)
Спасибо что сообщили! Уже поменял свой пароль.
Вот ссылка на Hash Generator, если вдруг кому интересно.
Вот ссылка на Hash Generator, если вдруг кому интересно.
почему бы чаще не использовать OpenID — стырили базу, а там половина людей не по паролям (думаю много кто использовал бы)
Зато очень весело будет если стырят базу OpenID :)
Э-эх… Если бы везде был OpenID, у меня бы под клавиатурой не было записан 130 паролей от «не важных» сайтов. :-)
Ну и, пожалуй, своему OpenID провайдеру я бы не доверил доступ на free-lance.ru (и любой другой сервис, где есть данные моей кредитной карты, какие-либо счета и т.п.).
Ну и, пожалуй, своему OpenID провайдеру я бы не доверил доступ на free-lance.ru (и любой другой сервис, где есть данные моей кредитной карты, какие-либо счета и т.п.).
Зевнул, поменял пароль, emerge -avu world :)
Мне любопытно, а какую систему взломали? Был ли это «дырявый» IIS или «у-меня-нет-дыр» linux-система?
Извиняюсь за беспокойство, но уже минут 20 не могу сменить пароль. При каждой попытке выдается сообщение об ошибке: «Пустоту сохранить невозможно!», хотя, я там все нужные поля заполняю.
И еще, я не специалист в этом, но мне кажется, что URI вида
«http://username.habrahabr.ru/ajax/users/settings/?userdata%5Bpassword_old%5D=йцукенqwerty&userdata%5Bpassword%5D=qwerty&userdata%5Bpassword_repeat%5D=qwerty» не совсем безопасны… Но, если я не прав, это не странно, ведь, я не специалист.
И еще, я не специалист в этом, но мне кажется, что URI вида
«http://username.habrahabr.ru/ajax/users/settings/?userdata%5Bpassword_old%5D=йцукенqwerty&userdata%5Bpassword%5D=qwerty&userdata%5Bpassword_repeat%5D=qwerty» не совсем безопасны… Но, если я не прав, это не странно, ведь, я не специалист.
Когда же создатели публичных сервисов перестанут хранить в открытую пароли? Подсоленный md5 ведь придумали уже давно!
Отдельное спасибо за быструю смену пароля на сайте ;)
Вот, черт… беда… Спасибо что предупредили…
имея уникальные рандомные пароли на каждом ресурсе, минимум по 12 символов — становится жалко потенциальных взломщиков O_o
то ли лыжи не едут, то ли я такой дурак — надо автоматически генерировать пароль и высылать пользователю на ящик, а в таких случаях — принудительно повторять операцию
Sign up to leave a comment.
Внимание! Пароли!