Пользователь
0,0
рейтинг
7 сентября 2014 в 23:32

Разработка → 1000000 паролей от почтовых ящиков Яндекса утекли в сеть

Сегодня на одном довольно широко известном ресурсе разместили базу email адресов с паролями от почтовых ящиков «Яндекса». База представляет собой текстовый документ, в котором заявлено 1 млн позиций.

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

Когда именно, и по какой причине данная база утекла в сеть, остается неизвестным. В комментариях народ пишет, что из первых попавшихся 10 яшиков как минимум 8 являются на настоящий момент валидными.

В общем, дружно меняем пароли, пока представители «Яндекса» ищут крота.
Alex @lagudal
карма
11,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (550)

  • +32
    Новость масштабная (прежде всего «яндекс хранит пароли в clear text», затем уже «эти пароли украли»). Нагуглить информацию не удалось, полная тишина в сети. Можете предоставить подтверждение своей информации?
    • +4
      Что-то мне кажется, если бы был доступ полноценный, то было бы больше адресов. Себя вот там не нашёл (пароль сменю, на всяк). Коллега предположил, что это коллекция добытая фишингом.
      • +3
        Может быть, фишинг (да, я тоже себя не нашел). Это объясняет целых 75086 повторов с разницей лишь в регистре. Может быть, несколько различных ресурсов объединились и проверили, у кого из юзеров пароль на том ресурсе совпадает с почтовым паролем.
        • +6
          Извиняюсь, за то что оставляю свой комментарий под вашим, но так он будет лучше виден.
          Я добавил на isleaked.com толстую базу аккаунтов mail.ru из этого комментария, которую мне любезно перезалил Voenniy, а это ещё ~5 млн аккаунтов, пусть и слегка устаревших, но работающих. Проверяйтесь, распространяйте и меняйте пароли.
      • +3
        Мы в Яндексе в целом с вашим коллегой согласны, это фишинг и вирусы. Подробнее: habrahabr.ru/company/yandex/blog/236007/
    • –39
      Я понимаю, «хабр — сборище школоты», но вы-то почему к ним примазываетесь? Вроде взрослый человек, а про CRAM-MD5 (если он поддерживается Яндексом, то и требует для него базы паролей в открытом виде) не знаете, ПАРОЛЬВОТКРЫТОМВИДЕКАГЖЕТАГ. Мне стыдно за вас.

      То, что он и в любом случае используется в открытом виде, хотя бы и через SSL — никто не задумывается. К чему это приводит, как пример: heartbleed или иная дырка в сервере, и утекли ваши пароли. Что, думаете, все сервисы затирают ту область памяти, в которой проверялся пароль, надёжно? Хрена с два.

      Проблема не в том, что пароли хранятся в открытом виде. Проблема в том, что для проверки так или иначе используется пароль (или его эквивалент) в открытом виде. Ещё раз, для непонятливых: то, что достаточно сообщить серверу для удостоверения себя, обязательно необходимо сообщить ему в открытом виде, либо он заранее это должен иметь в открытом виде. И это плохо.

      Есть механизмы вроде SRP-6, в которых это требование снимается, и это хорошо. Но он сложный, хорошо если один из тысячи хабровчан, паникующих при словах «пароль в базе в открытом виде», способен реализовать SRP-6.

      И давайте вспомним любимый BGP или хотя бы OSPF. Что там для аутентификации? PSK. Пароль в открытом виде.
      А, ну и CHAP у провайдеров ещё. В Ростелекоме, например.
      • +14
        А что, пароль уже нельзя хешировать в браузере, чтобы он в открытом виде не уходил дальше браузера?
        • +7
          Еще полгода назад я такие меры ругался что, дескать, это свинцовые трусы от спида, теперь, пожалуй, вообще никогда такое говорить не буду.
          • 0
            Я не говорю, что это панацея. Понятно, что при подключении не через веб, а почтовые протоколы, при наличии дыры в ssl, пароль тоже можно украсть. Но для сервисов, где безопастность критична, пусть лучше будет дополнительная ступенька защиты, чем не будет.
            • +3
              Да я это скорее в подтверждение написал, что даже такие меры, как оказалось, лишними не бывают.
        • +34
          Какой смысл?

          Если хешировать в браузере, то хеш становится тем достаточным для аутентификации эквивалентом пароля. Фактически, хеш сам становится паролем в открытом виде, а то, что мы хешировали, уже не важно.
          • +7
            Следующий комментатор предложит сделать аутентификацию двухэтапной и получится CHAP :)
          • +5
            Важно, что этот хеш будет паролем только на яндексе, и больше нигде, а также что пользователю для обеспечения безопасности достаточно любым образом изменить свой пароль, пусть даже приписав одну цифру, а не радикально сменить его.
            • +1
              Мечты, мечты. Каждый сервис начнёт хранить в браузере SHA2(p), а некоторые — MD5(p), и всё, приплыли.
              • +1
                Сервис не будет ничего хранить в браузере клиента кроме куки.
              • +1
                Пусть просто сервис при авторизации высылает клиенту соль для хэширования.
          • 0
            Пароль в открытом виде может подойти к другим сервисам пользователя, зарегистрированным на эту-же почту. А хеш с солью — нет.
            • 0
              У хэша с солью другая задача — чтобы кража базы данных не компрометировала всех пользователей сервиса (как это произошло сейчас у Яндекса). Поэтому браузер не должен передавать хэш пароля, а всегда сам пароль. А чтобы данные не перехватывались снифером — для этого нужен SSL.
              • 0
                Хорошо, когда SSL — гарантия надежности. Вероятность его взлома, конечно не очень большая, но есть и от большинства владельцев сайтов никак не зависит, к сожалению.
                • +2
                  Вы понимаете, что передача хэша не решает проблему? Атака на SSL очень сложна, и чтобы перехватить переданный пароль, все-равно нужен снифер. Если каким-то образом атака на конкретного пользователя оказалась удачной, другие пользователи от этого не страдают. То же, если у сервиса угнали базу (подразумевается, что сервис хранит хэши паролей с солью).
                  А в случае с вашим хешем, снифер сразу перехватывает «пароль» (т.е. по этому пункту система более уязвима). В случае угона базы данных злоумышленник получает доступ ко всем аккаунтам (т.е. и по этому пункту система более уязвима, при чем существенно).
                  Единственный случай, когда, казалось бы, хэш выигрывает — это если пользователь использует один и тот же пароль для разных сервисов. Однако, если у пользователя один пароль для всех учеток, день рождения или 123456 — то это пользователь идиот, а не проблема сервиса.
                  • +1
                    Ну я больше говорю о хешировании как о доп защите, а не замене SSL. Хотя, ниже описали намного более интересный способ, который даже при пробое ssl ничего не выдаст.
                    • 0
                      Да, но это «доп защита» открывает огромную дырень в виде угрозы угона базы паролей.
                  • +1
                    Единственный случай, когда, казалось бы, хэш выигрывает — это если пользователь использует один и тот же пароль для разных сервисов.

                    А сервисы используют разные механизмы генерации хэша.
                    • +2
                      Достаточно просто разной соли
          • +1
            Так и не надо хешировать один пароль. Можно перед хешированием подмешать к паролю какую-нибудь информацию с сервера (например текущее время) и из пароля получится аутентификационный токен, который каждый раз будет разный.
            • 0
              А проверять пароль как? Сервер знает токен и хеш. Как проверить, что хеш=f(токен+пароль)?
              • 0
                Ну теоретически:

                браузер отправляет

                MD5 (MD5(pass + salt) + md5(ip+salt2)), при этом, md5(ip+salt2) браузер предварительно полуает с сервера.

                Сервер хранит MD5(pass + salt) в базе, допустим это hash_pass. Получая с браузера что-то, он проверяет MD5(hash_pass + md5(remote_addr+salt2) ) на равенство с тем, что получил от браузера.
                • +19
                  До изобретения CHAP осталось совсем чуть-чуть :)
                  • 0
                    А в чем отличие уже на данном этапе? ip заменить на id сессии?
                    • +24
                      В вашей схеме есть излишества, ведущие к потенциальным уязвимостям. Например, ваш клиент вычисляет md5(md5(secret | clientSalt) | challenge) — зачем, когда можно вычислять md5(secret | clientSalt | challenge)? В вашем случае, если каким-то образом утечет md5(secret | clientSalt) (с сервера, например, потому что сервер хранит именно md5(pass + salt)), появляется возможность использовать его повторно, а это критическая уязвимость.

                      Сервер генерирует challenge, используя ip — зачем? Соль должна быть случайна, а если соль случайна, её придется временно хранить. Если так, то добавление ip излишне, можно просто отправлять длинную случайную строку и хранить её на время проведения аутентификации.

                      В правильном случае сервер отправляет клиенту длинную случайную строку, которая никак не связана с любыми характеристиками клиента — challenge. Клиент вычисляет response = md5(salt | secret | challenge) и отправляет серверу response и salt, где последняя — это длинная случайная строка, которую генерирует сам клиент. Сервер, зная secret, salt и challenge повторяет вычисление у себя и либо отшивает клиента, либо аутентифицирует его.

                      Очевидный недостаток — пароли хранятся в открытом виде :), а ведь именно этого мы и пытались избежать. Зато это самый всамделишно-настоящий CHAP! :) Поэтому есть вариант лучше, вот его протокол:

                      1. Пользователь вводит некий пароль password.
                      2. Генератору ECDSA-ключей скармливается pbkdf2(password) — на выходе получаем secret и public.
                      3. Клиент говорит серверу — «Привет, я vasya@yandex.ru»
                      4. Сервер проверяет, есть ли у него в базе публичный ключ vasya@yandex.ru, и если да, то говорит клиенту — «Окей, держи длинную случайную строку challenge и некий последовательный счетчик seq, на который ты не можешь влиять и который растет монотонно, никогда не повторяясь».
                      5. Клиент вычисляет response = ecdsaSign(secret, challenge | seq | длинная случайная строка) и отправляет подписанное сообщение серверу.
                      6. Сервер отбрасывает соль, сверяет, что challenge совпадает с отправленным ранее, и проверяет публичным ключом, извлеченным из БД, что подпись верна.
                      7. Готово!

                      В этом случае сервер не знает ни пароля, ни его хэша, и пароль никогда не передается никуда даже во время регистрации. Наличие счетчика обеспечивает неуязвимость к replay-атакам даже в случае дублирующегося challenge. MITM при этом, правда, возможен, так что этот протокол всё равно нужно пускать поверх TLS, чтобы клиент был уверен, что говорит с сервером, а не с хакером.
                      • 0
                        Спасибо за пояснение, вопрос по пункту 6. | это у вас разделитель? А то непонятно, каким образом сервер отбросит соль.
                        • 0
                          Конкатенация — "foo" | "bar" == "foobar". Сервер знает длину challenge, следовательно, может просто взять первые N байт сообщения для проверки верности challenge, но при этом подпись считать от всего сообщения.
                          • 0
                            Понятно, спасибо за поясления.
                      • 0
                        Поэтому есть вариант лучше, вот его протокол:

                        этот протокол всё равно нужно пускать поверх TLS

                        А зачем тогда протокол, когда в TLS уже есть сертификаты и ECDSA или другой асимметришный шифр, и можно аутентифицировать клиента, например, по серийнику ключа или же по cname?

                        А вообще, респект за замечание по поводу неслучайности challenge, если он зависит от ip. Я думал об этом, писать не стал, а следовало.
                        • +2
                          Если вы хотите аутентифицировать клиента средствами TLS, клиент должен получить валидный клиентский сертификат. Я не говорю, что это сложно, но это, как минимум, непривычно для большинства, и сопряжено с рядом неудобств, связанных с хранением и бэкапированием этого самого сертификата, его восстановлением в случае, если «шеф, усё пропало», и реализацией логаута, когда браузер уже спросил, какой сертификат будем использовать и отказывается его «забыть». С серверной же стороны реализация клиентской идентификации тоже не так проста, потому что работает на уровне соединения. Т.е. это всё возможно, но сопряжено с рядом трудностей и для клиента, и для сервера.

                          Тогда как предложенная мной схема использует «обычные пароли» и вписывается в существующую инфраструктуру любого проекта, использующего аутентификацию по паролю, с полпинка.
                          • 0
                            Тем не менее, StartSSL использует именно такой подход: при регистрации прямо в браузере генерируется пара и запрос сертификата, этот запрос передаётся на сайт, откуда возвращается сертификат, строится pkcs12 и встраивается в браузер. И тут же они рекомендуют сделать резервную копию. После чего аутентификация в приватных областях сайта происходит тупо по сертификату.

                            И знаете, использовать это удобно.
                            • 0
                              Для сайта, на котором вы авторизовываетесь изредка под одной учеткой, и всегда с браузера — да, удобно. А вот когда нужен вход с нескольких устройств (импортировать клиентский сертификат в мобильный браузер — не всегда элементарная задача) и возможность зайти откуда угодно, не думая о ключе, то лучше уж обычный пароль — основная масса народа не потянет премудрости TLS-авторизации, переевыпуск ключей, бэкапы и т.д…

                              Протокол, похожий на описанный mwizard используется в Steam. Я не особо разбирался с подробностями, и возможно могу ошибаться в последовательности. Там используется RSA, и схема проще.
                              При нажатии кнопки логина на сайте, делается запрос на /login/getrsakey/ с логином и временем. В ответ приходит публичный ключ RSA (уникальный для пользователя) и им просто шифруется пароль. Правда соли вроде нет, т.е. да. получается что перехваченный ответ можно переиспользовать, но тут не уверен, не отслеживал. С другой стороны, вероятность перехвата TLS-соединения мала, у основной массы пользователей аккаунты взламывают через подставные сайты или троянов.
                              • 0
                                UPD: перечитал и переоисмыслил описанный выше протокол, понял что там все же другое.
                                Steam я привел в качестве примера использования шифрования пароля на клиенте, отличного от популярного md5(pass+salt+...) (и подобных) или plaintext.
                • 0
                  В вашей схеме для аутентификации нужно знать штуку MD5(pass+salt), которая выполняет роль пароля в данном случае. Эти штуки хранятся в базе открытым текстом.

                  Да, проблема «одинаковые пароли на разных сайтах» действителньно снимается, в этом смысле подход конечно лучше.
                  • 0
                    Не только проблема с разными сайтами решается. Если даже перехватите то, что отправляет браузер, это не поможет авторизироваться с этими данными с другой машины.
                    • +1
                      Это потому, что вы изобрели CHAP (поздравляю). Но проблему «SQL-инъекций» это не решает — стырить базу достаточно, т.к. эквиваленты пароля, достаточные для аутентификации, там в открытом виде.
                • +6
                • +1
                  Сервер хранит MD5(pass + salt) в базе
                  — вы это на полном серьёзе предлагаете? Не в шутку?
                  • 0
                    Я исхожу из такого условия. Вопрос был «как проверить пароль». Как хороший способ защиты это не позиционируется. То, что предлагает mwizard выглядит значительно лучше.
              • +2
                Вы правы, в данном случае все равно придется хранить пароль на сервере, тут защита будет только на этапе передачи по сети (для чего в большинстве случаев лучше использовать SSL).

                Тут надо использовать не просто хеширование, а асимметричную криптографию. Тогда можно введенный в браузере пароль превратить в пару открытый/закрытый ключ. Присылаемый сервером токен шифруем в браузере с помощью закрытого ключа, который никуда не передается и нигде не хранится (он вычисляется каждый раз из пароля). А открытый ключ хранится на сервере, позволяя расшифровать и проверить токен.
                • +2
                  google SRP-6
                • 0
                  Ну наверное закрытый и открытый ключ местами надо поменять;)

                  Кстати, чем принципиально генерация закрытого ключа из пароля и сохранение его отличается от получения хеша и из пароля и соли? Что ключ что хеш это производная от пароля, по которой сам пароль восстановить нельзя, а проверить — можно.
                  • +1
                    Зачем менять их местами? Глупость получится же.
                  • 0
                    Пароль и его хэш отличаются от закрытого и открытого ключа тем, что при помощи закрытого ключа можно создать сообщение, которое можно проверить при помощи открытого ключа, тогда как сделать то же самое, используя пароль и его хэш, нельзя.
          • 0
            Есть одноразовые пароли. Это не те, что на бумажке таблицей вписаны, а которые пересчитываются через счетчик и рекурсивный хэш. Вполне спасает от таких проблем.
        • 0
          Это просто смена пароля по сути. Передавать серверу пароль или его простой хэш — практически не изменяет защищенность аккаунта ни для одного вида атак от перехвата трафика до подглядывания ввода на клавиатуре.
      • +1
        Нет ни одной причины в наше время юзать CRAM-MD5 и прочие безопасные алгоритмы, гораздо лучше просто заставить всех юзать SSL правильных версий с правильным cipherlist.

        Да и тем более я не думаю, что много людей юзает почту яндекса через POP/IMAP чтобы подстраивать под них архитектуру авторизации.
      • +3
        а про CRAM-MD5 (если он поддерживается Яндексом, то и требует для него базы паролей в открытом виде) не знаете

        Это тоже было бы оскорблением в их сторону.
        То, что он и в любом случае используется в открытом виде, хотя бы и через SSL — никто не задумывается. К чему это приводит, как пример: heartbleed или иная дырка в сервере, и утекли ваши пароли.

        1) Heardbleed, как и прочие баги, позволяющие длительно и незаметно сосать память сервера, случается редко. Очень редко. Сравните вероятность наличия у сервера подобного бага с наличием у него дыры, позволяющей делать SQL инъекции. Например, select * from passwords.
        2) Heartbleed требует довольно длительного прослушивания, чтобы поймать много паролей. У того же яндекса сессия месяцами может висеть открытой.
        3) Этой же аргументацией можно доказать, что и PKI — отстой, так как у сервера можно незаметно стянуть приватный ключ. Но обычно такого не происходит.
        4) Чтобы инсайдеру стащить базу паролей, в одном случае ему достаточно иметь доступ к базе на любом уровне, а в другом — распространить на все сервера трояна и долго ждать.
        Так что нет, хранение пароля в базе в открытом виде куда страшнее, чем кратковременное его пребывание в памяти и передача через канал в зашифрованном виде.

        А еще наверняка у большинства юзеров один пароль на всё. Потому еще правильнее было бы полностью защититься от его раскрытия и передавать только хеш, а для валидации брать хеш от хеша. Тогда пароль будет иметься в памяти только на стороне клиента. А если клиент скомпрометирован, то тут уж пиши пропало в любом случае.
        И давайте вспомним любимый BGP или хотя бы OSPF. Что там для аутентификации? PSK. Пароль в открытом виде.
        А, ну и CHAP у провайдеров ещё. В Ростелекоме, например.

        В этих случаях предполагается, что риск MITM (или вообще подключения третьей стороны) минимален. Потому и защита минимальна. Вы ведь, надеюсь, не выберете CHAP для защиты чего-либо смотрящего в интернет, еще и без защиты на уровне транспорта (SSL например)?
        • 0
          В этих случаях предполагается, что риск MITM (или вообще подключения третьей стороны) минимален. Потому и защита минимальна. Вы ведь, надеюсь, не выберете CHAP для защиты чего-либо смотрящего в интернет, еще и без защиты на уровне транспорта (SSL например)?

          «Дважды ошибиться в одном и том же человеке? Да, раньше со мной такого не былвало. Старею...»

          Окститесь. Для PPPoE я безусловно выберу CHAP, потому, что к ADSL или Ethernet-линии абонента можно незаметно для него подключиться и подслушать, и если бы это был PAP, подслушали бы пароль, а в случае с CHAP — фигу с маслом. Пусть лучше провайдер знает пароли, чем будет возможна таргентированная атака на пользователей. А SSL тут вообще прикручивать некуда.

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

          Да ладно там, почему сразу трояна. Может быть, код просто кривоват и можно ухитриться сбрасывать пароли в лог-файл. Кстати говоря, Apache вполне можно настроить так, что он будет сбрасывать в debug-лог всю информацию, достаточную для расшифровки SSL-канала, то есть, фактически — лог с паролями в открытом виде.

          А еще наверняка у большинства юзеров один пароль на всё.

          И самым безопасным вариантом будет не давать им возможности задать пароль самостоятельно. В лучшем случае, генерировать несколько и разрешать выбрать, или генерировать и допустить незначительную модификацию. Что вообще разорвёт связь между тем, как хранится такой пароль на сервере и безопасностью остальных сервисов юзера: данный скомпроментированный сервер и так уже скомпроментирован настолько, что база утекла, и хуже уже не будет, а остальные не пострадают.
          • +5
            Для PPPoE я безусловно выберу CHAP, потому, что к ADSL или Ethernet-линии абонента можно незаметно для него подключиться и подслушать

            Это сложно сделать для одиночного пользователя и ОЧЕНЬ сложно для множественных пользователей. Потому и допустимо задействовать такой небезопасный механизм как CHAP. Если есть дополнительные меры защиты (например, логиниться можно только с указанного порта коммутатора), то и PAP допустим.
            Может быть, код просто кривоват и можно ухитриться сбрасывать пароли в лог-файл.

            И это подразумевает очень кривые руки у администраторов.
            И самым безопасным вариантом будет не давать им возможности задать пароль самостоятельно

            Не… Тогда эти пароли будут постоянно забываться (недовольство сервисом), а также записываться где попало. Вот если пароль в открытом виде бывает только на клиенте — это уже не проблема.
            • +3
              Ну, и остаётся SRP-6, который вроде бы всем адекватным требованиям удовлетворяет.
            • +1
              Это сложно сделать для одиночного пользователя

              Что именно сложно?
              • +1
                Именно то, что надо физическое присутствие, установка тапа, установка чего-либо сниффающего и так далее. Я бы не назвал это «просто».
            • 0
              Итого, только что получил:
              Здравствуйте!

              Вы получили это письмо, потому что пользуетесь сервисом Яндекс.Почта для домена.


              Дело в том, что завтра, 16 сентября Яндекс.Почта перейдёт на протокол SSL. При передаче данных по IMAP/POP3/SMTP сервис будет требовать шифрование по SSL. Пожалуйста, измените настройки почтовых программ, которые используют владельцы почтовых ящиков, зарегистрированных в Вашем домене. Иначе с помощью этих программ нельзя будет получать и отправлять письма.

              Мы подготовили для Вас подробную инструкцию, как изменить настройки. Выберите соответствующую программу.


              Из чего следует:

              ЛИБО они имеют мой пароль в открытом виде, т.к. иначе не работал бы CRAM-MD5 (и опция «зашифрованный пароль» в thunderbird)
              ЛИБО мой пароль мог пересылаться в открытом виде по сети, т.к. по-другому они не смогли бы его проверить.

              Уж лучше первое.

              Речь идёт не об основной яндекс-учётке, но тонкость в том, что я в основном и пользуюсь-то почтой той, что на ПДД. И я не настраивал эту почту в программах, использовал через веб-интерфейс, который через HTTPS, так что про себя я более или менее уверен. Но…
              • 0
                Скорее, второе. Наследие былых времен, когда прослушка трафика считалась чем-то крайне нереалистичным, а шифрование трафика и вообще его защита — излишеством.

                Чтобы ужаснуться масштабам бедствия, погуглите «wall of sheep». Это — случаи, когда люди пересылают пароли серверу. При подключении по вайфаю. С открытой аутентификацией. На конференции по безопасности. Среди толпы кулхацкеров разного уровня грамотности (но в среднем такого, что лучше даже несмартфонный телефон оставить дома, на всякий случай).
                • 0
                  Я к тому, что в целом хранить пароли в открытом виде на сервере, при условии того, что это необходимо для защищённой аутентификации по сети — не так уж и плохо. Даже в случае Яндекса, потому, что обязательный SSL он вводит только в третьем квартале 2014 года.

                  А вообще доводилось и мне отравить ARP, вклиниться MitM и перехватить такой вот пароль (никакого SSL не было, конечно). В академических целях, чтобы продемонстрировать знакомому, что это довольно просто, делается на ровном месте и никакого специального оборудования не нужно.
                  • 0
                    Ну тут надо выбирать. Либо повысить вероятность компрометации отдельных юзеров (а у части в любом случае украдут учетные данные, хоть теми же троянами или из-за использования одинакового пароля везде), либо повысить вероятность компрометации вообще всех юзеров.

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

                    У меня давно была идея поднять дома отдельный открытый SSID и пропускать его трафик через отдельную машинку с Cain'ом. Строго в исследовательских целях, не используя эту информацию кому-либо во вред разумеется, и наверное даже с предупреждением (captive portal) о том, что трафик может анализироваться :)
                    • 0
                      А, а в дверь ещё не постучали? Значит, постучат.
      • +3
        Чего то вы ересь несете.
        Пароли надо хранить, пропустив через однонаправленную хэш функцию, что бы в случае утечки их из места хранения нельзя было узнать изначальный пароль и завладеть аккаунтом.

        «хотя бы и через SSL» — ну если для вас ssl не является надежным методом передачи данных, то вероятно вы настолько крутой хакер-нешкольник, что и восстановить пароль из хэша для вас не составит труда.

        Проблема не в том, что для проверки используется пароль в открытом виде, а в непонимании как и почему так это все происходит.

      • 0
        В Яндексе не используется CRAM-MD5. И не использовался никогда, насколько мне известно.
    • +2
      isleaked.com/ проверяйтесь
    • 0
      Конечно, Яндекс не хранит пароли в открытом доступе.
      Вот подробный разбор, что и как: habrahabr.ru/company/yandex/blog/236007/
  • +8
    а где ссылки на пруфы?
    • –14
      Вам сама база что ль нужна? Для спама или проверки на яндекс.деньги? Так-то есть возможность проверить присутствие мыла в базе и так. Одно из своих мыл (годичной давности) я там тоже обнаружил, к сожалению. Незнаю откуда в базу попало это мыло.
      • +29
        Нет. Эта «новость» выглядит не совсем убедительно без подтверждающих это источников.
        «Нагенерить» можно сколько угодно.
        • +1
          Полную базу я из ветки на своем форуме вытер, так как небывалый поток скачиваний пошел после публикации на хабре, но оставил базу без паролей для возможности проверки. Поверьте, база с паролями существует.
          Мне эта ситуация интересна тем, что еще утром шестого числа прошла новость(а на других ресурсах может и раньше), были выложены базы, и тут в ночь на восьмое число такой переполох, даже по ящику показали, что пользователь хабра обнаружил утечку миллионов аккаунтов, и всем вдруг срочно эта база понадобилась и пошли первые комментарии от самого яндекса.
          • 0
            Всё просто — ХабраХабр читают разные журналисты и сотрудники Яндекса. Ну и аудитория гораздо более широкая.
      • +11
        Выкладывайте базу без полных email и полных паролей (например, первые пять символов). Тогда каждый сможет проверить, что база есть и сможет проверить наличие своего ящика в ней.
      • +3
        ЯД вообще в безопасности, максимум сумму на счету узнать можно. Транзакцию без платежного пароля не провести, не сейте панику.
        • +2
          У многих он совпадает с паролем от ящика. Так что, лучше провериться на нахождение своих мыл по ссылкам выше.
          • +13
            Я не уверен, и могу ошибаться, но мне кажется, что ЯД не позволит ввести пароль такой же, как и на саму учетную запись.
            • +4
              По крайней мере раньше давал, и у меня сейчас так ибо удобно. Shame on me.
              • +4
                In this case, shame on Yandex, actually.
              • +3
                И для кого яндекс старался с двухфакторной авторизацией?.. Вы же не станете к сейфу подбирать замок, чтобы подходил ключ от входной двери?
                У меня уже давно платежные пароли СМС-ками приходят. А еще есть токены, как бумажные, так и электронные.
            • +2
              У меня у моей жены так оказалось что пароль совпадал с платежным. Либо раньше не было такой защиты, ибо сейчас точно есть. Но с другой стороны наверное можно поставить пароль на паспорт такой же как платежный, т.е. все в обратную сторону.
              • –2
                «Раньше» это когда? 3 года назад не давал. Точно помню, пришлось этот платежный даже записать.
            • 0
              Ок, для приличного процента нужно будет прибавить единичку
    • +6
      Нашел базу с паролями. Достаточно опасная штука. Нашел красивый ящик, зашел под его данными, оказывается если номер телефона не указан можно указать свой и этим активировать ящик. Т.е. можно сменить пароль на заблокированном ящике не вводя секретные вопросы, какие либо личные данные и т.д. Просто злоумышленник после блокировки ящика может поменять пароль если ящик не привязан к номеру телефона.
      Ящик оказался мертвый, с 2008 года им не пользовались. (ого 6 лет прошло) Никаких данных там нет абсолютно. Ящик видимо создавался, но про него сразу забыли.
      Но вот так вот при желании как я понимаю, можно найти старые ящики без введенных номеров и захватить много данных. Чет яндекс совсем сплоховал, даже система блокировки идеальная для взлома, кроме пароля и логина ничего для захвата не надо знать.
      • +3
        Копался дальше — наткнулся на незаблокированный аккаунт. Выяснил id вконтакте человека и отписал ему о смене пароля. Т.е. даже не факт, что блокировка будет. Хотя натыкался на ящики где есть блокировка + введен телефон, там зайти не получится.
        К слову ящики там достаточно старые, не меньше 2-3 лет каждому.
        • +43
          Завязывай с этим делом. 272 УК РФ в чистом виде. С чистосердечным признанием.
        • 0
          Действительно, заблокировали утёкшие ящики и теперь светят их телефонами.
        • 0
          При таком раскладе Яндекс должен принудительно заблокировать ящики с утекшими данными и выслать пользователям ссылки для сброса пароля. В противном случае будет много утечек Яндекс.Денег например с привязанных кошельков.
          • +1
            Выслать ссылки трудно, если ящик — основной и единственный :)
            • НЛО прилетело и опубликовало эту надпись здесь
              • +1
                Ну дык если могут выслать в мозг — то зачем этот архаичный метод связи использовать? Тогда и новую мыслепочту могли бы уж напрямую слать… Ах да, ведь канал засылки напрямую в мозг надо защитить паролем и шифрованием, а то ведь спам начнут засылать.
      • +16
        Смешно, но из-за это утечки нашел свой ящик, пароль от которого забыл в 2005 году, он оказался жив, все мои древние подписки там же.
        • 0
          А моего нет :( А восстановить не получилось.
  • +4
    Подтвердить или опровергнуть, как, когда и что это было, я не могу. Файл этот у меня есть, если сообщество потребует, передам кому то, чье слово будет достойно доверия. Просто свое мыло я там нашел, пароль был текущий. Так что «Нагенерить» не подходит. По странному стечению жизненных обстоятельств, никогда ничего важного на яндекс-почте не держал и критичной переписки не вел.
    пс. я взял с другого ресурса, но как видно, распространение идет быстро.
    • 0
      Насколько я понимаю, то дело в том, что сообщество, к сожалению, не хочет верить вашему «Просто свое мыло я там нашел, пароль был текущий», в следствии чего требуют пруфов. Очень щепетильная ситуация, я вынужден отметить.

      С одной стороны, вы не хотите подвергать никого опасности, а с другой — сообщество жаждет пруфов…
      • +7
        Если сообщество ждет пруфов, то такое сообщество должно уметь искать пруфы.
        Я нашел базу с паролями бесплатно без смс за 15 минут поиска.
      • +2
        Хотите пруфов? Я подтверждаю, что такая база есть и одна из ссылок здесь выложенных ведет на форум где можно скачать этот архив, в котором файл на 38.1 мб. Один из обитателей сего форума выложил открытую ссылку.
        • –1
          Пруф это не «я подтверждаю», а сама база, возможно с замененными на звездочки несколькими символами из логина и пароля. Хотя, какая разница, если база и так в открытом доступен уже?
    • –1
      Моего мыла нет, но пароль сменил
    • 0
      Можно ссылку на файл, а то неясно: менять ли пароль…
      • +4
        Раз неясно, менять. Что тут непонятного.
      • +3
        А где гарантия что выложили все утёкшие пароли?
  • +5
    Интересно узнать комментарии виновников торжества. Неужели в 2014 году пароли ещё где-то лежат в голом виде?
    • +11
      Интересно узнать не только комментарии виновников, но и самого Яндекса.
    • +5
      ну паролям не обязательно лежать в открытом виде, есть подозрение что если получить доступ к яндексовому CDN который отдает js'ки например, то можно вполне утаскивать вводимые бедными пользователями данные. предварительно их разлогинив ^_^
    • +10
      nic.ru например даже при восстановлении присылает старый пароль.
    • +3
      Больше похоже, что утечка произошла не по вине yandex, а по вине самих пользователей или сторонних ресурсов – пароли лежат в открытом виде, размер базы ничтожно мал по сравнению со всей аудиторией яндекса и т.п.
      • 0
        Моего пароля нет. С Я.Почты настроена сборка почты, поэтому я там почти не бываю. Только в ЯД. Панически всегда проверяю адрес. Плачу от силы в 5 местах…
        Видимо просто развели
      • –2
        своей почты от яндекса не пользовался год, при этом он тоже слит, мне кажется это полюбому косяк яндекса
      • 0
        Там ровно миллион? Слишком круглое число для утечки полной базы. Может быть, опубликовали лишь часть базы, а Яндекс сейчас тихо шантажируют «будем светить по миллиону в день».
        • +1
          1261809 записей
          • +2
            На самом деле чуть меньше. После удаления дублей остается 1186565
  • +3
    Утекла база только классической почты @ya.ru или и почта ПДД тоже присутствует?
    • 0
      Моя ПДД в списке не числится (что, конечно же, не является 100% прувом, но хоть позволяет сегодня уснуть спокойно)
    • +3
      Очень актуальный вопрос, кстати, учитывая корпоративные данные различных компаний и пароли там тоже имеют иную ценность.
      • 0
        Судя по файлу которым я располагаю — нет, почты ПДД там нет. Только yandex.ru
  • +2
    Сделайте сайт на коленке, чтоб проверить утекла почта или нет.
    • +3
      Есть мнение, что те, кто сперли пароли, выкачали их больше чем миллион, просто выложили не все.
    • +19
      • +24
        Собираем спамлист?)
      • 0
        Что-то попробовал почту из файлика выше (тот что без паролей), ваша софтина пишет, что почты нету. Файл с паролями не скачивал)
        • 0
          Какую именно почту? Вроде все загрузил в базу.
          А вы дописали <собака>yandex.ru?
        • 0
          Просто там нужно указывать почту полностью, с собакой и yandex.ru. Я тоже сейчас проверял.
      • 0
        аллиасы не учитываются (example@yandex.ru и example@ya.ru — одно и то же)
        • +1
          В утекшей базе только example@yandex.ru
          Теперь там можно не дописывать <собака>yandex.ru, а просто ввести ник.
          • 0
            Кстати, не заметил ни одного мейла вида номертелефонаyandex.ru, хотя они вроде бы только в этом году появились?
            • 0
              Таких в базе около 150 штук
          • 0
            Ещё одно: dash-dot@ya.ru и dash.dot@ya.ru — это один и тот же ящик.
      • +44
        ПОЧТЫ В БАЗЕ НЕТУ! Расслабьтесь. Спасибо.
        Внутренний параноик опоздал и противно шепчет: «Теперь есть».
        • +1
          Ну пароль-то Вы не вводили =)
      • +5
        Вопросики вместо текста, кодировку поправить бы (Safari 7.0.6, Mac OS X Mavericks).
        • 0
          Изменил на Utf-8
      • НЛО прилетело и опубликовало эту надпись здесь
      • +7
        почему нет возможности искать по паролю? ;)
        • +3
          хм, до сих пор нужно ставить тег *сарказм*?
        • +4
  • +23
    nataxan, dmJonny, jkt, vsesh, octo47, Zalina, ingdir, stepancheg
    Ребят, почему пароль в открытом виде?
    • +32
      Я не совсем тот к кому вы обращаетесь, но если всписок продолжить, наверное в нем окажусь, поэтому отвечу.
      Я не из паспорта, т.е. мое мнение не является официальным. Но вообщем я достоверно знаю, что пароли у Яндекса в закрытом виде. И в открытом, на сколько мне известно, никогда не были (по крайней мере 10 лет назад когда я пришел в компанию, точно были закрытыми).
      Что на самом деле произошло вам наверное ответят официально, когда разберутся.
      Комментарий kabachok ниже про то, что в списке встречаются логины по несколько раз в разном регистре, что скорее говорит о сборке паролей со ввода пользователя считаю разумным объяснением.
      habrahabr.ru/post/235949/#comment_7940865
      • +1
        Предположу, что в этом сливе аккаунты тех, кого в какой-то промежуток времени «поимел» кейлоггер.
        • +1
          А как тогда объяснить такое habrahabr.ru/post/235949/#comment_7941233
          или хотите сказать кейлоггер запускали более шести лет назад, а сейчас только база всплыла?
          • +1
            А почему вы это исключаете? Например, тырили 10 лет подряд, но вспыло только сейчас, потому, что кто-то облажался и потерял осторожность, или просто какой-то чудик слил базу.
            • +3
              Вообще, база однозначно получена разными способами.
              Нашёл один точно свой акк (совершенно случайно, просматривая список коротких адресов в поисках «красивых»), как его слили — загадка. Проблема в том, что акк во-первых регался ну очень давно (оценочно — 2005-2006-ой), во-вторых регался с целью получить спам-почту для регистрации на другом сайте (временных емейлов тогда то ли не было, то ли я о них не знал), в-третьих кроме этого сайта врядли где-то мною использовался (т.е. на 90% уверен, что я его зарегал — ввёл и всё).
              Нашёл в списке ещё один акк, предположительно временно мой, но насчёт него однозначно не уверен.

              Примечательно, что основного яндекс-акка (который вполне себе регулярно используется) — в списке нет.
              • 0
                А пароль на том сайте случаем не совпадает с паролем к почте? Может быть через него и утёк?
      • 0
        А вот тут опровергают:
        habrahabr.ru/post/235949/#comment_7941801
  • +2
    так а пруфы-то будут?
    • 0
      Пароли реальные, аккаунты тоже. Какие тут ещё пруфы? Ссылку на базу автор по понятным причинам не опубликовал.
      • 0
        Интересно, как это спасет кого-то? если база уже ходит?
        • 0
          Ну какая-никакая защита от скрипткиддисов на волнах эпидемии.
  • +1
    Ждем пруфов.
    Но на всякий пожарный сменил пароль.
  • +4
    Интересный факт. Почта зарегистрированная год назад присутствует, а почты созданной в 2000 году нету.
    • +1
      Тоже самое.
    • 0
      Те кто зарегистрировал почту в 2000 году много реже подвержены всякому фишингу и более подозрительны. Если проще: лучше разбираются в IT.
      • +2
        Мне кажется Torna имел в виду два своих почтовых ящика :)
        • 0
          Пардоньте :) Но наблюдение, IMHO, по большей части верное.
  • 0
    Подтверждаю, почта зареганная весной этого года присутствует (и да, пароль подходит)
    • +1
      P.S. Вангую массовую выгрузку личных фото и т.д. где-нибудь на бордах.
      • +5
        Глюкозы, Анны Семенович и Максима Галкина?
        • +19
          Вы представляете себе что будет на личных фотом Максима Галкина?
          • +33
            Куда заплатить, чтобы не выкладывали?
            • +27
              1BQ9qza7fn9snSCyJQB3ZcN46biBtkt4ee
              Любая сумма, и я обещаю не выкладывать, если вдруг они окажутся у меня.
  • +2
    Себя не нашел, но пароли лишний раз сменю
    • +14
      сам также подумал и сделал, а затем задумался, если утекли связки ящик — пароль для относительно недавно зарегистрированных, не будет ли смена пароля возможностью для злоумышленников его получить. Если его менять сейчас. Ведь они могли выложить этот список, чтобы заставить других сменить пароли, и получить их тоже :D
      • +2
        я на такой случай двухфакторную нацепил бы. Не в курсе у яндекса есть это или нет.
        • +7
          Нет у них MFA. Шел 2014 год…
        • +3
          вроде у них ее нет. Хотя есть привязка телефона для восстановления.
          Кстати со стороны всех сервисов с привязкой телефона, было бы очень правильно присылать смску по факту смены пароля, с уникальным ключом для отмены сего дела.
          • 0
            Лучше ключ для подтверждения смены пароля, с почтой даже за 5 минут можно много чего сделать!
            Но двухфакторная авторизация в современном виде мне не нравится одним аспектом… потерял телефон — трудности с доступом(хоть и временные, но довольно длительные), нет сети — трудности с доступом, проблемы у мобильного оператора — трудности с доступом. Слишком от многих факторов станет зависеть доступ к ресурсу.
            • 0
              Ну так печатайте одноразовые пароли. Ну и носите бумажку с собой.
          • 0
            У яндекса при отвязке телефона нужно подтвердить это через SMS, приходящее на него же, либо номер отвяжется через месяц. Т.е. после смены пароля нельзя быстро отвязать телефон, если нет к нему доступа + придет SMS. Но по факту смены пароля смски не идут, да…
      • 0
        Черт, логично, теперь спокойно не засну, несмотря на использование аккаунда для регистрации на третьесортных ресурсах
        • +11
          В любой непонятной ситуации — ложись спать.
          • 0
            :3 пожалуй так и сделаю. И каждый день, в течение недели буду менять пароль.
            • +2
              звучит как шантаж :)
      • 0
        Менял пароль 3 недели назад, в базе не числюсь.
  • –10
    Видимо причина того, что угнаны только пароли свежих ящиков в том, что с недавних пор Яндекс плотно сотрудничает с органами и видимо для них и был сделан сбор паролей в отдельное место.
    • +2
      [sarcasm] И этим местом был icloud, откуда и утекли пароли. [/sarcasm]
  • +20
    Скорее всего база запаролена, пароли утекли как то иначе, скорее всего пользователи из сами вводили.
    в базе замечено две почты
    aleksandr-kOblyakov
    aleksandr-koblyakov
    различается лишь регистр одной буквы
    Смею предположить что пользователь сам писал логин и пароль, где-то.
    • +9
      Кстати таких примеров там очень много. Может быть какая-то масштабная фишинг-атака была.
      • +11
        Была фишинг атака. Долгое время приходили письма от «службы поддержки» — а-ля «ваш яндекс-кошелек требует идентификации, зайдите туда-то»… очень правдоподобные письма, не попадающие в спам.
    • НЛО прилетело и опубликовало эту надпись здесь
    • –5
      Я еще нашел такую же парочку — ylalakeks ylAlakeks

      ИМХО, это вброс от самого Яндекса, чтобы народ массово пошел менять пароли :)

      PS. Своей адрес в базе не нашел, но пароль сменил… блин, уже забыл на какой… :)))))
  • +6
    Яндекс отреагировал.
    Скриншот
    image
    • 0
      А если телефон не привязан? Кто-то в курсе?
      • +2
        не все аккаунты из базы заблокировали.
        • +1
          О, а теперь элементы теории заговоров на сон грядущий, так сказать.
          1) Если заблокировали не все (возможно просто еще не успели), то по каким критериям ведется отсеивание?
          2) Если заблокировали все из этого списка, но не залочили некоторые новые аккаунты не из списка (проверил) — это можно расценивать как то, что список мейлов знаком Яндексу и делать соответствующие выводы (в меру персональных шизы, фобий, здравомыслия и т.д.)
    • +3
      Яндекс блокирует файлы с паролями, залитые на Я.диск
      Заголовок
      image
      • +15
        По иронии судьбы пароли от Яндекс.Почты выложили на Яндекс.Диске:)
        • +2
          Они уже повсюду…
      • 0
        Интересно, как они их определяют, по хэшу, или по содержимому?
        Яндекс начал сканировать загруженные пользователями файлы как гугл?
        • 0
          Думаю, на Диске просто есть инструменты по дедупликации, так что скорее просто по хэшу, совпадающему с заблокированным файлом.
    • +1
      Это не яндекс отреагировал. Это их бот который следит за действиями пользователя (места, время, поведение и тд и тп) залочил подозрительную активность.
    • 0
      Тоже утром появилась эта надпись при входе в аккаунт. Судя по журналу, 6 сентября кто-то через казахстанского провайдера залогинился в мой аккаунт по IMAP.
  • +1
    Начали блокировать. Собственно, свою там и нашел, но, благо, почта ненужная, и пароль легко забрутфорсить.

    Скрытый текст

    • +7
      Пароли в утекшей базе добыты не методом брутфорса.
      • +6
        А почему не брутфорсом?
        Не фишингом точно. Я в свой аккаунт не захожу уже минимум год, только почтовик туда по имап ходит. Однако пароль таки в файле есть.
        • +2
          По моему тут результат нескольких атак и брутфорс, и фишинг, и кейлогер слишком много разных условий использования даже в рамках этого топика + похоже очень разные периоды их(атак) проведения.
  • 0
    del, быстро коменты пИшете :(
  • 0
    Интересен метод утечки. Может через какое-нибудь яндекс.пиво (бар) и прочее, что требует ввода пароля.

    Кстати что мешает любому трояну вообще пароли от чего угодно утягивать путём прописывания авторизационных хостов в hosts и проксирования на реальные сервера?
    • +3
      Просто в hosts низя, если https.
      • 0
        Да, там https, при чем с HSTS прямо в preload list.
        Так что если троян — то хукал системные вызовы на валидацию или глобальный сертификат на систему ставил.
        • 0
          Рядовые пользователи склонны не читать кукаю-то муть про сертификаты и нажимать «Далее» и «Разрешить».
          • 0
            Вы устанавливали корневой сертификат в систему? Там не просто пару кликов) довольно мутное и явно незнакомое окно для пользователя, слабо верится в 1млн+ случаев.
            • +1
              я не хацкер, но мне кажется ничего нереально нет, в том, чтоб корневой сертификат поставить в автоматическом режиме. другое дело, что в ff, например, они свои, но это просто можно учесть.

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

              но это всё настолько должно быть на уровне рефлексов, даже у продвинутых пользователей, что обычные пользователи остаются без шансов в этом плане. у меня лично винда прожила 8 лет (с миграцией по железу и с апгрейдом ОС) без антивируса. Тут главное правило — вовремя обновляться. А уж не кликать по непонятной фигне — не самое сложное.
            • +1
              на фишинговом сайте можно и не использовать https — 1 миллион юзеров легко этого не заметят
        • 0
          Нафига такие сложности?! У яндекса навалом сервисов, которые работают тупо по http, но имеют кнопку 'Войти', по нажатию на которую вылазит красивая формочка ввода пароля без адресбара (чтобы проверить, куда ты пароль вдалбливаешь), вместо явного перехода на passport.yandex.ru. Вот через все это дело можно легко организовать MITM-атаку. Дополнительно способствует отсутствие DNSSEC.
          • 0
            И спасает только возможность настроить браузер так, чтобы он не давал скрыть строку адреса, даже если этого очень хочет сайт.
      • 0
        Только ктож его проверяет?
    • –1
      Ничто :)
    • 0
      Выше написал. Была масштабная фишиниг-атака…
      • +2
        ну это только предположение. если это правда, то мне грустно от глупости 1 млн людей в части безопасности. Кевин Митник уже давно это приметил, но тогда компы только появлялись. тогда можно было, мне кажется, спокойно спросить пароль, сказав, что он был утерян в базе…

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

        и вообще интересно, существуют ли курсы повышения понимания сетевой безопасности? вообще хорошо было бы такие вещи в школе преподавать, на ряду с ОБЖ.
        • +5
          Существуют. Есть у меня один друг, сидел годами на протрояненной насквозь XP под очень древним браузером, говорил «да пофиг, никому я не нужен, пускай взламывают, у меня ни в почте, ни ВК ничего интересного нет». В итоге один раз деньги с карточки увели — с тех пор все выучил и про фишинг, и про то, что обновления ОС/браузера — это не просто окошко, которое надо закрывать — да еще и другим знакомым рассказывает. Они его, кстати, тоже не слушают.
        • +1
          Думаю, некоторые люди просто еще не до конца осознают, что именно они хранят в интернете и как это им может навредить. Они не читают эпические истории о взломе на Хабре, они не знают, что одного пароля от почты достаточно, чтобы увести все деньги, переписки, фотографии и видео, или даже историю перемещения по этой планете, а так же заблокировать твою мобилу и десктоп… и так далее.
          И если в школах и заведут такие курсы в школе — их будут слушать так же, как сейчас слушают литературу/историю и т.д. — то есть те, кому это надо. А кому это надо — тот, как известно, и безо всяких курсов разберется.
          • 0
            ну курсы — это хотя бы что-то. если даже на 5% снизятся глупые уводы паролей, то это уже хорошо.

            чот у меня нет истории перемещения по этой планете((

            ещё кстати, меня удивляет отсталость безопасности многих крупных фирм. был как-то у девчонки в офисе, легко поднял ssh-тоннель с порт-мапом порта прокси. и так очень много где. блокировка сайтов в большинстве фирм вызывает у меня смех или хотя бы улыбку.
            пока не было конторы, где у меня не было бы полного доступа в интернет и для этого даже обычно не нужны админские права, хотя если нужен полноценный l3 доступ, то без админских прав никак, но это тоже не проблема. Есть много волшебных дисков, позволяющих поиметь локальные админские права.
            • 0
              чот у меня нет истории перемещения по этой планете((

              Если нет смартфона с Android — то и истории не должно быть :)
              Эта фишка там, насколько я помню, по умолчанию включается при настройке Google Now.
              • 0
                При первом включении телефона (сброса прошивки) там спрашивается разрешение на сбор GEO-фигни + потом в настройках где-то можно отключить. У меня телефон с Android есть, но истории нет.
              • +1
                Если нет смартфона с Android — то и истории не должно быть :)

                Ой ли? Настройки > Конфеденциальность > Службы геолокации > Системные службы > Часто посещаемые места > Enjoy!
                • 0
                  Простите, а где мне это найти в моем iPhone? :)
                  Извиняюсь, не распарсил. Действительно есть. Только как мне посмотреть, собственно, эти данные на карте?
                  • +1
                    Я и написал, где оно лежит в iOS :) Ну разве что, может, не «Конфеденциальность», а «Приватность» в семерке?
                    Скрытый текст
                    image
                    • 0
                      Благодарю! Не знал, что оно пишет историю — да и все равно почему-то у меня отключено :)
                      С другой стороны — насколько я понял, там только часто посещаемые — у гугла же буквально история перемещений. Были истории, как благодаря этой фиче владелец вычислял по IP находил украденный телефон вместе с вором.
                      • 0
                        Таки да, были )))
                  • 0
                    Так там прямо нажимаете на пакет данных ("… записано мест: NN") и оно нарисует красивую карту со спотами вашего нахождения =)
      • +3
        Я не думаю то это была фишинг-атака. Так как почту (которая в базе) зарегистрировал всего год назад и не пользовался ей.
        • 0
          Ну, сам Яндекс пока что говорит о фишинге.
  • +9
    Есть несколько аккаунтов, на которые захожу раз в год (управление доменами). Ни один не утёк. Скорее всего это не слив базы яндекса, а какая-то очень успешная атака на пользователей.
    • 0
      Аналогично. Аккаунты используются тогда для получения почты через pop в gmail, ни одного нет. Хотя, конечно, не показатель.
      • 0
        Также. Более того — пользуюсь ЯД. Всегда проверяю адрес параноидально.
  • +19
    Совершенно не верю в то, что пароли хранились в plain text, ровно как и в крота на стороне Яндекса. Больше всего похоже на улов большого фишинговой или троян-атаки. Но заголовок заставил взволноваться :)
    • 0
      Хорошо… тогда почему существует максимальная длина пароля? :)
      • 0
        Я не знаю, насколько это правда, но вот отсылка на Бобука 2010 года: m.habrahabr.ru/post/82753/comments/#comment_2458904
        • 0
          Вы действительно в это верите?
          • 0
            Не особо. Но я верю, что пароли не храняться plain текстом.
            • 0
              Допустим не в открытом виде, но есть сомнения, что там в таком случае — хэширование (при чем устойчивое), а не шифрование.
              P.S.
              • 0
                Нет доверия телефону ночью :(
                По способу хранения паролей – ничего сказать не могу. Почему у вас такие сомнения появились? Вы что-то знаете, или ночная паранойя? :)
            • 0
              Еще не так давно пароли хранились почти в открытом виде.

              habrahabr.ru/post/82880/
              • +3
                Это же подставленные пароли самим браузером. Их украсть сложнее, разве что через атаку на CDN, но это надо хорошо постараться.
                • –1
                  Пароли приходили с сервера Яндекса, а не подставлялись браузером!
                  • –1
                    Прочитал ваш топик, из представленных скриншотов html верстки ясно видно следующее:
                    • У поля с паролем пустой аттрибут value, т.е. с серверов Яндекса данные не приходили
                    • У этого же поля отсутствует аттрибут autocomplete, по дефолту его значение может быть равно on, в таком случае браузер может запомнить пароли и подставлять их автоматически
                    • Сейчас у аналогичных полей в верстке прописано значение для аттрибута autocomplete, поэтому проблема не воспроизводится


                    Я сам не разбираюсь почти никак в html, поэтому поправьте, если я не прав.
                    • 0
                      С помощью плагинов в браузере можно запомнить все.
                      • +1
                        Было три топика. Почитайте все. Пароли не хранились в браузере еще раз повторяю. Они приходили в открытом виде с сервера яндекса.

                        habrahabr.ru/post/82317/ — начало здесь
                        habrahabr.ru/post/82504/ — второй топик.
                  • 0
                    пруф?
                    • +1
                      habrahabr.ru/post/82880/#comment_2464458 Если пароли подставлялись браузером, то Яндекс удаленно пофиксил все браузеры мира.
                      • 0
                        А, так это совсем другие пароли…
      • +10
        Технических ограничений на длину пароля давно нет, есть только исторические, и мы с ними активно боремся.
        Конечно же, пароли хранятся только в виде соленых хешей (и более того).
        • 0
          Спасибо, еще давно интересовался в тви — никто не ответил.
          • +3
            надо было спросить у меня на последнем Defcon Russia, если вкратце — скоро этого ограничения не будет.
          • +3
            мне подсказывают, что этого ограничения уже нет, если вы еще где-то его наблюдаете — дайте знать.
            • 0
              Я не хожу постоянно с мыслями о том, есть ли ограничения на пароль или нет. Встретилось — вспомнил.
              Сейчас проверил, ограничения действительно нет, спасибо.
    • +1
      У меня есть 2 аккаунта, которым уже лет по 7-10. Один использовался, как основной, а второй — только на сервисах, где не хватало основной почты (не более, чем на 5 сервисах за всё время), а уже много лет ни тем, ни другим не пользуюсь. Первого в базе нет, а второй — есть. Поэтому не верю я, что это фишинг атака.
  • +1
    если много лоченых (с просьбой сменить пароль), то скорей всего это ботоводские базы украденных дохлых аккаунтов, которые ужа давно спалились, как взломанные. И ботоводы эти списки выбрасывают, чтоб с капчей не заморачиваться.
    • 0
      Заблокированных аккаунтов (навскидку) 35%
      Это не много.
      • +3
        как инструментом обеспечивалась «навскидка», если не секрет? :)
        • 0
          логин Ctrl+V
          пароль Ctrl+V
          Enter
          • 0
            1 милион раз?!
            • +6
              Я не силён в статистике, но для достаточно точной оценки нужно гораздо меньше миллиона.
              • 0
                погрешности не было, так что должны были проверить либо все логины-пароли, либо выбрать какое-то подмножество случайным образом (тут не описано почему человек считает что его выборка достаточно случайна и случайна ли) и проверить на нем.

                В текущей постановке фразы скорее всего проверили, если проверили, 10 логинов-паролей с верху, пару-тройку помотав куда-то и сделали вывод.
  • +13
    Топ-100 паролей из этой базы
    pastebin.com/2YTZMaF0 / privatepaste.com/3415d71c12
    Всего в базе неуникальных паролей (встречаются 10 раз и более) — 7089 штук
    50 раз и более — 532 пароля
    • +4
      qwerty несколько раз в списке встречается.
      • +2
        Спасибо. Проблему с регистром пофиксил.

        Обновленные данные:

        Топ-200 паролей из этой базы
        pastebin.com/jjXpBTz0 / privatepaste.com/a5c023e162
        Всего в базе неуникальных паролей (встречаются 10 раз и более) — 6533 пароля
        50 раз и более — 560 паролей
        • +4
          Либо у Вас база совсем не та, либо кому-то из нас двоих скрипт-фу надо прокачивать. Второе вероятнее.
          У меня 50+ — ровно 600, 2+ — 129127.

          Файл я готовил при помощи cat |awk -F ':' '{print $2}'|sort|uniq -c|sort -nr> passwords
          И дальше можно делать nl и wc -l этому файлу, фильтруя его.
    • +4
      Хм, у меня совершенно другие результаты. Но судя по тому что там querty встречается десяток раз — у вас sort заглючил.

      pastebin.com/HNb8U4Pp
      • +1
        Вот с этим у меня совпадает, вроде.
      • +5
        судя по тому что там querty встречается десяток раз

        О. Подскажите, как вам удалось опечататься в слове qwerty? Всегда хотел знать, как такое можно провернуть:)
        • +2
          Печатал не глядя. Иногда при наборе вслепую получаются совершенно другие слова, например, печатал qwerty, а мозг в этот момент подумал «Что за qwerty? Давай напишем хоть что-то близкое к нормальному слову query». К тому же я не отношусь к той категории интернет-пользователей, которые могут без ошибок воспроизвести слово «qwerty» — зачем такие глупости, когда 123123 набрать проще и быстрее?
        • 0
          Если вы печатаете слепым методом, то, особенно на первых порах, часто случается, что одним пальцем вы набрали следующий символ, раньше чем успели набрать другим пальцем предыдущий. Актуально для печати любым количеством пальцев, кроме одного. Ну и кроме того us — далеко не единственная раскладка в мире. У меня dvorak и там qwerty выглядит как x,doky (могу немного ошибаться, т.к. печатаю по памяти со смартфона). Но u не находится рядом с w и здесь. Так можно опечататься, наверное, при наборе со слуха человеком, не понимающим, почему qwerty пишется так, как оно пишется, либо при использовании других раскладок (я не помню, что там в какой-нибудь azerty).
          • 0
            В другую раскладку можно было бы поверить если бы было azerty или qwertz. Но qu больше похоже действительно на подсознательную коррекцию.
    • +4
      А почему 237 раз встречается пароль «werilopert»? Чего то я паттерн запоминания не понимаю.
      • +9
        Один бот регился
        • 0
          Если посмотреть на e-mails, то вы правы. (dmi<набор цифр>[собака]yandex.ru)
          • 0
            Скорее всего, ботоящик использовался для единственного сайта. Можно зайти на сам ящик и узнать, с каких сайтов приходили подтверждения регистрации — значит, с этих сайтов и слив был.
      • 0
        Просто навыки слепой печати. Пальцы удобно лежат.
  • +4
    Вопрос может оказаться оффтопом, но все же.
    Зашел в журнал посещений, вижу себя и часто в промежутках между моими посещениями такое:
    Заход по IMAP IP не определен
    Такое разве возможно?
  • 0
    У меня две почты на Яндексе. Одна для денег, другая по работе.
    Обе не указаны в списке, который предоставил в ветку Sabin.
    Правда файл весит тут 15 Мб, а не 38, как выше заявлено. (
    • +1
      38 Мб — это с паролями
  • +54
    1. Мы в курсе и занимаемся.
    2. Нет, пароли, разумеется, не хранятся в открытом виде.
    3. Какие-то подробности будут после того, как мы будем иметь больше информации. Возможно — днем.
    • –37
      То есть, вы подтверждаете, что утечка была?
      • +31
        Да, они в курсе что от них была утечка данных которые у них не хранятся.
        • –4
          Это было первое сообщение от офф. лиц. Не понимаю, что я сделал не так, ну да ладно.
          • –2
            Тут вина не яндекса, а самих пользователей, которые вводят свои пароли где попало (фишинг), либо заражены вирусами, либо ещё что-то.
            • +2
              Там есть ящики, которыми с 2005 года не пользовались.
              Есть ящики, которые вообще нигде не светили.
              • 0
                Плюсую, у самого такой попал.
            • –2
              Как сказали, данные собраны не брутфорсом. А чтобы набрать фишингом данные по миллиону юзеров, надо довольно крупный сервис для этого иметь, разве не так?
              • +1
                Или десяток лет неторопливой работы.
    • –1
      Коллеги, пароли на 90.2% цифровые!
      Из цифровых только 10.5% имеют больше 8 символов.
      Т.е. банальный брутфорс и ничего более.
  • +2
    Гляньте кому не лень, в истории входов в этих аккаунтах, может есть что то общее? Может все мыла одного региона или еще чего нибудь
  • –7
    Интересно, утечка связана с тем, что Яндекс стал лить инфу в ФСБ? :)
  • –69
    Пароли просто обязаны хранится в открытом виде.
    Причина банальна: не возможно не зная пароля на сервере поддерживать все защищённые методы аутентификации, там на вход нужно подавать пароль в открытом виде.
    • +55
      Как страшно жить в вашей вселенной.
    • +3
      WAT?
    • +8
      хэш для слабаков
    • +4
      Не рассказывайте никому. А то наши законотворцы еще увидят и обяжут в обязательном порядке так поступать. В некоторых последних законах они явно черпали вдохновение из неудачных комментариев в форумах или соцсетях.
      • –1
        Конкретно в нашей стране все крупные почтовые сервисы первую половину 200-х не поддерживали входа при котором нельзя подсмотреть пароль, те не было TLS и не было ничего с шифрованием пароля, из того что я описал ниже.
        Или плевать всем было или попросили их, но включить APOP или CRAM-MD5 вообще ничего не стоило.
        Сейчас видимо сделали интерфейсы для органов своих а от чужих TLS. Хотя без прибивания сертификатов оно не поможет.
        • 0
          > не возможно не зная пароля на сервере поддерживать все защищённые методы аутентификации

          Все и не надо.

          >Пароли просто обязаны хранится в открытом виде… Там на вход нужно подавать пароль в открытом виде.

          Необходимость подавать пароль в открытом виде не означает необходимости хранить пароль в открытом виде в базе. Сервер получает пароль через TLS, считает от него HMAC с солью, забывает пароль, сравнивает HMAC с хранящимся в базе.
    • –3
      не надо поддерживать методы аутентификации, которые требуют на вход пароль
      • +4
        По сертификатам входить довольно не привычно :)
        А уж по аппаратным ключам и подавно.
        • –1
          Не надо поддерживать методы аутентификации, которые требуют на вход пароль на сервере.

          Ну и деревом прикидываться тоже не надо.
          • +1
            Сложно не имея пароля открытым текстом поддерживать авторизацию по куче разных протоколов и разными методами.
            Либо TLS либо нужно иметь пароль открытым текстом.
            Ещё есть варианты не стандартные / менее распространённые (асимметричное крипто), но они ближе к TLS.
            • 0
              Ну и имейте TLS. Просто, стандартно, секьюрно.

              Зачем вы мне рассказываете как сложно вам поддерживать несекьюрные протоколы?
              • +1
                Есть много протоколов без TLS или где его прикрутили недавно и софт ещё не умеет.
                • 0
                  Но в примеры вы почему-то приводите протоколы, которые давно на TLS? Дайте угадаю, это специальные протоколы класса «неуловимых Джо».

                  Если софт не умеет ни TLS, ни просто авторизации по хешу — выкиньте. Ну то есть можно было бы поступить как гугл с «application-specific password», но вы ж не гугл, поэтому просто выкиньте и не подставляйте ни себя, ни пользователей.
                  • +1
                    telnet — есть драфт и софта почти нет.
                    FTP — в софте далеко не везде реализовано.

                    Так же есть ситуации когда TLS применять не выгодно, а авторизация нужна: например стримиг аудио/видео по HTTP.
                    В таком случае можно разве что через RADIUS гонять digest на более защищённый сервер с базой.
                    • +1
                      FTP в IIS авторизовывал через AD в начале века, остальное проблема софта.
                      Стриминг у нормальных людей работает так: вы авторизовываетесь, вам дают секретную ссылку (Ну или сертификат) и стримьте пока она не протухнет.

                      telnet — это тот случай, когда стюардессу надо закопать. Яндекс его вроде не раздаёт, да и вообще я не знаю кто раздаёт, кроме некоторых хостеров.
    • 0
      толсто, учитесь делать это тоньше!
    • +6
      POP3
      USER+PASS — открыто
      APOP — MD5(rand+pass), где rand — отправляется пользователю сервером
      AUTH — об этом ниже.

      IMAP
      AUTH — точно и может что то ещё.

      SMTP
      AUTH — поддерживает:
      LOGIN — открытым тестом: в первом пакете логин, во втором пароль
      PLAIN — открытым тестом: в одном пакете: «логин»/0«пароль»/0/0
      CRAM-MD5 — требует пароля открытым текстом для работы: «логин»+" " + hmac_md5(rand, password), где rand — отправляется пользователю сервером
      DIGEST-MD5 — требует пароля открытым текстом для работы: md5(md5(«логин» + "." + «реалм» + "." + «пароль») + "." + «соль_сервера» + "." + «соль_клиента») — это часть алгоритма.

      DPA, MSN, NEGOTIATE, NTLM, KERBEROS_V4 — не знаю точно, сам не кодил.

      На данный момент у яндекса:
      для смтп
      250-STARTTLS
      250-AUTH LOGIN PLAIN

      для поп3
      +OK Capability list follows
      STLS
      USER

      Те подразумевается использование клиентом TLS и да, для почты можно хранить только солёные хэши.
      Однако у яндекса ещё вагон и маленькая тележка сервисов и как там происходит авторизация мне не ведомо и не интересно.

      Можно предположить что пароли могли отснифать у юзеров которые не использовали TLS для почты, либо когда была не закрыта дырка в OpenSSL позволяющая читать чужие пароли.
      • НЛО прилетело и опубликовало эту надпись здесь
        • +2
          Это я знаю, но для CRAM-MD5, DIGEST-MD5, APOP и некоторых других открытый пароль необходим с обеих сторон.
          • +4
            help.yandex.ru/mail/mail-clients.xml
            Не-SSL вариантов вроде даже и не предусмотрено.
            Какие там auth-механизмы, впрочем, не указано.

            Блин, печально что Вас заминусовали. Мысли-то интересные, только подача подкачала, увы.
            • +4
              Это тема для откладывания кирпичей, — читать некогда, надо спасать нажитое :)

              SSL — не панацея, кроме описанного выше с левыми сертификатами от валидных ЦС и закрытой дыркой в OpenSSL, теоретически можно на промежуточном узле вырезать/заменить «250-STARTTLS» и есть вероятность что некоторые клиенты воспримут это как должное и не станут возмущаться что TLS вдруг стал недоступен…
          • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              Все, что вы перечислили, автор написал. И даже отметил, что текущие поддерживаемые яндексом методы аутентификации в почте реализуемы без хранения исходного пароля на сервере. Вы как читали-то?
              • НЛО прилетело и опубликовало эту надпись здесь
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    Это я заметил.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        Я выше написал, что так получилось, что у Яндекса по всей видимости никогда не было открытых паролей, поэтому если мысль использовать подобные методы аутентификации для других сервисов и приходила в голову кому-то из разработчиков, то скорей всего не надолго, в связи с невозможностью реализации.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                    • +1
                      Да просто первый же Ваш ответ повторял выводы сделанные в комментарии, на который вы отвечали :)
                      Мне немного обдно стало за Ivan_83. Начал он не очень, это да. Но потом исправился вроде бы. Ан нет.
                      • 0
                        Спасибо за поддержку.
                        Не стоит моя карма такого внимания. ))
                        Всегда можно понаписать в разных топиках что то типа: «молодцы, так держать!» и нахватать плюсов за просто так.
                • 0
                  Перечитайте, пожалуйста, вот этот комментарий, на который вы отвечали: habrahabr.ru/post/235949/#comment_7941221
                  Там перечислены методы аутентификации в почтовых протоколах вообще и поддерживаемые яндексом в частности. А также отмечается, что поддерживаемые методы реализуются без знания оригинального пароля на стороне яндекса.
            • +1
              Написал коммент, потом когда писал второй с подробностями посмотрел.
              Смотрел только на POP3 и SMTP — ещё помню как смотреть на них.
              У яндекса куча мест где можно пароль ввести.

              CRAM-MD5 — там предлагают «хак» с сохранением промежуточного состояния, хэши от двух половинок пароля или его хэша.
              Это секурно (обратно пароль узнать сложно), но в таком виде пароль больше некуда скормить нельзя.
              Более того, если он утечёт в таком виде то его можно будет использовать для авторизации с помощью CRAM-MD5.
      • +1
        Смешные какие CA у Яндекса:

        $ openssl s_client -host mail.yandex.ru -port 443

        1 s:/C=FR/O=KEYNECTIS/CN=CLASS 2 KEYNECTIS CA
        i:/C=FR/O=Certplus/CN=Class 2 Primary CA

        $ openssl s_client -host smtp.yandex.ru -port 25 -starttls smtp
        1 s:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Level IV CA

        Французы да поляки. Никаких «потенциальных противников»…
        Кстати, Unizeto забавная лавка.
        • 0
          Для выпуска левого сертификата подойдёт любой ЦА.
          StartSSL тоже подозрительно — бесплатен :)

          С сертификатами в плане секурности ситуация не очень.
          Часто RSA1024, реже RSA2048 и почти никогда ECDSA. И sha1…
          • 0
            ECDSA чтобы не работать на win xp? :)
            • 0
              Нельзя вечно ориентироваться на устаревшее.
              Не все браузеры полагаются на встроенное в систему CryptoAPI.
              • 0
                >Нельзя вечно ориентироваться на устаревшее.
                Нельзя просто так взять и отказывать в сервисе определенному проценту пользователей в погоне за инновациями.
                Пока никаких проблем безопасности при использовании rsa2048 нет.
    • 0
      Иван, а как же тег <sarcasm> </sarcasm>? Не расстраивайте нас так. Или…?
      • 0
        Сейчас вспомнил, что у нас закон приняли обязывающий сайты хранить и логи и вообще всё что связано с аккаунтом.
    • 0
      Беги!!!
  • 0
    А где ссылка на базу? Стоит ли менять свой пароль?
    • 0
      Выше давали ссылку на «проверить свою почту» games-gen.com/mails/check2.html
      • 0
        Спасибо. Но перешёл по ссылке там нечего нет.
        • 0
          В данный момент сайт лежит под хабраэффектом. Пользуйтесь другими сайтами из этого поста: habrahabr.ru/post/236077/
  • +1
    Список всех слитых email'ов (без паролей):
    db.tt/DYQKYttf
    Проверить слит ли пароль от электронной почты можно также с помощью сервиса:
    yaslit.ru/ (уже чувствуется хабраэффект)
    • 0
      Ваш сайт? Базу слили не 7 сентября, а как минимум 5го днем.
      • 0
        базу слили минимум неделю назад.
  • +3
    Скрытый текст
    123456 39212
    123456789 13931
    111111 9829
    qwerty 7937
    1234567890 5930
    1234567 4684
    7777777 4609
    123321 4326
    000000 3314
    123123 3035
    666666 2813
    12345678 2576
    555555 2417
    654321 2303
    gfhjkm 1816
    777777 1501
    112233 1483
    12345 1478
    121212 1433
    987654321 1389
    159753 1173
    qwertyuiop 1122
    qazwsx 1110
    222222 967
    1q2w3e 943
    0987654321 877
    1q2w3e4r 873
    1111111 832
    123qwe 805
    zxcvbnm 774
    88888888 762
    123654 726
    333333 707
    131313 697
    999999 691
    677
    4815162342 661
    12344321 639
    1qaz2wsx 633
    11111111 615
    asdfgh 611
    qweasdzxc 584
    123123123 578
    159357 575
    zxcvbn 571
    ghbdtn 548
    qazwsxedc 545
    1111111111 526
    1234554321 524
    1q2w3e4r5t 502
    1029384756 469
    qwe123 457
    789456123 449
    147258369 445
    1234qwer 439
    135790 429
    098765 427
    999999999 425
    888888 408
    12341234 408
    12345qwert 401
    qweasd 395
    987654 395
    111222 391
    147852369 382
    789456 377
    asdfghjkl 376
    samsung 375
    159951 365
    vfhbyf 358
    101010 358
    nikita 356
    444444 353
    qwerty123 350
    qweqwe 335
    q1w2e3 331
    marina 331
    fyfcnfcbz 329
    qwaszx 326
    00000000 325
    qazxsw 322
    010203 321
    9379992 318
    123789 318
    zzzzzz 308
    qqqqqq 308
    11223344 307
    dbrnjhbz 306
    qwertyu 304
    147258 299
    12345678910 299
    yfnfif 296
    55555 296
    232323 296
    aaaaaa 291
    fylhtq 289
    147852 289
    fktrcfylh 285
    1qazxsw2 281
    q1w2e3r4 278
    7654321 278
    12 277
    natasha 275
    1 275
    cjkysirj 274
    cdtnkfyf 271
    5555555 270
    qwerty1 268
    5555555555 268
    vfrcbv 259
    123454321 257
    stalker 253
    134679 243
    0000000000 242
    werilopert 239
    666999 238
    124578 238
    252525 236
    1122334455 236
    polina 233
    1478963 228
    212121 223
    qwer1234 221
    yandex 219
    trfnthbyf 219
    192837465 216
    1234 216
    ru 215
    nfnmzyf 214
    hjvfirf 213
    cthutq 210
    sergey 209
    11 209
    2 208
    111222333 206
    fktrctq 204
    741852963 204
    852456 203
    12qwaszx 203
    102030 203
    123654789 202
    qwertyui 201
    090909 200
    1q2w3e4r5t6y 198
    10 198
    142536 197
    010101 197
    maksim 194
    iloveyou 193
    vfvjxrf 192
    rhbcnbyf 189
    123 188
    nastya 186
    password 185
    15426378 184
    0000000 181
    87654321 178
    1234512345 178
    natali 176
    asdasd 176
    753951 175
    serega 173
    lvbnhbq 173
    09 173
    spartak 172
    andrey 172
    906090 168
    121314 168
    master 167
    kirill 167
    321321 167
    02 165
    ybrbnf 164
    7895123 164
    20102010 163
    kristina 162
    123098 162
    132435 158
    12121212 158
    k 157
    genius 157
    555666 157
    454545 157
    19751975 157
    07 157
    1qaz2wsx3edc 154
    05 154
    zaqwsx 153
    porol777 153
    128500 153
    456123 152
    svetlana 151
    q1w2e3r4t5 151
    3830182 151
    1111 151
    08 151
    cjkywt 150
    123456q 148
    1234321 148
    01 148
    dthjybrf 147
    dfvgbh 147
    55555555 146
    151515 146
    1123581321 146
    vfrcbvrf 145
    2010 144
    123qweasd 144
    123456a 143
    0123456789 143
    3 142
    rfrfirf 141
    jrcfyf 141
    135792468 141
    25962596 139
    fanat1234 138
    19891989 138
    oksana 137
    456789 137
    qwerty12345 136
    ruslan 135
    258456 135
    9 134
    666777 134
    007007 134
    sobaka 133
    951753 133
    456456 133
    123456789987654321 133
    19871987 132
    123987 132
    06 132
    565656 130
    adidas 129
    2128506 129
    qazxswedc 128
    dkflbvbh 128
    102938 128
    100 128
    veronika 127
    741852 126
    19831983 126
    12131415 126
    123qweasdzxc 125
    12345a 124
    xxxxxx 123
    a 123
    19951995 123
    privet 122
    31415926 122
    123456654321 122
    if 121
    1725782 121
    147896325 121
    03 121
    123456789q 120
    7 119
    rjntyjr 118
    rfnthbyf 118
    karina 118
    cxfcnmt 117
    8 117
    upyachka 116
    qwert12345 116
    25802580 116
    12345q 116
    19941994 115
    valera 114
    123qwe123 114
    aezakmi 113
    555777 113
    06011982 113
    vladimir 112
    rbhbkk 112
    adgjmptw 112
    5 112
    171717 112
    zxc123 111
    killer 111
    gjkbyf 111
    19931993 110
    naruto 109
    andrei 108
    04 108
    viktor 107
    russia 107
    fktrcfylhf 107
    qwqwqw 106
    696969 106
    135246 106
    ktyjxrf 105
    112358 105
    zvezda 104
    321654 104
    moloko 103
    love777321777 103
    ghbdtnbr 103
    larisa 102
    77777777 102
    7753191 102
    456852 102
    14789632 102
    070707 102
    zaq12wsx 101
    sergei 101
    20092009 101
    irf 100
    8924419 100
    hesoyam 99
    galina 99
    Nhbujyjvtnhbz212 99
    911911 99
    qazqaz 98
    73501505 98
    1a2b3c 98
    12369874 98
    080808 98
    19921992 97
    qawsed 96
    q12345 96
    4 96
    3333333 96
    141414 96
    qwerty123456 95
    dfktynbyf 95
    19851985 95
    ronaldo 94
    22222222 94
    vkontakte 93
    n 93
    7001850 93
    6 93
    rfhbyf 92
    19861986 92
    13 92
    9876543210 91
    14 91
    viktoria 90
    qaz123 90
    gbpltw 90
    forever 90
    787898 90
    1357924680 90
    10z10z 90
    dfkthbz 89
    25 89
    2011 89
    19841984 89
    19 89
    1000000 89
    katerina 88
    19911991 88
    123321123 88
    asd123 87
    202020 87
    123456789123456789 87
    solnce 86
    slipknot 86
    fuckoff 86
    flatron 86
    danila 86
    crjhgbjy 86
    cfitymrf 86
    asasas 86
    13579 86
    e9933429e 85
    909090 85
    789654 85
    12345678900987654321 85
    love 84
    kolobok 84
    q1w2e3r4t5y6 83
    753159 83
    1234125 83
    111111111 83
    01020304 83
    rhfcjnrf 82
    qwerasdf 82
    ekaterina 82
    aleksandr 82
    234567 82
    1366613 82
    ytrewq 81
    svetik 81
    bhbirf 81
    11111 81
    vfhufhbnf 80
    1um83z 80
    17 80
    13243546 80
    123456789a 80
    wwwwww 79
    defender 79
    azamat 79
    235689 79
    19961996 79
    19881988 79
    11112222 79
    0 79
    vladik 78
    tdutybq 78
    ghjcnj 78
    159159 78
    147369 78
    zxcasdqwe 77
    vfvekz 77
    s 77
    pupsik 77
    ghbcnfd 77
    1987 77
    nuttertools 76
    7777777777 76
    23091989 76
    22 76
    15 76
    vfksirf 75
    qwerty99 75
    knopka 75
    dkflbckfd 75
    SuperManBoy 75
    777888 75
    23 75
    1995 75
    1985 75
    17711771s 75
    qazwsxedcrfv 74
    max333 74
    fgtkmcby 74
    barsik 74
    asdfghj 74
    456654 74
    242424 74
    2009 74
    20082008 74
    19811981 74
    yfcntymrf 73
    vbybcnh1 73
    ssssss 73
    romashka 73
    rc 73
    rammstein 73
    lokomotiv 73
    dfcbkbq 73
    cgfhnfr 73
    789789 73
    25081994 73
    1q1q1q 73
    vfhecz 72
    qwerty12 72
    kz 72
    2222222 72
    162534 72
    123456qwerty 72
    11235813 72
    nirvana 71
    323232 71
    28 71
    rfn 70
    r 70
    pdtplf 70
    microlab 70
    matrix 70
    fyutkbyf 70
    freedom 70
    asdfghjk 70
    angelina 70
    223344 70
    1q2w3e4r5t6y7u8i9o0p 70
    19411945 70
    18 70
    132456 70
    123698745 70
    111333 70
    zaq123 69
    vfczyz 69
    fytxrf 69
    deniska 69
    anastasia 69
    987456 69
    272727 69
    21 69
    192837 69
    123abc 69
    122112 69
    021065 69
    rfrnec 68
    kotenok 68
    fuckyou 68
    dfkthf 68
    963852741 68
    963852 68
    300487 68
    1qa2ws3ed 68
    110442 68
    0192837465 68
    loveyou 67
    1983 67
    123qaz 67
    12345654321 67
    12290423 67
    1011111 67
    w123456 66
    scorpion 66
    rctybz 66
    drjynfrnt 66
    d6v1n41d6v1n41 66
    321654987 66
    135798642 66
    07101962 66
    yfnfkmz 65
    nfy 65
    koshka 65
    9999999 65
    9562876 65
    27 65
    24 65
    19801980 65
    13131313 65
    12345678901234567890 65
    tatyana 64
    denn98 64
    1996 64
    1986 64
    147147 64
    1237895 64
    tkbpfdtnf 63
    motorola 63
    567890 63
    343434 63
    1989 63
    1988 63
    rjycnfynby 62
    ntktajy 62
    m 62
    dbrnjh 62
    898989 62
    4648246482 62
    333777 62
    20 62
    10203040 62
    valentina 61
    ufkbyf 61
    q1q1q1 61
    london 61
    840451 61
    777999 61
    321123 61
    2000 61
    1357908642 61
    123zxc 61
    030303 61
    windows 60
    qweqweqwe 60
    nfytxrf 60
    999666 60
    1976 60
    123456789z 60
    1212121212 60
    11041988 60
    qwer12 59
    qwe123qwe 59
    alenka 59
    abc123 59
    9999999999 59
    333666 59
    222333 59
    1994 59
    14881488 59
    1236987 59
    0102030405 59
    q12345678 58
    pantera 58
    hfytnrb 58
    gegcbr 58
    1998 58
    1978 58
    16 58
    123465 58
    123456z 58
    vbkfirf 57
    rhjrjlbk 57
    rfnz90 57
    motherlode 57
    margarita 57
    asdf1234 57
    a123456 57
    25800852 57
    1991 57
    1980 57
    122333 57
    12031990 57
    09051945 57
    rehbwf 56
    aspirine 56
    794613 56
    22091991 56
    19901990 56
    19821982 56
    19781978 56
    19761976 56
    161616 56
    varvara 55
    toyota 55
    tokiohotel 55
    svoboda 55
    fkbyjxrf 55
    e 55
    arsenal 55
    a12345 55
    Angelina 55
    789987 55
    654123 55
    456321 55
    2008 55
    1999 55
    134679852 55
    1239811 55
    0000 55
    zxcv1234 54
    z 54
    warcraft 54
    rrrrrr 54
    heckfy 54
    artemka 54
    789123 54
    787878 54
    26 54
    1997 54
    1993 54
    19731973 54
    ybrjkfq 53
    rjhjktdf 53
    ranetki 53
    poiuytrewq 53
    kakashka 53
    alexandr 53
    alexander 53
    99999999 53
    784512 53
    777666 53
    525252 53
    321678 53
    321456 53
    060606 53
    vfibyf 52
    terminator 52
    rfntymrf 52
    lololo 52
    i 52
    ghbywtccf 52
    6606025 52
    19981998 52
    19971997 52
    1984 52
    172839 52
    123asd 52
    123451 52
    020202 52
    012345 52
    vitalik 51
    vfvfgfgf 51
    qwertyqwerty 51
    ltybcrf 51
    hjccbz 51
    daniil 51
    bagira 51
    b 51
    963258 51
    321679 51
    1979 51
    191919 51
    111111a 51
    050505 51
    zzzzzzz 50
    zaqxsw 50
    vfntvfnbrf 50
    vasilisa 50
    tamara 50
    t 50
    samara 50
    rtyuehe 50
    nissan 50
    lfitymrf 50
    ghjcnjnfr 50
    byajhvfnbrf 50
    Noob572 50
    98 50
    3333333333 50
    29 50
    2222222222 50
    1981 50
    19283746 50
    181818 50
    1598753 50
    123789456 50
    1234560 50


    Есть и однобуковные пароли о_О