[Решето] WineHQ login database compromised.

Ну и кому нужны логины-пароли от сайта wine? Очевидно же, что там скорее всего банально спам-базу собрали.

Ты кое-что забываешь. Есть гении, которые не используют отдельный пароль даже для мыла, на которое идут все восстановления. ССЗБ, конечно, но все-таки

Пароли в БД то всё равно не в плейнтексте.
Нет, ну конечно, можно выискать в БД самых злобных буратин, у которых пароль такой, что быстро подбирается по словарю, да ещё и к мылу подходит... но что толку то? Таких будет очень немного.

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

Главное чтобы пароль был более-менее стойким и не подбирался по словарю. Если твой акк на поломанном сайте не имеет каких-либо особых прав, целенаправленно подбирать именно твой пароль никто не будет.

Как звать твоего кота/твою собаку? Или скажи девичью фамилию своей матери :).

Ну в почту попробуют стукнуться, я думаю.

Мне, кстати, интересно, кто тот неумный человек, который первым додумался использовать девичью фамилию матери для восстановления пароля? Будто бы её очень сложно узнать злоумышленнику.

На хабре статейка была как чувак на видяхах пароли щёлкал. Так вот он там дофига насобирал, даже относительно длинных и несловарных паролей.

Погугли статейку, она интересная.

Стукнуться с чем? Для этого сначала надо пароль подобрать. А если он не подбирается по словарю - то тратить время никто не будет.

Сам задаюсь этим вопросом. Почему я никогда не видел, чтобы вопрос можно было вводить свой собственный?

Что он там щёлкал? MD5, который голым уже нигде не используется?

больше 8 символов, не словарных... но один фиг ссыкотно 8)

>Почему я никогда не видел, чтобы вопрос можно было вводить свой собственный?
O_o
Вообще-то на большей части сайтов можно.

Ага, номер паспорта, дату рождения ...

Почему я никогда не видел, чтобы вопрос можно было вводить свой собственный?

гмыло позволяет точно )

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

Хмм, стойкое воспоминание, что не видел ни разу. Хотя всё равно я в ответ чепуху пишу.

> phpmyadmin

*sigh*

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

Хы, видимо тот старый добрый setup.php, с FTP инклудом :)

>Как звать твоего кота/твою собаку?

Пельмени.

Шутка ли, на куче серваков он стоит досихпор эта протухшая версия.

Httj7gр7yt6hg8j6g86
Вот так зовут :)

Только когда реально пароль потеряю - то обычно с концами. :)

Да, я хорошего мнения о веб-мастерах приличных ресурсов. И даже знаю, что на старых сайтах, где был голый md5, в своё время его меняли на что-нибудь вроде md5(md5+salt).

s/на старых сайтах/на некоторых старых сайтах/
fix, конечно же

Они пароли что, не солили?

Не солят пароли только мудаки.

>Пароли в БД то всё равно не в плейнтексте.

Надежды юношей питают… Сколько уже утечек от крупных монстров, типа той же Sony, показывало, что пароли часто открытые. Исследования же по ним целые публиковались.

>Что он там щёлкал? MD5, который голым уже нигде не используется?

Я всё ещё на своих проектах использую шифрование MD5 :)

Голое? md5(pass)?

Извини за грубость, но смотри выше.

Если у тебя голый MD5, то про тебя выше правильно написали.

>Я всё ещё на своих проектах использую шифрование MD5 :)

Чёрт, вот я тормоз. Посмотрел сейчас — у меня используется sha1 с присоединённым к паролю логином (чистой соли нет). Не помню просто, сколько лет назад менял последний раз систему авторизации, лет 5 или 6 назад :)

Это лучше, но не идеал. Если пользователя зовут svu, то в случае с коротким паролем это не спасёт.

Идеальный случай, конечно, с случайной солью.

>Голое? md5(pass)?

Извини за грубость, но смотри выше.

Всё не так однозначно. Какой смысл мне сильно шифровать пароли на своём «уютном бложике», например?

