19 смертных грехов, угрожающих безопасности программ
Шрифт:
Повторное воспроизведение потока случайных чисел
Если по какой–то странной причине (например, для моделирования методом Монте Карло) вы захотите воспользоваться генератором случайных чисел, так чтобы можно было сохранить затравку, а затем воспроизвести весь поток, то получите исходную затравку от системного генератора, а затем используйте ее в качестве ключа для вашего любимого блочного шифра (например, AES). Рассматривайте 128–битовые входные данные для AES как одно 128–разрядное число. Начните с 0. Получите на выходе 16 байтов, зашифровав это значение. Когда понадобятся следующие данные,
Такой генератор порождает случайные числа криптографического качества, ничем не хуже любого другого. На самом деле это хорошо известная конструкция, превращающая любой блочный шифр в потоковый; она называется режимом счетчика.
Дополнительные защитные меры
Если приобретение аппаратного генератора случайных чисел оправдано, то есть несколько решений. Но для большинства практических целей системного CRNG–генератора должно хватить. Впрочем, если вы создаете программное обеспечение для проведения лотерей, то есть смысл рассмотреть и такую альтернативу.
Другие ресурсы
□ Стандарт NIST FIPS 140 содержит рекомендации относительно случайных чисел, прежде всего проверки их качества. Сейчас выпущена вторая редакция стандарта: FIPS 140–2. В тексте первой редакции процедура тестирования случайных чисел была описана более детально, так что есть смысл ознакомиться с ней: http://csrc.nist.gov/cryptval/140–2.htm
□ Система сбора и распределения энтропии (EGADS – Entropy Gathering AND Distribution System) предназначена главным образом для систем, не имеющих собственного CRNG–генератора и механизма сбора энтропии: www.securesoftware.com/resources/download_egads.html
□ RFC 1750: рекомендации по обеспечению случайности в целях безопасности: www.ietf.org/rfc/rfcl750.txt
□ «How We Learned to Cheat at Online Poker» by Brad Arkin, Frank Hill, Scott Marks, Matt Schmid, Thomas John Walls, and Gary McGraw: www.cigital.om/ papers/download/developer_gambling.pdf
□ «Randomness and Netscape Browser» by Ian Goldberg and David Wagner: www.ddj.com/documents/s=965/ddj9601h/9601h.htm
Резюме
Рекомендуется
□ По возможности пользуйтесь криптографическим генератором псевдослучайных чисел (CRNG).
□ Убедитесь, что затравка любого криптографического генератора содержит по меньшей мере 64, а лучше 128 битов энропии.
Не рекомендуется
□ Не пользуйтесь некриптографическими генераторами псевдослучайных чисел (некриптографические PRNG).
Стоит подумать
□ О том, чтобы в ситуациях, требующих повышенной безопасности, применять аппаратные генераторы псевдослучайных чисел.
Грех 19. Неудобный
В чем состоит грех
Несколько лет назад инженеры из Центра проблем безопасности Microsoft (Microsoft Security Response Center – MSRC) сформулировали 10 незыблемых законов безопасного администрирования. Второй закон звучит так:
Система безопасности работает только тогда, когда безопасный способ одновременно является простым.
Ссылку на 10 незыблемых законов вы найдете в разделе «Другие ресурсы».
Безопасность и простота часто конфликтуют. Пароли – это один из популярных «простых» способов, но безопасным его обычно не назовешь (см. грех 11).
Существует специальная дисциплина, изучающая практичность интерфейсов. Она учит, как создавать программы, с которыми конечным пользователям будет удобно работать. Ее основные принципы можно применить и к безопасности.
Подверженные греху языки
Эта проблема не связана ни с каким конкретным языком.
Как происходит грехопадение
На первый взгляд, практичность – это отнюдь не высшая математика. Каждый из нас является пользователем, и каждый более или менее понимает, что удобно, а что нет. Но иногда за деревьями не видно леса. Разработчики программ часто полагают, что то, что кажется удобным им, будет удобно и всем остальным. Первый принцип создания удобных и безопасных систем гласит: «Проектировщики – не пользователи». О том, как применять его на практике, мы поговорим в разделе «Искупление греха».
Кроме того, до разработчиков часто не доходят претензии пользователей. Возьмем, к примеру, Web–приложение, которое запрашивает ввод имени и пароля при каждом входе. Это безопаснее, чем организовывать какое–то управление паролями и запоминать пользователя. Однако пользователи могут счесть такую систему неудобной и поискать приложение, автор которого не так трепетно относился к безопасности. Таким образом, второй принцип создания удобных и безопасных систем утверждает: «Безопасность (почти) никогда не стоит у пользователей на первом месте». Да, конечно, любой человек будет говорить, что ему очень нужна безопасная программа, но забудет свои слова в тот самый момент, когда стремление обеспечить безопасность начнет мешать ему работать. Есть также еще один феномен: люди «прощелкивают» диалоговые окна, в которых речь идет о безопасности, даже не читая, в стремлении поскорее добраться до необходимой функциональности.
Итак, безопасность для пользователя – не главное. Значит, если приложение не является безопасным по умолчанию, то пользователь и не поинтересуется, как сделать его таковым. Даже если для этого нужно всего лишь щелкнуть переключателем, он не станет утруждать себя. Поэтому не думайте, что вы сможете научить кого–то безопасному поведению с помощью руководства или сообщений, выдаваемых приложением. Конечно, очень соблазнительно переложить ответственность на пользователей, но мир от этого безопаснее не станет. Запомните: администраторы не склонны изменять настройки на более безопасные, а обычные пользователи представления не имеют, как это сделать.