Comments 74
UFO just landed and posted this here
Почта критично — на нее приходят подтверждение о смене паролей на многих сервисах. Завладеть основной почтой человека — все равно что получить доступ ко всем сервисам, привязанным к этой почте.
Не понимаю, при чем здесь РайффайзенБанк. У них сейчас SMS либо ридер, генерирующий одноразовые пароли, без которых ничего перевести невозможно. А по ссылке выше последнее сообщение от 02.12.2013.
P.S. мне от них пока ничего связанного с внеочередной сменой пароля не приходило.
P.S. мне от них пока ничего связанного с внеочередной сменой пароля не приходило.
Интересно было бы посмотреть примерный список тех, кого удалось слить с использованием данной уязвимости. Судя по слухам — всё очень печально.
Мне кажется, что из известных сервисов больше всех пострадал Yahoo. Их медлительность при патчинге стали активно ретвитить, провоцируя людей заряжать скрипты на login.yahoo.com
Про остальных — не знаю. Но даже на текущий момент, люди не особо задумываются о том что уязвимость не в HTTPS, а в OpenSSL. А значит все Jabber порты, SMTPS, SMTP/TLS и т.п. уязвимы наравне с вебом.
Про остальных — не знаю. Но даже на текущий момент, люди не особо задумываются о том что уязвимость не в HTTPS, а в OpenSSL. А значит все Jabber порты, SMTPS, SMTP/TLS и т.п. уязвимы наравне с вебом.
Хах! Еще даже не все российские банки залатали дыру, о чем тут дальше говорить.
UFO just landed and posted this here
Насколько мне известно, это были неблагонадёжные партнёры и от них уже давно избавились.
И я склонен верить тому, что впредь такого не повторится :)
И я склонен верить тому, что впредь такого не повторится :)
Суть понятия «сертификат» как раз в том, чтобы знать, кто отвечает за подписанный бинарник, чтобы «неблагонадёжный партнёр» не мог выдать своё ПО за чужое. Подписано сертификатом Mail.ru? Отвечает Mail.ru.
Сертификатиом подписывается только наш бинарник, который занимается загрузкой и установкой. Устанавливаемый бинарник нашим сертификатом не подписывался. Примерно то же самое, что Install Shield или Akamai'евский загрузчик обвинять в том, что он устанавливает вредоносное ПО.
Ну дурачка-то не включайте. Сколько раз примерно вы видели подписанный инсталлшилд, устанавливающий вредоносное ПО? Для чего в винде есть галка «всегда доверять полученному от %companyname%»?
Зачем на чужой смотреть, давайте прямо сейчас свой сделаем.
Идем в папку c:\program files\InstallShield Installation Information / c:\program files (x86)\InstallShield Installation Information (она скрытая)
Cмотрим по папочкам.
Ищем setup.exe с электронными подписями. У меня есть на выбор с подписями от:
InstallShield Software Corporation
Macrovision Corporation
Realtek Semiconductor Corp
CyberLink
Могу подарить любой.
Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.
P.S. Я не спорю хорошо это или плохо, более того, негативно отношусь к дистрибуции посредством партнерских программ. И еще более того, 20 лет участвую в опенсорсных проектах. Но это же технический чятег, да, я могу указать кому-то на техническую неточность?
Идем в папку c:\program files\InstallShield Installation Information / c:\program files (x86)\InstallShield Installation Information (она скрытая)
Cмотрим по папочкам.
Ищем setup.exe с электронными подписями. У меня есть на выбор с подписями от:
InstallShield Software Corporation
Macrovision Corporation
Realtek Semiconductor Corp
CyberLink
Могу подарить любой.
Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.
P.S. Я не спорю хорошо это или плохо, более того, негативно отношусь к дистрибуции посредством партнерских программ. И еще более того, 20 лет участвую в опенсорсных проектах. Но это же технический чятег, да, я могу указать кому-то на техническую неточность?
Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.
Что вы имеете в виду под проверкой целостности? Проверку именно виндой в момент запуска установщика или проверку самим установщиком этой библиотеки?
Ни там ни там.
Вот PoC с тремя разными setup.exe с разными подписями:
cloud.mail.ru/public/8b9e46cd16ff/virus.zip
запускает безопасный «вирус» переименованный в data1.cab.
Сорсы приложены.
Т.е. воспроизведите действие обычного пользователя — загрузите, откройте в проводнике. Он предложит извлечь, после чего запускайте любой из сетапов.
Похожий фокус можно провернуть практически с любым подписаным файлом и это будет до тех пор, пока система не начнет проверять все исполняемые файлы на наличие подписи.
Вот PoC с тремя разными setup.exe с разными подписями:
cloud.mail.ru/public/8b9e46cd16ff/virus.zip
запускает безопасный «вирус» переименованный в data1.cab.
Сорсы приложены.
Т.е. воспроизведите действие обычного пользователя — загрузите, откройте в проводнике. Он предложит извлечь, после чего запускайте любой из сетапов.
Похожий фокус можно провернуть практически с любым подписаным файлом и это будет до тех пор, пока система не начнет проверять все исполняемые файлы на наличие подписи.
Похожий фокус можно провернуть практически с любым подписаным файлом и это будет до тех пор, пока система не начнет проверять все исполняемые файлы на наличие подписи.
Вам не кажется, что это сродни перекладыванию с больной головы на здоровую? Система проверяет подпись того файла, который запускается пользователем. Потому что именно это действие пользователь санкционировал лично. Все прочие исполняемые файлы, в том числе подсасываемые установщиком библиотеки, должны проверяться на целостность самим установщиком, ибо только он знает, какие библиотеки ему нужны.
Почему именно так? Да потому что библиотеки в проекте могут идти из разных ресурсов, и условиями лицензий на их использование может быть запрещена любая их модификация, а цифровая подпись требует модификации бинарника. Как следствие, если ОС обяжет подписанный ехе-шник использовать только подписанные dll-ки, у части разработчиков возникнут проблемы.
Поэтому идеологически верно контролировать целостность используемых тобой библиотек самостоятельно. По крайней мере если ты действительно хочешь обеспечить безопасность пользователю своего продукта.
Я не знаю, какое решение теоретически правильное, я показываю что тот механизм проверки целостности, который есть, сейчас на практике не работает и тривиально обходится, PoC выше.
То, что Вы предлагаете при текущей организации загрузки приложения в Windows не сработает. Производитель EXE файла не знает какие именно библиотеки будут подгружены итоге в адресное пространства процесса. Системные библитеки могут подгружать другие библиотеки. Для того, чтобы все это контролировать надо писать свой динамический линковщик взамен системного и перехватывать системные вызовы на загрузку библиотек. Т.е. подменять функционал системы. При этом вирмейкеру достаточно для маскировки любого одного приложения, которое так делать не будет. Вот это как раз перекладывание с больной головы на здоровую — реализовывать системный функционал в каждом исполняемом файле.
То, что Вы предлагаете при текущей организации загрузки приложения в Windows не сработает. Производитель EXE файла не знает какие именно библиотеки будут подгружены итоге в адресное пространства процесса. Системные библитеки могут подгружать другие библиотеки. Для того, чтобы все это контролировать надо писать свой динамический линковщик взамен системного и перехватывать системные вызовы на загрузку библиотек. Т.е. подменять функционал системы. При этом вирмейкеру достаточно для маскировки любого одного приложения, которое так делать не будет. Вот это как раз перекладывание с больной головы на здоровую — реализовывать системный функционал в каждом исполняемом файле.
О системных библиотеках никто и не говорит. Они не идут в комплекте поставки приложения, и их целостность — уже забота той стороны, которая эти библиотеки в систему запустила.
А вот проверять целостность тех библиотек, которыми ты самолично комплектуешь свой продукт — подход более чем уместный. Ваш PoC выше не прокатит, если использовать именно такой подход. Как не прокатит и установка говнософта с помощью подписанного Mail.ru инсталлятора, потому как инсталлятор должен будет сам знать, какой _setup.dll с ним используется.
А вот проверять целостность тех библиотек, которыми ты самолично комплектуешь свой продукт — подход более чем уместный. Ваш PoC выше не прокатит, если использовать именно такой подход. Как не прокатит и установка говнософта с помощью подписанного Mail.ru инсталлятора, потому как инсталлятор должен будет сам знать, какой _setup.dll с ним используется.
Нет, это прокатит только для библиотек, которые грузятся в процессе выполнения приложения через LoadLibrary. Но не прокатит для библиотек, которые подключаются через динамическую линковку при старте приложения (а их большинство), т.к. динамическую линковку в Windows выполняет не само приложение и библиотека будет загружена раньше, и DllMain выполнен раньше, чем начнет работу код приложения и будет возможность проверить целостность библиотеки. Скорее всего, есть какой-нибудь способ проверить уже загруженную библиотеку до того, как сработает DllMain, но все равно это пляски с бубном и наколенные решения. Гораздо проще и правильней подписать свои библиотеки и на уровне системы не разрешать загрузку неподписанных.
О чем вы там спорите? Очевидно же, что файлы, загружаемые системным загрузчиком (динамически прилинкованные), должны проверяться им же, а файлы, загружаемые самим приложением — должны проверяться приложением.
Как вариант, да.
А почему не очевиден вариант проверять все, что грузится через LoadLibrary?
А почему не очевиден вариант проверять все, что грузится через LoadLibrary?
Антивирусники так делают… и при этом система загибается. Слава богу, додумались «кешировать» результаты проверки — для каждой версии базы вирусов неизмененные файлы проверяются лишь один раз.
Но блин, я один раз встречал приложение, которое модифицирует исполняемые файлы в процессе работы и делает это часто с последующим запуском. Это был какой-то видеоконвертер, который создавал «оптимизированный» файл обработчика чуть ли не под каждый кадр. Фух, теперь вспоминаю как страшный сон.
Антивирусу это не понравилось и каждый раз надо было нажимать какие-то кнопки для продолжения.
Но блин, я один раз встречал приложение, которое модифицирует исполняемые файлы в процессе работы и делает это часто с последующим запуском. Это был какой-то видеоконвертер, который создавал «оптимизированный» файл обработчика чуть ли не под каждый кадр. Фух, теперь вспоминаю как страшный сон.
Антивирусу это не понравилось и каждый раз надо было нажимать какие-то кнопки для продолжения.
Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.
В этом и проблема. Да, в данном случае Загрузчик IS не проверяет, что он устанавливает. Так же, как и загрузчик mail.ru. Возможно, это старая версия IS лохматых времен, а новые проверяют, а Realtek и прочие не озаботились апгрейдом.
Но есть и различие с загрузчиком mail.ru. Устанавливаемый контент находится не внутри загрузчика, а скачивается по определенному URL. У mail.ru ЕМНИП была процедура проверки загружаемого приложения (отдельный вопрос, насколько она была честной и тщательной, но была). Но результаты этой проверки не фиксировались в виде цифровой подписи самого контента. Достаточно подменить файл по этому URL и троян-даунлоадер готов.
То, что установка идет через прокси, сути не меняет. Единственная цель всей этой схемы — беспрепятственное попадание левого ПО на комп неискушенного пользователя. «Левого» в данном случае означает, что автор поделки не тратился на сертификат, его никто не проверял, что он не мошенник и не вирмейкер. То есть доверия к нему никакого. А ваша схема создает у пользователя иллюзию, что ему можно доверять. Это обман пользователя, как ни крути. Это примерно то же самое, что вывешивать сверху каждого письма зеленую плашку с текстом «Проверено антивирусом , все OK», когда на самом деле никакой проверки не производится.
Последние кавычки читать как «Проверено антивирусом AVname, все OK».
Я чуть выше написал. Если пользователь из недоверенного источника готов скачать исполняемый файл и его запустить, то помочь ему очень сложно. Если это будет не setup.exe, а zip-файл в котором будет дистрибутив чего-то с setup.exe, причем с вполне доверенной подписью — что-то изменится?
Если пользователь из недоверенного источника готов скачать исполняемый файл и его запустить, то помочь ему очень сложно.
Вы знаете, далеко не все производители софта позволяют скачать свою продукцию со своего сайта через HTTPS. Публикует хэши от выложенных бинарников и того меньше контор. И я лично помню случаи, когда с официального сайта разработчика меня перекидывало на какой-нибудь download.com, потому что это был официальный метод распространения софта.
При таком положении вещей единственный способ убедиться в аутентичности скаченного продукта — это цифровая подпись инсталлятора. И это не беда тупых пользователей, это беда самой системы распространения. Поэтому если установщик с цифровой подписью ставит всякий шлак на мой компьютер, и технически у меня нет никакого иного способа проверить подлинность установщика кроме как по его цифровой подписи, это подрывает пользовательское доверие к подписанным инсталляторам в принципе.
При таком положении вещей единственный способ убедиться в аутентичности скаченного продукта — это цифровая подпись инсталлятора.
Это Ваша точка зрения. Моя точка зрения, что в настоящий момент такого способа в Windows, вообще нет, т.к. контролируется целостность только непосредственно исполняемого файла. Разультат выполнения приложения зависит не только от исполняемого файла, который непосредственно запускается, но и от среды выполнения — динамических библиотек, данных, с которыми приложение оперирует, параметров настройки. Пока не контролируется целостность и валидность хотя бы одной компоненты — есть возможность модифицировать результат работы подписанного приложения. PoC когда запуск подписанного приложения приводит к выполнению троянского кода — выше. И это не особенность конкретного инсталлятора, такое можно сделать с практически любым подписанным EXE-файлом.
Мне кажется, для десктопных систем надо полностью отказаться от установки приложений мимо подписанных пакетов установки и не разрешать запускать приложения или менять их среду выполнения другими способами, что-то похожее есть в мобильных системах Пока этого нет в десктопных системах, но к этому все и идет.
Вы несете какой-то бред. Достаточно сделать установщик состоящий из одного исполняемого файла и подписать его. Этот файл должен содержать все необходимые данные для установки. Модифицировать его, сохранив при этом валидность подписи будет практически невозможно. В случае с даунлоадерами они должны скачивать только подписанные пакеты установки и проверять их подпись. Вот и все, хватит уже отмазываться. Вы просто не хотите обеспечить (да собственно я уверен, что и цель такую не ставили) защиту пользователя от «левого» софта.
Да и ник у вас соответствующий что тут говорить.
О да. Это безусловно меняет дело. Я надеюсь, что вам по жизни будут попадяться врачи с таким же убеждением как у вас. Они будут делать вам прививки и говорить, что мы оказываем вам медицинскую услугу «инъекция» а что мы вводим — это не наша ответственность, это к производителю вакцины, мы у них не спрашивали что это, нам сказали так нужно. Ну и почаще вам продавцов недвижимости, которые отвечают только за «подписание» договора, а что вы там получите, чтоб их не волновало. Ну и в магазине вам продавцов, которые отвечают только за правильно пробитый чек, а что там в пакете они насовли — чтоб ваша ответственность была, вы же покупаете. Почаще вам людей встречать, которые четко отделяют свою зону ответственности и чтоб она не подпадала под типичные ваши ожидания. Чтоб вам нужно было каждую закорючку проверять и кропотливо искать тех, кто возьмет на себя обязательства в полном объеме и так как вы ожидаете.
Не особо информативная статья. Заголовок
Ни короткого объяснения что это такое или как оно работает. Получилось: "- Почему ..? — Потому."
Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять паролии ответ
На наших критически важных проектах работает так называемое разделение сессий.
Ни короткого объяснения что это такое или как оно работает. Получилось: "- Почему ..? — Потому."
В скором времени мы обязательно расскажем об этом подробнее )
Но если просто, то на данный момент, для каждого домена третьего уровня выставляется отдельная Secure и HTTPOnly авторизационная кука, вместо одной общей. При этом сохраняется единая авторизация, и снижаются риски эксплуатации XSS и угона сессии на каком-нибудь богом забытом проекте компании, куда ещё не дошли руки безопасников.
Примерно по такой-же схеме работает авторизация на Google.com
Но если просто, то на данный момент, для каждого домена третьего уровня выставляется отдельная Secure и HTTPOnly авторизационная кука, вместо одной общей. При этом сохраняется единая авторизация, и снижаются риски эксплуатации XSS и угона сессии на каком-нибудь богом забытом проекте компании, куда ещё не дошли руки безопасников.
Примерно по такой-же схеме работает авторизация на Google.com
разделение же, а значит один сервис проекта — одна сессия. Получив сессию почты можешь нагадить только в почте, все остальные сервисы в рамках проекта будут обломайтунг.
Все очевидно же. Разделение сессий — это когда ни у кого не дошли руки сделать единую сессию…
А может это всё же означает персональный sid для каждого домена/проекта? И в случае смены IP (= кражи сессии) sid «перевыпускается» центральным auth-сервисом, на котором вы логинитесь? При взломе auth-сервиса это не спасает, но зато это весьма ограниченный участок, который можно за счёт этого сделать высоко надёжным. Некоторые крупные проекты примерно так и работают, судя по редиректам.
Единая сессия, всегда ведёт к большим проблемам в безопасностью, поэтому что это самый очевидный, самый лёгкий, но самый небезопасный путь. И большинство компаний начинают именно с единой сессии.
Как пример уязвимостей доступных к эсплуатации с единой сессией:
1) XSS на проекте a.domain.com, ведёт к компрометации b.domain.com. Хотя на b.domain.com — багов не было.
2) Кража кук в открытой сети на проекте a.domain.com(который не умеет https) ведёт к компрометации b.domain.com(который умеет и любит HTTPS). Потому что невозможно выставить Secure флаг для авторизационных cookie — a.domain.com работать перестанет.
и т.п.
Как пример уязвимостей доступных к эсплуатации с единой сессией:
1) XSS на проекте a.domain.com, ведёт к компрометации b.domain.com. Хотя на b.domain.com — багов не было.
2) Кража кук в открытой сети на проекте a.domain.com(который не умеет https) ведёт к компрометации b.domain.com(который умеет и любит HTTPS). Потому что невозможно выставить Secure флаг для авторизационных cookie — a.domain.com работать перестанет.
и т.п.
> злоумышленники всё же могли получить авторизационные сессии (cookie) случайных людей, а так же потенциально скомпрометировать наши SSL-сертификаты.
Они просмотрели весь трафик через свои сервера чтобы узнать это?
Они просмотрели весь трафик через свои сервера чтобы узнать это?
А вы не подумали, что при взломе сторонних сервисов где указана почта, первым делом хакеры проверяют совпадет ли пароль от сервиса с паролем от почты?
К примеру, из этой вчерашней тестовой выборки из 10 аккаунтов игрового сервера целых 3 аккаунта mail.ru были скомпроментированы.
habrahabr.ru/post/218661/#comment_7480907
А надо сказать, что огромная куча сторонних сайтов уязвима и сейчас.
Так что как минимум предупредить красным шрифтом стоит.
К примеру, из этой вчерашней тестовой выборки из 10 аккаунтов игрового сервера целых 3 аккаунта mail.ru были скомпроментированы.
habrahabr.ru/post/218661/#comment_7480907
А надо сказать, что огромная куча сторонних сайтов уязвима и сейчас.
Так что как минимум предупредить красным шрифтом стоит.
Спасибо, действительно, не подумали. Сейчас займёмся )
P.S. А может есть где-нибудь общая база знаний последствий атаки? Чтобы понять кто мог потенциально пострадать?
P.S. А может есть где-нибудь общая база знаний последствий атаки? Чтобы понять кто мог потенциально пострадать?
facepalm.jpg
Что значит «последствий»? Дело еще не закончено. Осталось прочекать все хосты в интернете — нет ли на них уязвимостей. Ну и потом мониторить, чтобы таковые не появлялись.
Вам надо предупредить об абсолютной недопустимости использовать пароль от почты где-либо еще в связи с этой уязвимостью.
Если пароли уже совпадают, то предложить срочно сменить.
Если пароли уже совпадают, то предложить срочно сменить.
> предупредить об абсолютной недопустимости
Это не работает.
1) Мозг человека физически не может генерировать криптостойкие и различные пароли. Ну пять, ну семь хороших паролей для самых нужных мне сервисов я могу держать в памяти. Для регистрации же на каком-нибудь говнофоруме используется какой-нибудь «любимый» пароль типа 111111.
2) Заранее очень сложно определить — нужен ли данный сервис мне, чтобы ради регистрации придумывать стойкий пароль и как-то его сохранить у себя.
3) Возрастной порог вхождения в интернет уменьшается — сперва условный «первоклассник» заводит себе почту, а потом уже начинает курить… тьфу! читать маны и узнает о необходимости иметь хорошую защиту
> Если пароли уже совпадают, то предложить срочно сменить.
У mail.ru нет возможности определить — совпадает ли пароль пользователя на почте с паролем на каком-либо сервисе.
Это не работает.
1) Мозг человека физически не может генерировать криптостойкие и различные пароли. Ну пять, ну семь хороших паролей для самых нужных мне сервисов я могу держать в памяти. Для регистрации же на каком-нибудь говнофоруме используется какой-нибудь «любимый» пароль типа 111111.
2) Заранее очень сложно определить — нужен ли данный сервис мне, чтобы ради регистрации придумывать стойкий пароль и как-то его сохранить у себя.
3) Возрастной порог вхождения в интернет уменьшается — сперва условный «первоклассник» заводит себе почту, а потом уже начинает курить… тьфу! читать маны и узнает о необходимости иметь хорошую защиту
> Если пароли уже совпадают, то предложить срочно сменить.
У mail.ru нет возможности определить — совпадает ли пароль пользователя на почте с паролем на каком-либо сервисе.
> предупредить об абсолютной недопустимости
Это не работает.
1) Мозг человека физически не может генерировать криптостойкие и различные пароли. Ну пять, ну семь хороших паролей для самых нужных мне сервисов я могу держать в памяти. Для регистрации же на каком-нибудь говнофоруме используется какой-нибудь «любимый» пароль типа 111111.
Противоречивая какая то информация. Если я могу запомнить два пароля, то уже могу использовать один — для почты, а другой — для всего остального. А уж тем более 5 или 7 :)
Ну и очередной повод обзавестись менеджером паролей для хранения учетных данных на всяких не очень часто посещаемых сервисах.
Вы говорите «как должно быть», я с этим не спорю, но рассказываю «как есть на самом деле».
Человек сперва заводит себе почту, потом узнает о криптостойкости и много-много времени спустя приходит к использованию менеджеров паролей. Во всех книжках, во всех местах на всех сайтах написано, что не надо использовать один и тот же пароль на разных ресурсах. От того, что мы с вами повторим это еще раз для посетителей хабра — ничего не изменится. Здешняя аудитория об этом и так знает (надеюсь)
Если mail.ru произведет рассылку по пользователям и/или повесит алерт о желательности смены пароля (придется вешать всем) — по большому счету тоже мало что изменится. Бегущий генерал вызывает в военное время панику, а в мирное время — смех. Еще раз повторю — я не считаю, что это делать не надо. Я говорю, что это не спасет.
Человек сперва заводит себе почту, потом узнает о криптостойкости и много-много времени спустя приходит к использованию менеджеров паролей. Во всех книжках, во всех местах на всех сайтах написано, что не надо использовать один и тот же пароль на разных ресурсах. От того, что мы с вами повторим это еще раз для посетителей хабра — ничего не изменится. Здешняя аудитория об этом и так знает (надеюсь)
Если mail.ru произведет рассылку по пользователям и/или повесит алерт о желательности смены пароля (придется вешать всем) — по большому счету тоже мало что изменится. Бегущий генерал вызывает в военное время панику, а в мирное время — смех. Еще раз повторю — я не считаю, что это делать не надо. Я говорю, что это не спасет.
Я бы не говорил, что это «не работает», я бы сказал, что у этого способа «низкая эффективность». Можно сколько угодно напоминать пользователям о том, что нужно иметь разные пароли для разных сервисов, но пока пользователь сам до этого не дозреет — эти напоминания ни к чему не приведут. Но на тех, кто «дозрел», напоминание все же может повлиять.
По большому счету — ничего не изменится, но если считать конкретных людей, которых эта рассылка может подтолкнуть к действиям — то, вполне возможно, польза будет. Не «спасение», ни в коем разе. В этом случае вполне подходит фраза о том, что «спасение утопающего — дело рук самого утопающего».
По большому счету — ничего не изменится, но если считать конкретных людей, которых эта рассылка может подтолкнуть к действиям — то, вполне возможно, польза будет. Не «спасение», ни в коем разе. В этом случае вполне подходит фраза о том, что «спасение утопающего — дело рук самого утопающего».
Вы правы, это плохо, т.к. на многих сервисах е-мейл является логином, если пароль там совпадает с паролем от почтового ящика — это катастрофа. Мы стараемся об этом предупреждать пользователя при любой удобной возможности, я говорю это в каждом комментарии в СМИ по поводу безопасности. К сожалению, заставить людей довольно сложно.
Если вы имеете ввиду разные ресурсы mail.ru, то у нас централизованная система аутентификации, почти для всех ресурсов mail.ru пользователь авторизуется в одном месте и нет необходимости хранить и защищать много паролей в разных местах. Что во многом спасло нас от этой атаки.
А вто то, что пользователь использует один и тот же пароль в разных сервисах — это действительно проблема, о ней мы стараемся говорить при каждом удобном случае. Вот здесь, например: http://habrahabr.ru/company/mailru/blog/169801/ достаточно подробно объясняется почему не надо так делать.
А вто то, что пользователь использует один и тот же пароль в разных сервисах — это действительно проблема, о ней мы стараемся говорить при каждом удобном случае. Вот здесь, например: http://habrahabr.ru/company/mailru/blog/169801/ достаточно подробно объясняется почему не надо так делать.
могу добавить что из примерно 10 проверенных с сайта который для меня важен — в одном случае логин и пароль пользователя с mail.ru подошел к почте… дальше… было решено не смотреть. так что проблема вполне себе реальная.
Добавьте, пожалуйста, кармы до 5, не могу опубликовать статью о вредоносном скрипте в Google Analytics (Да простит меня НЛО)
Ok, можете минусовать мне карму. Вот сам топик: storage.sashok724.net/temporary/habratopic.html
Если кто хочет — выложите. Правда, интересно, у одного ли меня такая проблема.
Если кто хочет — выложите. Правда, интересно, у одного ли меня такая проблема.
Такие просьбы пишут только друзьям в личку, и то НЛО за такое может забанить даже «топовых» пользоватей и за благие намерения.
Всем еще раз спасибо, в отрицательной карме доступен Recovery Mode ;)
Disclaimer: Мнение автора комментария может не совпадать с мнением его работодателя.
Вы уж простите, не удержался.
Вы уж простите, не удержался.
Твой позорный недуг в подвиг определим. © ДМБ
Привет Эльдар :) Вас там бьют в Яндексе за несогласие с мнением партии?
В чём же наш позорный недуг?
В чём же наш позорный недуг?
мне нечего о нем рассказать т.к. я к нему не имею никакого отношения.
Скорее это моя личная профессиональная деформация:
www.ssllabs.com/ssltest/analyze.html?d=e.mail.ru
странно видеть, как люди пиарятся на отключении TLS в 2014 году ;)
Peace.
www.ssllabs.com/ssltest/analyze.html?d=e.mail.ru
странно видеть, как люди пиарятся на отключении TLS в 2014 году ;)
Peace.
Теперь этот баг будет поводом для ПР? 8)
>Хотя на этих проектах Heartbleed не давала возможности получить доступ к личным данным, логинам или паролям пользователей
Это вы так думаете что не давала. А кто знает что там на самом деле. Сертификаты то вы перевыпустили! Короче mail.ru в своем стиле-как всегда «заботится» о пользователях.
Это вы так думаете что не давала. А кто знает что там на самом деле. Сертификаты то вы перевыпустили! Короче mail.ru в своем стиле-как всегда «заботится» о пользователях.
Sign up to leave a comment.
Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять пароли