А вот с серьёзным заказчиками — куда курьёзнее. В двух крупных проектах заказчик явно требовал использование plain-text паролей в базе :)

…

Хотя, как уже писал ранее, в итоге, оказывается, у меня базовый класс sha1 использует. Но он тоже скомпрометирован, да.

>Идеальный случай, конечно, с случайной солью.

Для новых проектов, видимо, так и сделаю. Проблема в том, что для старых проектов заставлять менять пароли всем юзерам — огромный геморрой :)

Потому что {SUBJ}.

Сопрут с твоего уютного блоджика базу — и в случае несолёных паролей у пользователей начинает болеть голова о том, где они ещё с таким паролем зарегистрировались.

А если хорошо посолишь — то они могут этой базой только подтереться. И то, если распечатают.

>и в случае несолёных паролей у пользователей начинает болеть голова о том, где они ещё с таким паролем зарегистрировались

А таких пользователей жалко, что ли? :)

Тем более, что «взлом» md5 даёт же только коллизии, а не сами пароли и на другой системе шифрования (в т.ч. с солью) эта коллизия уже будет бесполезна.

Не надо заставлять, сделай варианты. Например, заведи соль в отдельном поле и генерируй её при смене пароля, или заведи соль в самом хэше и проверяй по формату хэша.

Проверки оставь обе. Либо по наличию соли в её поле, либо по формату хэша (в зависимости от того, где будешь соль хранить).

Для всех новых пользователей и при смене пароля у старых пользователей будет использоваться соль, но для старых пользователей не меняющих пароль всё будет работать как раньше.

Ну можешь ещё письма после этого всем разослать с кратким объяснением ситуации и советом сменить пароль, хотя бы на тот же самый.

>Например, заведи соль в отдельном поле и генерируй её при смене пароля

Ну да, вариант. Не обязательно при смене, просто при логине же пользователь уже пароль введёт — можно перегенерировать.

…

Что там из методик шифрования сегодня самое цивильное? (про соль-то понятно, но её злоумышленник тоже утянуть может :D)

Тем более, что «взлом» md5 даёт же только коллизии, а не сами пароли и на другой системе шифрования (в т.ч. с солью) эта коллизия уже будет бесполезна.

Ты базы паролей сайтиков видел когда-нибудь? Если пароль 12345, qwerty, или другой короткий (а таких большинство), то с вероятностью около 100% после «взлома» будет не какая-то коллизия, а этот конкретный пароль.

Кстати, про логин — не подумал, спасибо за мысль.

Тогда и письма рассылать не нужно.

про соль-то понятно, но её злоумышленник тоже утянуть может

Соль не для того, чтобы пароль не подобрали вообще. Соль для того, чтобы пароль не посмотрели по прегенерированным таблицам.

>Тогда и письма рассылать не нужно.

Ну, тут вопрос в старых, редко заходящих юзерах и времени, когда будет убран старый механизм :)

>для того, чтобы пароль не посмотрели по прегенерированным таблицам.

А, так коллизии сейчас тупо так ищут? Ясно, я-то думал, процессорные мощности загружают… :)

Кстати, по поводу plain-text. Интересная мысль — пробовать асимметричное шифрование для паролей.

Типа, шифрующий ключ — открытый, с ним шифруем введённый пользователем пароль и проверяем корректность.

А расшифровывающий пароль надёжно упрятан, скажем, вообще недоступен в обычном режиме на сервере. Но если заказчику понадобится посмотреть оригинальный пароль — можно воспользоваться расшифрующим ключом и посмотреть :)

Сложность подбора конкретного пароля (при знании соли и алгоритма) она не увеличивает.

А вот от радужных таблиц и иже с ними спасает.

Вы строите б^Hанальные системы?

Я строю то, что хочет заказчик. А в ряде случаев он хочет иметь возможность видеть пароли :D

Эм, ну для похапэ:

crypt('password', '$6$rounds=10000$saltsaltsaltsaltsaltsaltsaltsalt$');