Вчера в официальном блоге 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.
Из всей этой истории назревает несколько вопросов:
- Действительно ли в Facebook приняли меры по исправлению уязвимости?
- Действительно ли к паролям не имел доступ никто, кроме сотрудников социальной сети?
- Действительно ли получат оповещения все пользователи, чьи пароли были скомпрометированы?
- Стоит ли вновь ждать подобных новостей о корпорации, не раз пренебрегавшей приватностью пользователей?
- Будут ли в Facebook искать сотрудника-инсайдера, причинившего значительный ущерб деловой репутации компании и раскрывшего информацию о существовании уязвимости?
- Имеют ли сотрудники российских социальных сетей неофициальный (не баг, а фича) доступ к паролям пользователей?
Комментарии (62)
BalinTomsk
21.03.2019 23:51+4При таком возмутительном высоком цензе в приеме на работу — такие убогие архитектурные решения уровня 80-х.
Неужели они до сих пор не знают что пароли в текстовом виде не должны даже покидать браузер пользователя. А в базе пере-закриптованно-пасоленые хэши?
koldoon
22.03.2019 00:29+4Везде есть легаси разного уровня маразма. И часто, когда продукт «выстреливает» времени там что-то менять уже попросту нет, да и опасно. Все по принципу: работает — не трожь. Бизнесу и инвесторам фактически не интересны технические долги, им нужны новые фичи, приносящие реальные деньги. Наивно полагать, что если проект большой или им занимается крупная корпорация, то значит там все хорошо, скорее даже наоборот.
Что до открытых паролей, то этим грешит не только фейсбук. Я не знаю, с чем конкретно это связано, потому что хеш-функции с солями и без известны и используются действительно уже очень давно, но факт: еще недавно и вконтакте мог вполне себе прислать «забытый» пароль на почту.
saboteur_kiev
22.03.2019 03:28так как их пароли хранились в открытом виде и доступ к ним имели более чем 20000 сотрудников Facebook».
А я как-то не верю, что столько лет 20.000 сотрудников не попытались хотя бы сообщить об этом.
Можно было даже анонимно оставить где-нибудь сообщение, что пароли в ФБ хранятся открыто, поднялась бы шумиха, подняли бы приоритет чтобы это пофиксить.
Или все 20.000 человек совершенно без совести и морали? Тогда жуть.
microcoder
22.03.2019 13:22> Или все 20.000 человек совершенно без совести и морали?
Вы так говорите, будто эти «все» имеют одинаковый уровень полномочия.
99,9% из них это наёмные работники, что им скажут — то и будут выполнять, а если не будут, то пойдут гулять на улицу. Мораль, совесть — у каждого своя, и в корпорации её устанавливает только один — владелец (совет директоров, лицо какое-то, совершенно не важно в данном случае кто именно), остальные подчиняются.
Каждый «наёмник» при устройстве, может подписывать юридический документ о неразглашении ком. тайны либо иной тайны которая может как раз таки содержать подобные случаи. Тайна, может быть закреплена в законодательстве страны и нарушитель может быть преследован по закону и осужден.
«Это бизнес, детка, ничего личного» )))
Sheti
22.03.2019 04:48FB не проект из 80-х. Уже во время рождения FB хранить пароли в открытом виде было плохо. Так что тут на лицо грубейший архитектурный просчёт.
arthi7471
22.03.2019 11:24Хех уровень маразма. Вин10 и андроид по телеметрии вас не смущает? Запустите варшарк увидите много интересного.
botyaslonim
22.03.2019 14:53Легаси легасями, но и то, и то всё-равно строка. Им только преобразователь на входе поставить. Какое-то феноменальное рукожопство
nile1
22.03.2019 08:50Неужели они до сих пор не знают что пароли в текстовом виде не должны даже покидать браузер пользователя.
Если браузер отправляет хеш вместо пароля, это равносильно тому, что хеш является паролем. И если в базе хранить этот хеш, то результат с точки зрения безопасности ничем не отличается от хранения пароля в открытом виде.
Соответственно, в базе нужно будет хранить хеш от хеша полученного от клиента. Единственное от чего защищает передача хеша вместо пароля из браузера — это невозможность использования перехваченного хеша на других сайтах (в случае если пользователь использует один пароль на нескольких сайтах).BalinTomsk
22.03.2019 15:52---Если браузер отправляет хеш вместо пароля, это равносильно тому, что хеш является паролем.
Я и не писал что хэш в чистом виде уходит из браусзра — эго вполне можно криптовать сеессионым ключом при отправке, и это не считая SSL сверху.
Чистый хеш тоже можно не хранить — а хеш на хеш, закриптованный в базе, колонка которой криптуется базой.
Это решение делатся за считанные часы.me21
22.03.2019 17:41Подождите, ведь что браузер отправляет серверу — то с точки зрения сервера и есть пароль.
Если дополнительно сверху наложено шифрование сессионным ключом, то чем это отличается от HTTPS? Почему сразу не использовать HTTPS + внутри него пароль в открытом виде, а в базе хранить его хеш?
microcoder
22.03.2019 10:04Неужели они до сих пор не знают что пароли в текстовом виде не должны даже покидать браузер
Это вы знаете как пользователь насмотревшийся "рекламы", лозунгов и т.д., а внутри компании существует коммерческая тайна, ошибки могут быть, где вполне заявления в "рекламе" и конечного продукта "на выходе" будут значительно различаться ИЗНАЧАЛЬНО и вы не узнаете об этом, пока тайна не покинет границы организации.
Не знать они не могут, это невозможно в принципе. Попробуйте создать систему аутнтификации и не знать как она работает. Получится? А если вы не один разрабатываете, получится у вас не знать как вы её разработали?
pal666
23.03.2019 02:01При таком возмутительном высоком цензе в приеме на работу — такие убогие архитектурные решения уровня 80-х.
ну не могут же они в самом деле писать на пхп
DrPass
22.03.2019 03:35-1Ну а что такого уж плохого в том, что какой-то сотрудник FB имеет возможность посмотреть пароль пользователя (я не думаю, что речь идет о всех 20000 сотрудников, иначе это бы стало известно намного раньше)? Это в свете того, что сотрудник FB и так имеет доступ ко всем приватным данным, которые пользователь сохранил, плюс может их редактировать, причем от имени пользователя. Ну, кроме факта, что хранение паролей в натуральном виде — признак дикого легаси в системе безопасности.
agat000
22.03.2019 05:39Все таки корпоративная дисциплина поражает. Столько лет никто ни гу-гу. Вот как надо воспитывать сотрудников.
Eldhenn
22.03.2019 06:22Я 20 лет занимаюсь разработкой веб-приложений. И я никогда, вот никогда вообще, ни разу в жизни не хранил пароли в открытом виде. Чуть ли не первое, чему меня научили — это crypt(3).
Как? Как это вообще возможно?
Komol
22.03.2019 08:27Фейсбук же начинался как поделка на коленках, с тех пор наверное и осталось все это. То что делается временно, обычно остается навсегда :)
microcoder
22.03.2019 10:09Как? Как это вообще возможно?
А почему бы нет, если есть планы что либо поделать с этими паролями? Дураков в компаниях не встречал.
Spectre
22.03.2019 08:04из всех паролей совпадали 2, фейсбук и убер
так вот заходили из какого-то Тайваня в аккаунт убера, причём почему-то без двухфакторной аутентификации, я сам не с первого раза захожу)
Пароль сложный, перебором не подобрать
savostin
22.03.2019 09:43+1Если я не ошибаюсь, Facebook не хранит есессно пароли в базе в открытом виде. Это какая-то система отладки и логгирования складывала логи, включая пароли, в открытом виде.
Suvitruf
22.03.2019 11:22Что-то похожее не так давно было в Twitter'е, там пароли в открытом виде в систему логирования отправлялись.
botyaslonim
22.03.2019 14:51Они просто прочитали на Хабре статью о том, что md5 может быть небезопасен, и решили его не использовать
firk
Это не уязвимость, а запланированное поведение.
Ну, возможно круг имеющих доступ только оказался чуть шире запланированного. С чего вы решили что фейсбук будет сам от себя охранять ваш пароль, который (вместе со всеми остальными «вашими» данными) они давно присвоили себе? Они не благотворительная организация.
Тут так: совсем мелкие организации не шифруют пароли по нубству (хотя последнее время всё больше начинают использовать скаченные с инета готовые движки где шифрование есть), те что по-больше начинают шифровать потому что это модно, либо из каких-то мутных крипто-утопических соображений, а самые крупные подходят к этому делу рационально и взвешивают все плюсы и минусы данного занятия. Плюс только один — избежать потенциальных потерь репутации когда кто-то это спалит, всё остальное — минусы и они обычно перевешивают.
Perlovich
А какие вообще могут быть плюсы от хранения пароля в открытом виде?
edogs
Так-то плюсы есть, но Ваш вопрос видимо подразумевал «какие плюсы могут быть от храненя пароля в открытом виде стоящие того что бы их так хранить»? Тогда вопрос более сложный, но опять же, в некоторых несколько искусственных ситуациях плюсы возможны.
BalinTomsk это вообще мало кто знает. Даже на хабре (дада, прям тут, на ресурсе для крутых технарей который типа сделан крутыми технарями) уходят в открытом виде, но Вас это от общения тут не останавливает:) Так что — всем по фиг, даже тем кто знает как надо.
На руборде хз как именно они хранятся, но при напоминании приходят в открытом виде на почту, а форум весьма старый, хороший и популярный до сих пор.
Единственное где мы помним пароли в открытом виде штатно имели возможность не уходить — это vbulletin, там делался md5 на пароль (на яваскрипте) перед отправкой его на сервак.
koldoon мы еще страннее вещь скажем. Какое-то время назад гугл при восстановлении пароля просил вспомнить хотя бы примерно старый пароль, часть его или типа того. И запрос о восстановлении тогда уходил на ручное рассмотрение. Вопрос — а на фига если у них нет паролей в открытом виде?
staticlab
С точки зрения взаимодействия клиента и сервера по сути паролем был этот хэш.
freeExec
Да, но ввести его с клавиатуры на другом сайте не выйдет, а если там при отправке используется уже другая хешфункция, то вообще облом.
mishutka90
Хэш можно «посолить» чем-нибудь, отправленным с сервера. И тогда хэш каждый раз будет разным. Пример реализации: mito-team.com/ru/article/2008/secure-http-authentification
nile1
Если клиент будет солить хэш каждый раз перед передачей на сервер, он не совпадет с соленым хэшем, который хранится в базе данных на сервере, разве нет?
UPD.
Перечитал внимательнее: ок, если сервер передает соль, это будет работать. Пароль в таком случае можно превратить в сессионный токен (соль должна «протухнуть» со временем и замениться новой, иначе эта процедура бессмысленна).
mishutka90
Поглядите реализацию по ссылке. Соль генерится каждый раз заново при отображении формы, и протухает или при отправке формы, или по таймауту. В любом случае, соль — одноразовая.
staticlab
Эта схема реализует проверку
sha1(sha1(passwordFromUser) + salt) == sha1(sha1(password) + salt)При этом в базе хранится
sha1(password).Если хакер сможет прочитать таблицу users, то получит доступ к сайту, поскольку всегда сможет вычислить
sha1(sha1(password) + salt). С этой точки зрения данная схема эквивалентна хранению нехешированного пароля, а потому небезопасна. Да, в общем случае хакер не будет знать реальный пароль, но доступ к уязвимому сайту всё равно получит.mishutka90
А если делить пароль пополам?
Первую половину передавать в открытом виде, а на сервере хранить только её хэш. Тогда получив доступ к таблице, хакер не будет знать первую половину пароля.
Вторую половину передавать описанным способом, для исключения перехвата.
Тогда для взлома потребуется и доступ к таблице users, и перехват первой половины пароля.
staticlab
Никогда не пытайтесь придумать свою криптографическую схему!
Для исключения перехвата пароля лучше всего использовать HTTPS. А ваша схема точно так же эквивалентна хранению в БД нехешированного пароля.
mishutka90
HTTPS в общем случае не исключает man-in-the-middle. В корпоративных сетях, к примеру. Или при принудительной установке в систему доверенных корневых сертификатов.
staticlab
А от чего защитит ваша схема? Вы разделяете, например, 10-символьный пароль на два 5-символьных. Одну часть пересылаете как есть, и хакер её перехватывает, а вторую хешируете, но 5-символьный пароль легко подбирается брутфорсом.
UPD: А с точки зрения получения доступа к сайту, хакеру точно так же достаточно перехватить нехешированную часть и хешированную и использовать их как есть.
mishutka90
> 5-символьный пароль легко подбирается брутфорсом
При размере соли, прилетающей с сервера, символов в 20, пятисимвольный пароль превращается в 25. И соль на каждую попытку разная. Брутфорс уже не прокатит.
staticlab
Хакер, перхватывая трафик, получает текущую соль, а затем получает соответствующий ей хэш. Далее он сможет забрутфорсить несколько символов пароля, соответствующих этому хэшу. 20 символов соли роли не играют, потому что в этом процессе будут константны. Соль нужна исключительно, чтобы предотвратить использование радужных таблиц.
pal666
мне кажется, вы путаете соль с nonce. соль это защита от радужных таблиц
mishutka90
> достаточно перехватить нехешированную часть и хешированную и использовать их как есть
Не совсем корректно. Если хешированная часть долетела до сервера, то соль устараеет, и перехваченные данные становятся бесполезными.
staticlab
Так, мы ещё не забыли, что у нас хранится в базе?
AgentSIB
Тут описано как этого избежать
habr.com/ru/post/336738
В конце концов есть EV.
mishutka90
В корпоративной среде у вас может принудительно лежать в системе доверенный корневой сертификат и отдаваться необходимая CAA запись DNS-сервером.
И тогда https-трафик будет читаться не намного сложнее http.
AgentSIB
А какова вероятность, что в корпоративной среде будет сделано все это для намеренного хищения пользовательских данных?))) Провернуть такую штуку для фишинга — крайне сложно, поэтому https — это выход из ситуации.
Но если вы не доверяете каналу, вы всегда можете работать через proxy/vpn.
К тому же никто не мешает добавить факторов авторизации помимо логина и пароля, что сделает вход в систему более защищенным, раз уж на то пошло.
Oz_Alex
edogs
knstqq
у них есть хэш пароля. Они могут построить по вашему похожему паролю 1М (или миллиард, если хэш функция быстрая) похожих паролей — созвучных, с изменённым символом-двумя и очень быстро сравнить хэши.
И если окажется, что вы почти угадали свой старый пароль — значит это сильный признак того, что страницу пытается восстановить настоящий владелец.
mishutka90
Если у них похожие пароли генерируют похожие хэши, то у них не хэш-функция, а позорище :)
Даже в уже древнем md5 изменение одного бита в исходных данных вело к полному несовпадению хеша.
microcoder
Ну может они хешируют сразу 2 или более хеша — один для проверки доступа, другой хранится для сравнивания «похожести»?
knstqq
Второй хэш, который для сравнения «похожести» разрушит всю безопасность системы, потому что предоставит МНОГО информации злоумышленнику. Так делать нельзя, всё равно что хранить в открытом виде
microcoder
Между "нельзя" и "могут делать" — огромная пропасть ))
"Если нельзя, но очень хочется, то можно" © кто-то там...
knstqq
прочитайте, пожалуйста моё сообщение более внимательно.
Более подробное объяснение:
ваш пароль Pupkin999, но вы забыли его
вводите pupkin999 как похожий. Сервис перебирает миллиард похожих паролей, в том числе:
pukin, pupkin, 999, pukin999, pupkin9999, pupkinkin999, 999pupkin, < — миллионы их и один из них будет Pupkin999.
В итоге, хэш Pupkin999 найдётся, а pupkin999 и 999pupkin — нет. И пофигу какая функция. Разумеется, хэш должен быть криптостоким, хотя бы как древний md5 и изменение одного бита должно менять (в среднем) половину битов.
edogs
Нам представляется более вероятным что пароли хранятся в открытом виде, чем то что гугл будет проверять похож ли пароль брутфорсом.
Это если https так или иначе не скомпромитирован. Корпоративные сети, вирусы на компе у юзера. В целом лишняя безопасность лишней не бывает.AgentSIB
Есть еще одна причина для соли, даже более серьезная. Форму логина от брутфорса обычно защищают, но вот авторизацию уже нет. В результате подобрать пароль через форму логина — оппа и блок, не получается. А если просто долбить запросами с куками в виде хэшей этого пароля (в случае не солености), то блока за брут как правило не будет.
AgentSIB
Именно для этого и придумали многофакторную авторизацию
Тут уже квалификация кодера. А вообще какая разница чем долбить? Кукисами, пост запросами с паролями, пост запросами с хешеми паролей и тп? Если на форме авторизации нет защиты от перебора — это проблема реализации формы авторизации. Тоже самое касается авторизации по кукиса.
AgentSIB
Поправлюсь. Многофакторную авторизацию придумали для другого. Если канал скомпроментирован, то тут нужен просто другой канал, как я писал выше (proxy/vpn etc). Формой авторизации тут проблему не решить.
Можно сделать свой костыль: Деффи Хеллман и общение с фронтом уже зашифрованными сообщениями :))
Можно разрабатывать систему, навешивая условия из разряда: https скомпроментирован, сертификат подменен, злоумышленник в бинокль видит монитор, на клавиатуре контроллер логирования нажатий, а АНБ улавливаем мозговые волны. Но давайте все же в качестве первоначальных условий брать стандартную ситуацию.
edogs
Тут речь о common practice, то что каждый второй делает защиту формы логина от брута, но почти никто не делает защиту авторизации по кукам от брута. Почти у всех популярных цмс/форумов так, да и хабр туда же.
AgentSIB
Тут соглашусь.
AgentSIB
Бред. Данное утверждение актуально для http сайтов, но в случае https пароль от клиента на сервер всегда по безопасному каналу и извращаться с хешем на фронте просто не имеет смысла.
А солить пароль надо, чтобы в случае получения базы его нельзя было восстановить по радужным таблицам. И алгоритм хеширования нужно вменяемый выбирать, так как md5 и sha1 уже давно считаются не безопасными.
sergey-b
Например, чтобы посчитать статистику наиболее популярных паролей.
Moskus
Вы так говорите, будто из-за репутационных рисков, которые стали репутационными инцидентами, курсы акций не рушатся и не летят со своих теплых высокооплачиваемых мест менеджеры, которые не удовлетворяют советы директоров.
firk
Ну, у риска есть оценка (упрощённо — вероятность его наступления, помноженная на вред от него). Сравнение её с оценкой пользы от него же — вопрос обсуждаемый (не тут, а среди менеджеров организации).
Ну и с другой стороны — мне вот кажется что у фейсбука ничего такого (вами описанного) не случится вследствие этой новости. Ну пошумят полтора ит-задрота и успокоятся, а 99% их аудитории даже не поймут о чём речь.
Даже на массовые сливы баз паролей уже давно большинству пофиг.
Ну и очень наивными выглядят заявления внизу вида «какое легаси», «да они безграмотные, не знают что надо шифровать» и т.д. BalinTomsk
sergyx Eldhenn Да знают они, знают, не дураки, но безопасность ваших учёток на других сайтах (где вы тот же пароль использовали) им даром не сдалась, у них другие интересы.