Сотрудники Facebook имели доступ к паролям пользователей Facebook и Instagram

    Новый скандал на тему приватности и сохранности персональных данных разгорается вокруг Facebook и Instagram.


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

    Со слов Pedro Canahuati, ответственного за безопасность и приватность высокопоставленного сотрудника Facebook, данная внутренняя уязвимость уже «была устранена», а пользователи, чьи пароли могли быть скомпрометированы, «получат об этом оповещение».

    Так же Pedro Canahuati упоминает, что «системы логина устроены таким образом, что маскируют пароли с использованием технологий, которые делают их нечитаемыми». Хорошее объяснение от высококвалифицированного специалиста, являющегося лицом крупнейшей в мире корпорации?

    В публикации Pedro Canahuati подчеркнул, что данные пароли «никогда не были видны никому за пределами Facebook» и не было обнаружено никаких доказательств того, что кто-либо «злоупотребил доступом к этим данным».

    Впрочем, не-обнаружение релевантности факта не отменяет вероятность его релевантности. И было бы странно, если корпорация Facebook признала эти факты публично, подтвердись они во внутреннем расследовании. Попытка сохранить лицо в таком случае выглядела бы еще более натянутой.


    Тот самый Pedro Canahuati, который мог видеть в том числе ваш пароль.

    Официальные представители Facebook и Pedro Canahuati явно лукавят. Несколько дней назад информация о внутренней уязвимости была опубликована в посвященном информационной безопасности блоге KrebsOnSecurity.

    Общественность узнала печальные факты пренебрежения крупной корпорацией сохранностью паролей пользователей благодаря инсайдеру внутри Facebook, по данным которого упомянутые пароли хранились в незащищенном виде с 2012 года. Со слов инсайдера, в Facebook было известно об этой уязвимости. В публикации KrebsOnSecurity так же говорится о том, что «скомпрометированными оказались 200-600 миллионов пользователей Facebook, так как их пароли хранились в открытом виде и доступ к ним имели более чем 20000 сотрудников Facebook».

    Дальнейших комментариев со стороны представителей Facebook не последовало. Другой сотрудник Facebook по имени Scott Renfro, взять интервью у которого удалось журналистам блога KrebsOnSecurity, отказался говорить о масштабах скомпрометированных учетных записей и количестве сотрудников, которые могли получить доступ к паролям пользователей.

    Важным во всей этой истории остается факт, что информация о внутренней уязвимости была опубликована в блоге Facebook через несколько дней после того, как «неудобный» инсайд появился в блоге KrebsOnSecurity.

    Из всей этой истории назревает несколько вопросов:

    1. Действительно ли в Facebook приняли меры по исправлению уязвимости?
    2. Действительно ли к паролям не имел доступ никто, кроме сотрудников социальной сети?
    3. Действительно ли получат оповещения все пользователи, чьи пароли были скомпрометированы?
    4. Стоит ли вновь ждать подобных новостей о корпорации, не раз пренебрегавшей приватностью пользователей?
    5. Будут ли в Facebook искать сотрудника-инсайдера, причинившего значительный ущерб деловой репутации компании и раскрывшего информацию о существовании уязвимости?
    6. Имеют ли сотрудники российских социальных сетей неофициальный (не баг, а фича) доступ к паролям пользователей?
    Поделиться публикацией

    Комментарии 64

      –2
      Это не уязвимость, а запланированное поведение.
      Ну, возможно круг имеющих доступ только оказался чуть шире запланированного. С чего вы решили что фейсбук будет сам от себя охранять ваш пароль, который (вместе со всеми остальными «вашими» данными) они давно присвоили себе? Они не благотворительная организация.

      Тут так: совсем мелкие организации не шифруют пароли по нубству (хотя последнее время всё больше начинают использовать скаченные с инета готовые движки где шифрование есть), те что по-больше начинают шифровать потому что это модно, либо из каких-то мутных крипто-утопических соображений, а самые крупные подходят к этому делу рационально и взвешивают все плюсы и минусы данного занятия. Плюс только один — избежать потенциальных потерь репутации когда кто-то это спалит, всё остальное — минусы и они обычно перевешивают.
        +3
        всё остальное — плюсы


        А какие вообще могут быть плюсы от хранения пароля в открытом виде?
          +2
          Так-то плюсы есть, но Ваш вопрос видимо подразумевал «какие плюсы могут быть от храненя пароля в открытом виде стоящие того что бы их так хранить»? Тогда вопрос более сложный, но опять же, в некоторых несколько искусственных ситуациях плюсы возможны.

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

          BalinTomsk это вообще мало кто знает. Даже на хабре (дада, прям тут, на ресурсе для крутых технарей который типа сделан крутыми технарями) уходят в открытом виде, но Вас это от общения тут не останавливает:) Так что — всем по фиг, даже тем кто знает как надо.
          На руборде хз как именно они хранятся, но при напоминании приходят в открытом виде на почту, а форум весьма старый, хороший и популярный до сих пор.
          Единственное где мы помним пароли в открытом виде штатно имели возможность не уходить — это vbulletin, там делался md5 на пароль (на яваскрипте) перед отправкой его на сервак.

          недавно и вконтакте мог вполне себе прислать «забытый» пароль на почту.

          koldoon мы еще страннее вещь скажем. Какое-то время назад гугл при восстановлении пароля просил вспомнить хотя бы примерно старый пароль, часть его или типа того. И запрос о восстановлении тогда уходил на ручное рассмотрение. Вопрос — а на фига если у них нет паролей в открытом виде?
            +1
            Единственное где мы помним пароли в открытом виде штатно имели возможность не уходить — это vbulletin, там делался md5 на пароль (на яваскрипте) перед отправкой его на сервак.

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

              0

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

                0
                Хэш можно «посолить» чем-нибудь, отправленным с сервера. И тогда хэш каждый раз будет разным. Пример реализации: mito-team.com/ru/article/2008/secure-http-authentification
                  0
                  Если клиент будет солить хэш каждый раз перед передачей на сервер, он не совпадет с соленым хэшем, который хранится в базе данных на сервере, разве нет?

                  UPD.
                  Перечитал внимательнее: ок, если сервер передает соль, это будет работать. Пароль в таком случае можно превратить в сессионный токен (соль должна «протухнуть» со временем и замениться новой, иначе эта процедура бессмысленна).
                    0
                    Поглядите реализацию по ссылке. Соль генерится каждый раз заново при отображении формы, и протухает или при отправке формы, или по таймауту. В любом случае, соль — одноразовая.
                    0

                    Эта схема реализует проверку


                    sha1(sha1(passwordFromUser) + salt) == sha1(sha1(password) + salt)


                    При этом в базе хранится sha1(password).


                    Если хакер сможет прочитать таблицу users, то получит доступ к сайту, поскольку всегда сможет вычислить sha1(sha1(password) + salt). С этой точки зрения данная схема эквивалентна хранению нехешированного пароля, а потому небезопасна. Да, в общем случае хакер не будет знать реальный пароль, но доступ к уязвимому сайту всё равно получит.

                      0
                      А если делить пароль пополам?

                      Первую половину передавать в открытом виде, а на сервере хранить только её хэш. Тогда получив доступ к таблице, хакер не будет знать первую половину пароля.
                      Вторую половину передавать описанным способом, для исключения перехвата.

                      Тогда для взлома потребуется и доступ к таблице users, и перехват первой половины пароля.
                        +1

                        Никогда не пытайтесь придумать свою криптографическую схему!


                        Для исключения перехвата пароля лучше всего использовать HTTPS. А ваша схема точно так же эквивалентна хранению в БД нехешированного пароля.

                          0
                          HTTPS в общем случае не исключает man-in-the-middle. В корпоративных сетях, к примеру. Или при принудительной установке в систему доверенных корневых сертификатов.
                            0

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


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

                              0
                              > 5-символьный пароль легко подбирается брутфорсом
                              При размере соли, прилетающей с сервера, символов в 20, пятисимвольный пароль превращается в 25. И соль на каждую попытку разная. Брутфорс уже не прокатит.
                                +1

                                Хакер, перхватывая трафик, получает текущую соль, а затем получает соответствующий ей хэш. Далее он сможет забрутфорсить несколько символов пароля, соответствующих этому хэшу. 20 символов соли роли не играют, потому что в этом процессе будут константны. Соль нужна исключительно, чтобы предотвратить использование радужных таблиц.

                                  0
                                  мне кажется, вы путаете соль с nonce. соль это защита от радужных таблиц
                                  0
                                  > достаточно перехватить нехешированную часть и хешированную и использовать их как есть

                                  Не совсем корректно. Если хешированная часть долетела до сервера, то соль устараеет, и перехваченные данные становятся бесполезными.
                                    +1

                                    Так, мы ещё не забыли, что у нас хранится в базе?

                                  0
                                  Тут описано как этого избежать

                                  habr.com/ru/post/336738

                                  В конце концов есть EV.
                                    0
                                    В корпоративной среде у вас может принудительно лежать в системе доверенный корневой сертификат и отдаваться необходимая CAA запись DNS-сервером.

                                    И тогда https-трафик будет читаться не намного сложнее http.
                                      0
                                      А какова вероятность, что в корпоративной среде будет сделано все это для намеренного хищения пользовательских данных?))) Провернуть такую штуку для фишинга — крайне сложно, поэтому https — это выход из ситуации.

                                      Но если вы не доверяете каналу, вы всегда можете работать через proxy/vpn.

                                      К тому же никто не мешает добавить факторов авторизации помимо логина и пароля, что сделает вход в систему более защищенным, раз уж на то пошло.
                        0
                        Вопрос — а на фига если у них нет паролей в открытом виде?
                        У них могут быть хеши. Хешируют то, что вы прислали и сравнивают с тем, что у них есть.
                          0
                          У них могут быть хеши. Хешируют то, что вы прислали и сравнивают с тем, что у них есть.
                          Просили не в точности старый пароль прислать, а «примерно старый пароль, часть его или типа того»© Звучало примерно как «part of your old password or something similar to it».
                            0
                            у них есть хэш пароля. Они могут построить по вашему похожему паролю 1М (или миллиард, если хэш функция быстрая) похожих паролей — созвучных, с изменённым символом-двумя и очень быстро сравнить хэши.
                            И если окажется, что вы почти угадали свой старый пароль — значит это сильный признак того, что страницу пытается восстановить настоящий владелец.
                              –2
                              Если у них похожие пароли генерируют похожие хэши, то у них не хэш-функция, а позорище :)

                              Даже в уже древнем md5 изменение одного бита в исходных данных вело к полному несовпадению хеша.
                                0
                                Ну может они хешируют сразу 2 или более хеша — один для проверки доступа, другой хранится для сравнивания «похожести»?
                                  0
                                  Второй хэш, который для сравнения «похожести» разрушит всю безопасность системы, потому что предоставит МНОГО информации злоумышленнику. Так делать нельзя, всё равно что хранить в открытом виде
                                    0
                                    Так делать нельзя

                                    Между "нельзя" и "могут делать" — огромная пропасть ))
                                    "Если нельзя, но очень хочется, то можно" © кто-то там...

                                  +2
                                  прочитайте, пожалуйста моё сообщение более внимательно.

                                  Более подробное объяснение:
                                  ваш пароль Pupkin999, но вы забыли его
                                  вводите pupkin999 как похожий. Сервис перебирает миллиард похожих паролей, в том числе:
                                  pukin, pupkin, 999, pukin999, pupkin9999, pupkinkin999, 999pupkin, < — миллионы их и один из них будет Pupkin999.
                                  В итоге, хэш Pupkin999 найдётся, а pupkin999 и 999pupkin — нет. И пофигу какая функция. Разумеется, хэш должен быть криптостоким, хотя бы как древний md5 и изменение одного бита должно менять (в среднем) половину битов.
                                    +1
                                    Нам представляется более вероятным что пароли хранятся в открытом виде, чем то что гугл будет проверять похож ли пароль брутфорсом.

                                    AgentSIB
                                    Бред. Данное утверждение актуально для http сайтов, но в случае https пароль от клиента на сервер всегда по безопасному каналу и извращаться с хешем на фронте просто не имеет смысла.
                                    Это если https так или иначе не скомпромитирован. Корпоративные сети, вирусы на компе у юзера. В целом лишняя безопасность лишней не бывает.

                                    А солить пароль надо, чтобы в случае получения базы его нельзя было восстановить по радужным таблицам. И алгоритм хеширования нужно вменяемый выбирать, так как md5 и sha1 уже давно считаются не безопасными.
                                    Есть еще одна причина для соли, даже более серьезная. Форму логина от брутфорса обычно защищают, но вот авторизацию уже нет. В результате подобрать пароль через форму логина — оппа и блок, не получается. А если просто долбить запросами с куками в виде хэшей этого пароля (в случае не солености), то блока за брут как правило не будет.
                                      0
                                      Это если https так или иначе не скомпромитирован. Корпоративные сети, вирусы на компе у юзера. В целом лишняя безопасность лишней не бывает.

                                      Именно для этого и придумали многофакторную авторизацию

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

                                      Тут уже квалификация кодера. А вообще какая разница чем долбить? Кукисами, пост запросами с паролями, пост запросами с хешеми паролей и тп? Если на форме авторизации нет защиты от перебора — это проблема реализации формы авторизации. Тоже самое касается авторизации по кукиса.
                                        0
                                        Поправлюсь. Многофакторную авторизацию придумали для другого. Если канал скомпроментирован, то тут нужен просто другой канал, как я писал выше (proxy/vpn etc). Формой авторизации тут проблему не решить.

                                        Можно сделать свой костыль: Деффи Хеллман и общение с фронтом уже зашифрованными сообщениями :))

                                        Можно разрабатывать систему, навешивая условия из разряда: https скомпроментирован, сертификат подменен, злоумышленник в бинокль видит монитор, на клавиатуре контроллер логирования нажатий, а АНБ улавливаем мозговые волны. Но давайте все же в качестве первоначальных условий брать стандартную ситуацию.
                                          0
                                          Именно для этого и придумали многофакторную авторизацию
                                          Наличие многофакторной авторизации не отменяет необходимости охранять один из ее факторов — пароль.

                                          Тут уже квалификация кодера. А вообще какая разница чем долбить? Кукисами, пост запросами с паролями, пост запросами с хешеми паролей и тп? Если на форме авторизации нет защиты от перебора — это проблема реализации формы авторизации. Тоже самое касается авторизации по кукиса..
                                          Тут речь о common practice, то что каждый второй делает защиту формы логина от брута, но почти никто не делает защиту авторизации по кукам от брута. Почти у всех популярных цмс/форумов так, да и хабр туда же.
                                            0
                                            Тут речь о common practice, то что каждый второй делает защиту формы логина от брута, но почти никто не делает защиту авторизации по кукам от брута. Почти у всех популярных цмс/форумов так, да и хабр туда же.

                                            Тут соглашусь.

                              +2
                              пароли в текстовом виде не должны даже покидать браузер пользователя

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

                              А солить пароль надо, чтобы в случае получения базы его нельзя было восстановить по радужным таблицам. И алгоритм хеширования нужно вменяемый выбирать, так как md5 и sha1 уже давно считаются не безопасными.
                              0
                              Например, чтобы посчитать статистику наиболее популярных паролей.
                              +1
                              Вы так говорите, будто из-за репутационных рисков, которые стали репутационными инцидентами, курсы акций не рушатся и не летят со своих теплых высокооплачиваемых мест менеджеры, которые не удовлетворяют советы директоров.
                                0
                                Ну, у риска есть оценка (упрощённо — вероятность его наступления, помноженная на вред от него). Сравнение её с оценкой пользы от него же — вопрос обсуждаемый (не тут, а среди менеджеров организации).

                                Ну и с другой стороны — мне вот кажется что у фейсбука ничего такого (вами описанного) не случится вследствие этой новости. Ну пошумят полтора ит-задрота и успокоятся, а 99% их аудитории даже не поймут о чём речь.
                                Даже на массовые сливы баз паролей уже давно большинству пофиг.

                                Ну и очень наивными выглядят заявления внизу вида «какое легаси», «да они безграмотные, не знают что надо шифровать» и т.д. BalinTomsk
                                sergyx Eldhenn Да знают они, знают, не дураки, но безопасность ваших учёток на других сайтах (где вы тот же пароль использовали) им даром не сдалась, у них другие интересы.
                              +8
                              При таком возмутительном высоком цензе в приеме на работу — такие убогие архитектурные решения уровня 80-х.

                              Неужели они до сих пор не знают что пароли в текстовом виде не должны даже покидать браузер пользователя. А в базе пере-закриптованно-пасоленые хэши?

                                +5
                                Везде есть легаси разного уровня маразма. И часто, когда продукт «выстреливает» времени там что-то менять уже попросту нет, да и опасно. Все по принципу: работает — не трожь. Бизнесу и инвесторам фактически не интересны технические долги, им нужны новые фичи, приносящие реальные деньги. Наивно полагать, что если проект большой или им занимается крупная корпорация, то значит там все хорошо, скорее даже наоборот.
                                Что до открытых паролей, то этим грешит не только фейсбук. Я не знаю, с чем конкретно это связано, потому что хеш-функции с солями и без известны и используются действительно уже очень давно, но факт: еще недавно и вконтакте мог вполне себе прислать «забытый» пароль на почту.
                                  0
                                  так как их пароли хранились в открытом виде и доступ к ним имели более чем 20000 сотрудников Facebook».


                                  А я как-то не верю, что столько лет 20.000 сотрудников не попытались хотя бы сообщить об этом.
                                  Можно было даже анонимно оставить где-нибудь сообщение, что пароли в ФБ хранятся открыто, поднялась бы шумиха, подняли бы приоритет чтобы это пофиксить.
                                  Или все 20.000 человек совершенно без совести и морали? Тогда жуть.
                                    0
                                    > Или все 20.000 человек совершенно без совести и морали?

                                    Вы так говорите, будто эти «все» имеют одинаковый уровень полномочия.

                                    99,9% из них это наёмные работники, что им скажут — то и будут выполнять, а если не будут, то пойдут гулять на улицу. Мораль, совесть — у каждого своя, и в корпорации её устанавливает только один — владелец (совет директоров, лицо какое-то, совершенно не важно в данном случае кто именно), остальные подчиняются.

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

                                    «Это бизнес, детка, ничего личного» )))
                                      0
                                      «Имели доступ» и «знали что у них есть доступ» это разные вещи.
                                      +5

                                      FB не проект из 80-х. Уже во время рождения FB хранить пароли в открытом виде было плохо. Так что тут на лицо грубейший архитектурный просчёт.

                                        +1
                                        Хех уровень маразма. Вин10 и андроид по телеметрии вас не смущает? Запустите варшарк увидите много интересного.
                                          0
                                          Легаси легасями, но и то, и то всё-равно строка. Им только преобразователь на входе поставить. Какое-то феноменальное рукожопство
                                          0
                                          Неужели они до сих пор не знают что пароли в текстовом виде не должны даже покидать браузер пользователя.


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

                                          Соответственно, в базе нужно будет хранить хеш от хеша полученного от клиента. Единственное от чего защищает передача хеша вместо пароля из браузера — это невозможность использования перехваченного хеша на других сайтах (в случае если пользователь использует один пароль на нескольких сайтах).
                                            0
                                            ---Если браузер отправляет хеш вместо пароля, это равносильно тому, что хеш является паролем.

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

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

                                            Это решение делатся за считанные часы.
                                              0
                                              Подождите, ведь что браузер отправляет серверу — то с точки зрения сервера и есть пароль.
                                              Если дополнительно сверху наложено шифрование сессионным ключом, то чем это отличается от HTTPS? Почему сразу не использовать HTTPS + внутри него пароль в открытом виде, а в базе хранить его хеш?
                                            +1
                                            Неужели они до сих пор не знают что пароли в текстовом виде не должны даже покидать браузер

                                            Это вы знаете как пользователь насмотревшийся "рекламы", лозунгов и т.д., а внутри компании существует коммерческая тайна, ошибки могут быть, где вполне заявления в "рекламе" и конечного продукта "на выходе" будут значительно различаться ИЗНАЧАЛЬНО и вы не узнаете об этом, пока тайна не покинет границы организации.


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

                                              0
                                              При таком возмутительном высоком цензе в приеме на работу — такие убогие архитектурные решения уровня 80-х.
                                              ну не могут же они в самом деле писать на пхп
                                              –4
                                              Ну а что такого уж плохого в том, что какой-то сотрудник FB имеет возможность посмотреть пароль пользователя (я не думаю, что речь идет о всех 20000 сотрудников, иначе это бы стало известно намного раньше)? Это в свете того, что сотрудник FB и так имеет доступ ко всем приватным данным, которые пользователь сохранил, плюс может их редактировать, причем от имени пользователя. Ну, кроме факта, что хранение паролей в натуральном виде — признак дикого легаси в системе безопасности.
                                                +2
                                                Эти пароли могут использоваться (и используются!) пользователями на других сервисах, отличных от Фейсбука.
                                                  –4
                                                  А это уже тупизм пользователей, а не FB. Уже сто раз было сказано не использовать одинаковые пароли для разных сервисов.
                                                    0
                                                    Объясните пожалуйста, за что минусы? На многих сайтах с регистрацией висят напоминания, чтобы пользователи не использовали одинаковые пароли. На самом хабре это уже тысячи раз упоминалось.
                                                    Т.е., обвинять FB в том что пользователя взломали на другой полощадке когда тот использовал одинаковые пароли — это как сказать, что в FB виноваты во взломе аккаунта на FB из-за того что пользователь записал свой пароль на листочке а кто-то его украл. Ну а что, эти программисты должны были предугадать такое и включить двухфакторную аутентификацию по дефолту!
                                                      +1

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

                                                0

                                                Все таки корпоративная дисциплина поражает. Столько лет никто ни гу-гу. Вот как надо воспитывать сотрудников.

                                                  0

                                                  Я 20 лет занимаюсь разработкой веб-приложений. И я никогда, вот никогда вообще, ни разу в жизни не хранил пароли в открытом виде. Чуть ли не первое, чему меня научили — это crypt(3).


                                                  Как? Как это вообще возможно?

                                                    0
                                                    Фейсбук же начинался как поделка на коленках, с тех пор наверное и осталось все это. То что делается временно, обычно остается навсегда :)
                                                      0
                                                      Как? Как это вообще возможно?

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

                                                      –1

                                                      из всех паролей совпадали 2, фейсбук и убер
                                                      так вот заходили из какого-то Тайваня в аккаунт убера, причём почему-то без двухфакторной аутентификации, я сам не с первого раза захожу)


                                                      Пароль сложный, перебором не подобрать

                                                        +4

                                                        Если я не ошибаюсь, Facebook не хранит есессно пароли в базе в открытом виде. Это какая-то система отладки и логгирования складывала логи, включая пароли, в открытом виде.

                                                          0
                                                          Что-то похожее не так давно было в Twitter'е, там пароли в открытом виде в систему логирования отправлялись.
                                                          0
                                                          Они просто прочитали на Хабре статью о том, что md5 может быть небезопасен, и решили его не использовать

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

                                                          Самое читаемое