Комментарии 52
Хорошая статья! Большое спасибо!
Хорошее изложение. :) В контексте борьбы с паролями стоило бы упомянуть про другие подходы (и их риски) — двухфакторная аутентификация, биометрия, и т.п., благо сейчас это доступно даже не особо продвинутым людям.
Скажите, а как вы относитесь к сервисам хранения паролей типа LastPass?
Такую базу паролей можно вести с помощью бесплатной утилиты KeePass. Сама база паролей конечно же шифруется, но для дополнительной защиты можно ее записать на надежный внешний носитель и работать с данными только на нем.
Во-во, вот на эту KeePass и надо проводить атаку, dll-шку подменить, чтобы она шифровать перестала, а пользователь будет думать, что он защищён. Активности никакой, просто база вся в открытом виде лежит.
А ещё на Excel, который помогает ему вычислять планы рисков и гипотезы, — самое то для прослушки. Или просто ради прикола программка типа Punto Switcher будет вносить изменения в эти планы.
Просто их надо помнить и для усложнения просто транслировать в сложную последовательность через какой-нибудь алгоритм (секретный), по которому в случае компрометации не поймёшь, как он составлен
В данном случае сразу две проблемы — нарушение принципа Керкго́ффса и… в общем, смотрите статью — вы опасно некомпетентны в криптографии, — была на хабре.
Но, как известно, пароли сейчас не являются самым слабым звеном, потому что они легко тырятся
Вы не правы. Пароли тырятся довольно редко. Если и тырятся в массовых количествах, то хеши паролей. И вот тут слабость паролей играет ключевую роль — слабые пароли легко подбираются по таблицам.
Так что вот эти все вещи типа брутфорса и прочая фигня уже давно устарели и считаются непрофессиональными.
О, да! Потырили хацкеры хеши и сказали такие — не, подбирать их непрофессионально, не будем из принципе! Смешно.
В данном случае сразу две проблемы — нарушение принципа Керкго́ффса
Теоретик виден сразу.
Во-первых — сложно подменить dll-ку, если программа состоит из одного exe-шника :D
Шифрация в него прямо и встроена. Кроме того он постоянно проверяет консистентность базы.
Не верите — посмотрите исходники — они лежат в открытом доступе.
Во-вторых, имея доступ, который позволяет что-то подменять на компьютере жертвы, украсть пароли — вообще не проблема и способов миллион.
Шифрация в него прямо и встроена. Кроме того он постоянно проверяет консистентность базы.
Не верите — посмотрите исходники — они лежат в открытом доступе.
Речь о том, что никто не проверяет, что там куда сохраняется. Есть файл — значит, всё нормально. Он говорит «я вот в KeePass сохраню всё и оно будет защищено», а ты думаешь он проверяет целостность постоянно? Нет, он один раз при скачивании проверил (и то, если понимает), а потом на автомате по окну делает вывод, что перед ним всё та же проверенная программа (и то, если он проверял вообще). Любые известные программы (массовые), они все под прицелом.
Он === KeePass, и он постоянно следит за своей базой — при открытии, при закрытии и т.д.
Другое дело про пользователя.
Но если Вы — реально параноик, то за одной основной программой следить — не проблема, не так ли?
Я вот помню последние 4 цифры CRC проги, в которой держу все свои пароли и каждый раз при запуске у меня запускается тулза, которая считает ее CRC и показывает это мне, затем уже запускает программу.
Довольно просто все.
Ну и как всегда — защита зависит от тебя самого, серебряной пули нет.
И KeePass тут не причем :)
Он === KeePass, и он постоянно следит за своей базой — при открытии, при закрытии и т.д.
Я имею в виду, что это всё можно изобразить. А то, что CRC там проверяешь, это тоже легко ломается. Типа «дорогой пользователь, у нас вышла новая версия KeePass, приглашаем вас её скачать», ты такой «ой, что-то я ссылку не помню на сайт их, а открою-ка я вот эту» — и всё, и пошёл ты и скачал то, что тебе зарядили. Там даже тебе повесят md5 на «сайте», чтобы ты проверил, что всё правильно и CRC себе новую сделал, но уже сам (об этом даже знать не надо, вот в чём фишка-то).
ты такой «ой, что-то я ссылку не помню на сайт их, а открою-ка я вот эту»Вот не надо меня с собой путать :D
Такого рода программы я обновляю только сам и только вручную (причем в этом конкретном случае я еще и сам из исходников собираю) и только, когда считаю важным.
Мало того — если я увижу такое поведение — оно мне сразу однозначно просигнализирует о компрометации.
Ну и никакие «MD5» на сайте не сканают — при запуске покажется реальная CRC.
А то, что CRC там проверяешь, это тоже легко ломается.Для этого надо это знать и предусмотреть, ну и «сломать» это весьма не просто. Для этого надо оставить программу либо как есть и использовать хуки и подмену при запуске или юзать коллизии — что уже само по себе — высший пилотаж.
Как, собственно, у KeePass и сделано: http://keepass.info/integrity_sig.html
Для критично важных приложений должны быть не md5 или другие чексуммы, а gpg-подписи (криптостойкие).
Ну, засунули тебе gpg-подпись, дальше что? Как ты читаешь gpg-попись? У тебя даже приём этой gpg-подписи никак не контролируется. Ты даже с уверенностью сказать не можешь, что тебе пришла по https та gpg-подпись, которую ты на сайте запрашивал. Почему? Потому что ты их не сравниваешь.
Как говорили в FIDOnet, отучаемся говорить за всех. Кто не проверяет — тому и страдать от возможной подмены.
Есть разработчик, у него есть пара gpg-ключей, приватный и публичный. Приватный ключ лежит на его машине, он секретный и он его никому никогда не даёт. Публичный лежит в паблике, его можно взять с официальных доверенных сайтов типа https://pgp.mit.edu/.
Разработчик при релизе подписывает бинарь своим приватным ключом, и получает gpg-подпись. Кладёт релизный бинарь и gpg-подпись на сайт, который работает по https.
Пользователь качает бинарь и gpg-подпись. На своей машине считает подпись бинаря и сравнивает с тем, что скачал с сайта. Это делается программой GPG, которой для проверки нужно дать публичный ключ того, кто подписывал бинарь. Который можно/нужно взять с сайтов-хранилищ ключей, типа https://pgp.mit.edu/.
И я не вижу атаки, при которой можно подменить бинарь на сайте. Кроме ситуации, когда взломали и сайт, и украли ключи с машины разработчика, а он почему-то про это не сообщил и не отозвал свой ключ в тот момент, когда узнал о взломе.
И да, я проверяю gpg-подписи важных для меня приложений, которые использую.
И я не вижу атаки, при которой можно подменить бинарь на сайте.
Потому что ты не знаешь нихрена, и вас таких тут большинство.
Предложите альтернативное решение?
Это всё полная туфта.
Вы мало того, что высказываете ничем не подкреплённое мнение, используя аргументы школьного уровня,
ты не знаешь нихрена, и вас таких тут большинство.
так вдобавок ещё и откровенно хамите.
Тут ведь еще вопрос потенциальной ценности данных. Не слишком ли сложный вариант вы описали для кражи данных у рядового пользователя?
Хотя написано вполне живо, да, согласен.
Wi-Fi-адаптеры Alfa на хорошем счету у ребят, «работающих» с Wi-Fi.
Ps по управлению рисками — в исо 27001 не прописывается конкретная модель. имеется конечно же 27005, но то что вы привели в статье — не совсем по 27005. впрочем, исо 27001 вы со своим подходом пройдете)
По тексту, фото там были…
Там вообще постараться надо, чтобы оно адресату в ящик попало. GMail не принимает письма, содержащие исполняемые файлы. Даже в архивах. Только если архив зашифрован с шифрованием имен файлов.
1.
— шифрование данных на жестком диске;
— гарантированное уничтожение данных на жестком диске
Покажете сценарий, при котором второй пункт не является излишним при правильном соблюдении первого?
2.
резервное копирование в облако;
Как при этом мы оцениваем риск несанкционированного доступа к копии данных?
2) Все зависит от того, какие именно данные синхронизируете, как оцениваете последствия от их компрометации, как соотносятся последствия от потери данных с последствиями от несанкционированного доступа. Главное, не забыть про данный риск.
1) Пользователь загружает файл из почты в папку downloads и только потом переносит, куда следует, или не переносит вовсе, забывая ее навечно.
Ну так это же и есть неправильное (неполное) соблюдение первого пункта? Почему папка downloads на нешифрованном разделе?
2… Главное, не забыть про данный риск.
Я именно к этому и вел. Я бы подчеркнул в тексте, что делегирование защиты данных в облаке администратору облака — не повод не оценивать связанные с этим риски
— шифрование данных на жестком диске;
— гарантированное уничтожение данных на жестком диске
Покажете сценарий, при котором второй пункт не является излишним при правильном соблюдении первого?
Появление в будущем квантовых компьютеров? Обнаружение уязвимости алгоритма шифрования/бэкдора в VeraCrypt?
Т.е. я предполагаю, что важную информацию пользователь хранит, неважную или потерявшую актуальность — удаляет. Взломали шифрование? Ок, получают доступ к важной. Гарантированное удаление от этого не защищает.
Я не утверждаю, что такого сценария нет, но я его не вижу.
Цель: защитить данные от разглашения
Мера 1: Шифрование.
Мера 2: Уничтожение.
Мера 1 защитит данные, но может повысить риск применения методов криптоанализа типа «паяльник».
В случае Меры 2 (если уничтожение произошло) может быть обойдётся и без «паяльника».
Уже много лет пользуюсь им, пока воровства паролей не замечено…
Интернет-контрразведка в действии: создаем персональную систему менеджмента информационной безопасности