Глава 18. Причины ослабления средств защиты
Разработать по-настоящему надежное программное средство защиты, хорошо справляющееся со всеми возложенными на него задачами, довольно сложно. Многие компании берутся за подобные проекты. Некоторые из них даже достигают коммерческих успехов. Но действительно хорошо справляются единицы.
Рассмотрим несколько основных причин, приводящих к неудачам в попытках разработки средств зашиты.
18.1. Непрофессионализм
В любой области деятельности лучше поручать важную работу профессионалам. Они способны быстро принимать правильные решения в сложных ситуациях. Для этого им приходится долго учиться и практиковаться под присмотром более опытных коллег, которые должны быть готовы прийти на помощь в случае ошибки. Но почему-то при разработке средств защиты обычно все не так.
18.1.1. Иллюзия простоты
Когда над каким-либо проектом работает группа программистов и выясняется, что в существующей системе необходимо предусмотреть функции защиты, чаще всего руководитель проекта возлагает реализацию защиты на плечи одного из имеющихся исполнителей.
Или представим ситуацию, когда программист-одиночка разрабатывает программу, основная функциональность которой относится к той области, в которой он является высококлассным специалистом. И вот, появляется идея защитить часть данных при помощи шифрования. Неужели человек станет тратить время на поиск специалиста по безопасности, а потом изыскивать деньги на оплату его услуг? Скорее всего, нет.
Стоит ли привлекать новых людей, если существующие программисты прекрасно знают свою работу? Надо ли тратить деньги на оплату услуг специалиста по безопасности? Ведь в защите информации нет ничего сложного! С помощью функции из трех строк можно перевести пароль в такой вид, что никто никогда не сможет отгадать, что это за пароль. А еще три строки позволят зашифровать данные. И вот защита готова и даже работает. Ведь если ввести неправильный пароль, то программа ничего не покажет. И при просмотре файла с защищенной информацией в шестнадцатеричном редакторе не видно ни пароля, ни самих данных.
При таком подходе к разработке защиты обычно удается сэкономить некоторое количество денег и времени. Правда потом, когда защита будет взломана, за построение нормальной защиты (если разработчики дорожат своей репутацией) все равно придется заплатить.
Может получиться и по-другому. Иногда человек, перед которым ставят задачу реализовать, например, цифровую подпись, обращается к поисковой системе Google, находит криптографическую библиотеку с подходящей лицензией и использует реализованный в ней механизм подписи "как есть". С чувством хорошо выполненного долга он сдает работу и очень сильно удивляется, когда даже стойкий криптографический алгоритм не смог предотвратить взлом.
Защита информации — это такая область, где нельзя быть специалистом частично. Если в других отраслях возможность применения 90 % существующих технологий приводит к результату, который на 10 % хуже идеального, то в защите информации проценты не играют никакой роли. Полученное решение будет или защищенным, или незащищенным.
Но, к сожалению, понимание того, что специалисты по защите информации не зря едят свой хлеб, ко многим приходит даже не с первого раза. Иначе чем можно объяснить многократные попытки улучшения защиты, конечным результатом которых является легко уязвимая система?
18.1.2. Излишнее усердие
Частным случаем непрофессионализма можно считать попытки защищать даже то, что не нуждается в защите.
Иногда разработчики зашифровывают часть несекретной информации точно таким же образом, как и информацию, которая нуждается в защите. Если при этом программа позволяет просматривать расшифрованную несекретную информацию, то иногда удается подменить зашифрованные данные и увидеть их в расшифрованном виде.
Шифрование паролей в ReGetDeluxe
Программа управления выкачиванием файлов ReGet Deluxe позволяет запоминать настройки закачки раздельно для каждого файла и каждого сайта. Если для доступа к серверу, например, по протоколу FTP (File Transfer Protocol) требуется пароль, он тоже сохраняется.
Все настройки хранятся в файле с расширением wrj, который сам ReGet называет файлом очереди (ReGet Junior/Deluxe Queue File). Этот файл представляет собой ХМL-документ, в котором визуально очень легко найти всю информацию, относящуюся к конкретному файлу или сайту. Но информация об имени пользователя и пароле доступа хранится в зашифрованном виде. Правда, запустив ReGet, можно в свойствах файла или сайта увидеть имя пользователя, а вот пароль будет представлен в виде набора звездочек.
Разумеется, существует возможность выяснить, каким образом выполняется расшифрование, т.к. ReGet способен расшифровывать пароль, не задавая пользователю дополнительных вопросов. Правда, для этого придется исследовать сам ReGet, а это требует довольно высокой квалификации и обычному пользователю недоступно.
Однако на практике пароль можно извлечь, используя только текстовый редактор и сам ReGet. Если в WRJ-файле поменять местами значения атрибутов "Usemame" и "Password" для нужного сайта, то ReGet в поле, соответствующем имени пользователя, покажет открытым текстом пароль, а имя пользователя окажется представленным в виде звездочек.
Но если бы имя пользователя не шифровалось вообще (что не снижает защищенность, ведь имя все равно показывается в настройках), то заставить ReGet расшифровать пароль и показать его на экране было бы не так просто.
