LINUX.ORG.RU
ФорумTalks

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

 


0

1

We are sorry to report that recently our login database for the
WineHQ Application Database was compromised. We know that the entire
contents of the login database was stolen by hackers. The password
was encrypted, but with enough effort and depending on the quality
of your old password, it could be cracked.

http://www.winehq.org/pipermail/wine-users/2011-October/097753.html

★★★★★

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

Ramen ★★★★
()
Ответ на: комментарий от Ramen

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

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

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

Ramen ★★★★
()

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

Andru ★★★★
()
Ответ на: комментарий от Andru

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

Ramen ★★★★
()
Ответ на: комментарий от post-factum

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

Ramen ★★★★
()
Ответ на: комментарий от Ramen

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

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

true_admin ★★★★★
()
Ответ на: комментарий от Xellos

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

Ramen ★★★★
()
Ответ на: комментарий от Ramen

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

Andru ★★★★
()
Ответ на: комментарий от post-factum

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

Ramen ★★★★
()
Ответ на: комментарий от post-factum

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

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

Andru ★★★★
()
Ответ на: комментарий от Ramen

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

Xellos ★★★★★
() автор топика
Ответ на: комментарий от Ramen

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

post-factum ★★★★★
()
Ответ на: комментарий от Ramen

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

winddos ★★★
()
Ответ на: комментарий от post-factum

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

Пельмени.

MrHouse
()
Ответ на: комментарий от winddos

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

winddos ★★★
()
Ответ на: комментарий от post-factum

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

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

winddos ★★★
()
Ответ на: комментарий от winddos

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

Ramen ★★★★
()
Ответ на: комментарий от Ramen

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

Ramen ★★★★
()

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

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

ChALkeR ★★★★★
()
Ответ на: комментарий от Ramen

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от Ramen

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

Ramen ★★★★
()
Ответ на: комментарий от KRoN73

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

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

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от ChALkeR

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

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

ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

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

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

ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

ChALkeR ★★★★★
()
Ответ на: комментарий от KRoN73

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

ChALkeR ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от ChALkeR

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от ChALkeR

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

SHA512 c 10к заходами.
Это теоретически делает хэш слабее, но если вписать скажем 100к, то жизнь того, кто его будет брутить, станет намного веселее.

winddos ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.