Специалист по кибербезопасности – достаточно новая для нашей профессия. Возможность получить образование в этой области появилась достаточно недавно, и зачастую эту должность занимают самопровозглашённые «диванные кибербезопасники», получившие образование из сборников давно устаревших советов и вырванных из контекста цитат. В этой статье мы развеем некоторые мифы, не имеющие ничего общего с реальной безопасностью.
Пароли нужно менять. Желательно – ежемесячно.
Необходимость периодической смены паролей – распространённый среди диванных кибербезопасников миф. Начнём с того, что у среднего пользователя может быть несколько устройств (как минимум – компьютер и смартфон) и несколько десятков, а то и сотен учётных записей. Смена всех этих паролей как раз и займёт один-два рабочих дня. Если повторять эту процедуру ежемесячно, производительность труда работников окажется под угрозой.
Даже если речь идёт о единственном пароле, то чаще всего пользователи, если им предоставить право выбора, будут использовать вариации на тему одного и того же пароля (Password1986, Password1987, Password 1988 и далее по списку). Такая смена пароля никак не увеличивает безопасность, создавая вполне закономерное раздражение у пользователей, вынужденных заниматься совершенно бессмысленным трудом. Если же пароль менять на случайный, то нужно быть готовым к тому, что запомнить его не сможет никто, и пароль начнут записывать на бумаге. Что приводит нас к следующему мифу.
Нельзя записывать пароль на бумаге
Нельзя хранить пароль там, где к нему могут получить доступ посторонние. Нельзя хранить пароль вместе или рядом с устройством, которое он защищает (например, в виде наклейки на ноутбук или стикера на мониторе). Пароль, который записан на бумаге, можно хранить в безопасном месте, в котором до него точно не доберутся посторонние, причём определение «безопасного» места будет разным в различных ситуациях. Например, для офиса нормально хранить распечатанные пароли в сейфе, а для дома безопасным хранилищем может быть и выдвижной ящик. Записанный на физическом носителе стойкий пароль намного более безопасен, чем нестойкий, повторяющийся, шаблонный пароль, который пользователь в состоянии запомнить.
Впрочем, пароли записывать удобнее всё-таки не на бумаге, а в специализированном приложении для хранения паролей.
Мы будем хранить пароли в приложении!
Само по себе решение хранить пароли в специализированном приложении – правильное, но нужно понимать разницу между различными решениями и их безопасностью. Так, все сохранённые в браузере (Chrome, Edge, Firefox) пароли доступны любому, кто получит доступ к вашему компьютеру с разблокированным экраном. Достаточно запустить приложение, и все пароли – как на ладони!
Синхронизация сохранённых паролей в облако – тема для отдельного разговора. Отмечу лишь, что Google и Microsoft пароли своих пользователей в облаке не шифруют (к паролям есть доступ как у самих компаний, так и у любого, кто сможет войти в учётную запись), а Apple – шифрует (ваши пароли остаются неизвестными компании, а для их скачивания и расшифровки потребуется дополнительно ввести код блокировки одного из привязанных к учётной записи устройств, который вряд ли станет известен злоумышленнику, даже если он сможет украсть логин и пароль).
Кстати, вполне допустимым вариантом будет хранение паролей в зашифрованной таблице Excel – её даже можно синхронизировать с облаком OneDrive. Убедитесь, однако, что пароль от этой таблицы действительно стойкий, что вы помните его наизусть и не используете ни в одном другом приложении или сервисе.
AES-256 – это всегда безопасно
На самом деле, нет. Стойкий алгоритм шифрования — это крепкие дубовые ворота. Но есть ещё замок, есть — ключ, есть сейф, в котором этот ключ хранится. Наконец, есть забор или ограда. Зачем ломать ворота, если можно сорвать замок, провернуть «собачку» куском проволоки, украсть ключ или и вовсе перепрыгнуть через забор? Никто и никогда не будет пытаться сделать рефакторинг 256-разрядных ключей, которые алгоритм AES использует для шифрования данных. Будут — пытаться подобрать пароль (пробовать отмычки), узнать пароль из других источников (выкрасть ключ), наконец — обойти ворота с другой стороны (использовать уязвимость — к примеру, вытащить ключ из оперативной памяти компьютера).
Отличный пример использования стойкого, но бессмысленного шифрования описан в статье Особенности шифрования и уязвимости в сетевых хранилищах Synology. Данные в сетевых хранилищах компании шифруются непосредственно паролем, который устанавливает пользователь (это уже неправильно; во всех грамотных реализациях используются ключ-посредник и/или мастер-ключ). При этом сам пароль шифруется фиксированной, жёстко прошитой в систему фразой “$1$5YN01o9y” – аналогом печально известного “default_password”, использующегося при шифровании по методу FDE в Android.
Пока ничего ужасного не произошло, за исключением того, что вместо стойкого ключа шифрования, сгенерированного случайным образом, который невозможно подобрать даже в теории, для шифрования используется текстовый пароль, очень даже поддающийся атакам. Да, это неправильно, но грамотный пользователь может учесть этот момент и самостоятельно сгенерировать случайный ключ.
Проблемы начнутся, если пользователь для удобства сохранит ключ во встроенном хранилище и включит опцию «автоматически монтировать папки при загрузке». Теперь этот сохранённый ключ будет зашифрован всё тем же известным нам паролем по умолчанию. Теперь можно не только расшифровать данные, но и увидеть сам пароль, который вводил пользователь! Далее этот пароль можно попробовать использовать для расшифровки другой информации по цепочке.
AES-256 – это плохо; нужно использовать нестандартный шифр
И снова – нет. В статье Расшифровка криптоконтейнеров VeraCrypt мы подробнейшим образом объяснили, на что влияет, а на что – совершенно не влияет выбор алгоритма шифрования – даже если выбирать из самых стойких вариантов или (конечно же, «для безопасности») шифровать данные дважды, а то и трижды с помощью разных алгоритмов.
В популярном (и действительно безопасном) продукте VeraCrypt предлагается выбор из пяти алгоритмов шифрования (AES, Serpent, Twofish, Camellia и «Кузнечик») и десяти вариантов их последовательного использования. При этом достаточно посмотреть на таблицу ниже, чтобы убедиться, что выбор какого-то конкретного алгоритма шифрования если и оказывает влияние на скорость атаки, то самое минимальное по сравнению с другими факторами.
Какими именно факторами? На скорость атаки влияет, например, то, известен ли атакующему алгоритм, которым зашифрованы данные. Обратите внимание: совершенно неважно, каким именно алгоритмом или алгоритмами данные зашифрованы, важно лишь то, известен алгоритм или нет. Если провести подобную атаку на диск, зашифрованный алгоритмом Serpent, то цифры не изменятся (нет, мы не копировали данные: все цифры были перепроверены несколько раз). Если нет, то в процессе перебора паролей придётся пробовать все 15 возможных комбинаций, только и всего.
А ещё на скорость атаки влияет выбранный алгоритм хеширования, посредством которого текстовый пароль преобразуется в ключ шифрования ключа шифрования. Последовательное использование двух шифров немного уменьшит скорость перебора, а трёх – уменьшит сильнее; разница в скорости, тем не менее, несравнима с тем, какое влияние на скорость перебора оказывает выбор хеш-функции. Так, выбор Whirlpool вместо SHA-512 замедляет скорость перебора с 1140 до 74.6 паролей в секунду.
А ещё очень сильно влияет количество итераций (раундов хеширования), которое используется для вычисления ключа шифрования. Миллион итераций перебирается ровно в миллион раз медленнее, чем одна-единственная.
Чтобы не попасться на уловку с выбором алгоритма шифрования, рекомендуем ознакомиться со статьёй Шифрование != хеширование. Как шифруются документы и защищаются пароли.
Стандартные решения легко взломать. Мы напишем своё!
Очень грустная ситуация, когда нанятый специалист по кибербезопасности начинает «писать своё». Как правило, созданная с нуля система безопасности и неудобна, и небезопасна: смысл принципа “security through obscurity” полностью аналогичен принципу «неуловимого Джо»: ваши данные в безопасности ровно до тех пор, пока они никому не нужны.
К счастью, в современном мире настолько безграмотных «специалистов» осталось мало, но на удивление они ещё встречаются – причём даже в крупных компаниях. Мы получили порцию чистой, незамутнённой радости, граничащей с умилением, в процессе исследования «безопасности» индийского бухгалтерского пакета Tally ERP 9. Разработчики этой программы решили не полагаться на существующие криптографические решения и создали свой собственный вариант, настоящий кошмар криптографа.
Почему «кошмар»? Индийскими разработчиками были нарушены абсолютно все базовые принципы безопасности начиная с азов. Все существующие алгоритмы хеширования без исключений гарантируют, что изменение всего одного бита в хешируемой последовательности приведёт к полному изменению всей контрольной суммы. Индийским разработчикам удалось сделать невероятное: они создали хеш-функцию, в которой при небольшом изменении пароля результат тоже меняется очень незначительно. Более того, у нас создалось впечатление, что при определённых условиях этот хеш можно обратить, получив из него оригинальный пароль (разумеется, если энтропия пароля не превышает энтропии его контрольной суммы). Вишенка на торте: преобразование применяется ровно один раз (почему это плохо – мы описали в предыдущем разделе).
Дальше – хуже. Вместо стандартного шифра AES индийские разработчики решили создать что-то своё, оригинальное и безопасное. Однако придумать что-то новое – не смогли, взяв за основу найденный на просторах интернета код шифра DES, использовавшегося в качестве государственного стандарта шифрования США в далёком 1977 году. Вместо «небезопасных» 256-битных ключей AES собственный шифр Tally использует для шифрования ключи длиной 64 бита (которые в процессе работы разворачиваются в расширенный 128-битный, как и у «настоящего» DES). Уже на этом месте можно прекратить исследование и реализовать простейшую атаку на ключ: 64 бита, да ещё и на таком древнем алгоритме вполне позволяют сделать полный рефакторинг пространства ключей за считанные дни. Впрочем, принцип «неуловимого Джо» надёжно защищает Tally от подобных атак.
SMS взломали, поэтому мы не будем использовать двухфакторную аутентификацию
Уязвимостей в протоколах сотовой связи хватает, а двухфакторная аутентификация через SMS – один из худших, если не худший вариант. Известны случаи, когда SIM-карты для получения кода через SMS получались по поддельным документам или доверенностям, что также не добавляет доверия этому способу двухфакторной аутентификации.
Ошибка в данном утверждении в слове «поэтому». Да, SMS – плохой вариант двухфакторной аутентификации. Однако любой вариант двухфакторной аутентификации, даже самый слабый, в бесконечное число раз безопаснее варианта без неё. Если есть возможность использовать альтернативный способ двухфакторной аутентификации – используйте его, но если такого способа нет – пользуйтесь одноразовыми кодами через SMS, и это всё равно во много раз безопаснее авторизации только по логину и паролю.
Мы используем VPN, он нас защитит
VPN – слишком обширная тема для того, чтобы просто сказать «да, VPN защищает» или «нет, VPN вас не защитит». Да, VPN защищает от ограниченного спектра угроз, но и сам может стать угрозой, если под VPN имеется в виду внешний, публичный сервис, а не корпоративный VPN, который используется для доступа к офисной локальной сети из дома.
При использовании VPN – хоть корпоративного, хоть публичного сервиса, – все данные с вашего устройства будут проходить через специальный зашифрованный туннель. С точки зрения стороннего наблюдателя будет видно лишь соединение между устройством и сервером VPN и тот факт, что через него передаются зашифрованные пакеты. Ни расшифровать трафик, ни даже определить ресурсы, к которым обращается устройство, со стороны невозможно.
Однако невозможное со стороны вполне осуществимо на стороне провайдера VPN. Используя соединение VPN, вы доверяете свой трафик корпоративному серверу или стороннему публичному сервису, который получает полную информацию о том, какие узлы вы посещаете и с какого именно реального IP-адреса. Очень важно то, как именно провайдер VPN распорядится этим знанием. Если речь идёт о корпоративном VPN, то беспокоиться об этом пользователю не нужно; если же речь о публичном (тем более – бесплатном) сервисе, то хорошо бы внимательно ознакомиться с его политикой конфиденциальности.
В статье Иллюзия безопасности: платные сервисы VPN, прокси и Apple Private Relay мы подробно рассказали, чем может грозить неправильный выбор провайдера VPN и от каких именно угроз способен защитить его использование.