Хранение зашифрованных данных

Если у вас нет веской причины поступать иначе, храните зашифрованные данные в конфигурационных файлах приложения или в реестре Windows. Основные преимущества этих вариантов — возможность защиты данных с помощью ACL-списков и легкость программного доступа.

Любой другой тип хранилища данных скорее всего не будет обладать хотя бы одним из этих преимуществ, и, хотя он может дать другие преимущества, маловероятно, что они оправдают дополнительные усилия по реализации.

Некоторые разработчики настаивают, что приложения Microsoft.NET Framework не должны использовать реестр, но это не закон. Главный недостаток реестра в том, что он не вполне подходит для развертывания приложения через XCOPY, однако, поскольку многие современные приложения развертываются с помощью программ установки и требуют выполнения определенных этапов конфигурирования в тех системах, куда они устанавливаются, совместимость с ХСОРУ может оказаться необязательной. Другой минус реестра в его специфичности для Windows-платформ — этот подход не сработает в других операционных системах. Впрочем, это

ограничение станет серьезной проблемой, только когда и другие платформы станут поддерживать общеязыковую реализацию (common language implementation, СLI).

Если вас интересует развертывание через XCOPY или взаимодействие с платформами, отличными от Windows, используйте конфигурационные файлы; нет — выберите вариант, наиболее подходящий вашим потребностям. Если нужно хранить параметры, совместно используемые несколькими приложениями, или определять эти параметрыпрограммно, реестр может оказаться более удобным в работе. Параметры, специфичные для приложения, которые не изменяются программно, могут храниться в конфигурационных файлах. В любом случае не забудьте применить соответствующие ACL к хранилищу данных. Например, неплохо было бы назначить право доступа для чтения к файлу или разделу реестра, содержащему секретные данные, учетной записи пользователя, под которой выполняется приложение. Также следует явным образом присвоить право доступа для записи пользователю или группе пользователей (например Administrators), которым разрешено модифицировать данные. Остальным следует запретить любой доступ.

Необратимое и обратимое шифрование

Существуют два метода шифрования данных: необратимое (one-way) (обычно называемое хэшированием) и обратимое (two-way). Технически хэширование — это не шифрование, но поскольку обе технологии при защите данных могут применяться сходным образом, т. е. преобразовывать данные из открытого текста в шифрованный, я буду считать их логически связанными.

Хэширование, служащее и для других целей, в области защиты данных дает определенные преимущества по сравнению с обратимым шифрованием.

Во-первых, хэширование чуть легче в использовании. Во-вторых, поскольку в хэшировании нет шифровальных ключей, оно устраняет проблему управления ключами, о которой будет рассказано ниже. Основной недостаток хэширования в том, что оно не поддерживает расшифровку, но в некоторых случаях эта проблема может обернуться благом.

Аутентификация на основе паролей — типичный случай, в котором хэширование более приемлемо чем обратимое шифрование. Если ваше приложение хранит пароли только в целях аутентификации, не зашифровывайте их симметричным или открытым ключом — храните вместо этого их хэшированные значения. При регистрации пользователя на входе вместо расшифровки и сравнения паролей в открытом виде приложение может сравнивать хэши паролей. Чтобы уменьшить риск атаки по словарю (dictionary attack), всегда используйте в хэшах ≪расширяющие≫ значения (salt values). ≪Расширение≫ — это случайные данные, добавляемые к открытому тексту до того, как он будет хэширован, и сохраняемые вместе с хэшем для последующего использования при сравнении другого открытого текста схэшем. Пример использования хэша с ≪расширением≫ для аутентификации на основе паролей см. в рубрике ≪Безопасный код≫ за август 2003 г, (http://msdn.micTosoft.com/msdnmag/issues/03/08/

SecurityBriefs/default.aspx).

Алгоритмы хэширования

Самые популярные алгоритмы хэширования — MD5 и SHA-1. Длина хэшей SHA-1 равна 160 битам, а длина хэшей MD5 — 128, Алгоритм SHA-1 чуть медленнее, но обеспечивает более высокую защиту, чем MD5. В дополнение к MD5 и SHA-1 NET Framework предлагает поддержку 256-, 384- и 512-битных версий алгоритма SHA, что еще надежнее, но, вероятно, и медленнее.

Простейший способ хэшировать данные — вызвать метод HashPasswordForStoringlnConfigFile класса FormsAuthentication, как в следующем примере:

using System.Web.Security;

 

string base64Hasn\'alue =

FormsAuthentlcatlon.HashPasswordForStoringlnConfigFileC'mypassword",

"shaT);

К сожалению, этот метод поддерживает только алгоритмы хэширования MD5 и SHA-1, так что, если вы хотите использовать хэши SHA-256, SHA-384 или SHA-512, вам придется писать чуть больше кода. Пример по ссылке http;//www.obviex.com/samples/hash,aspx поясняет, как создавать и сравнивать хэши с применением различных алгоритмов хэширования.

Шифровальные ключи

Если вашему приложению необходимо знать текстовые значения секретных данных, вы не сможете применить хэширование. В таком случае используйте обратимое шифрование с симметричным ключом или с парой

из открытого и закрытого ключей. Если вы не уверены, какой тип ключей выбрать, используйте симметричные ключи. Основной недостаток шифрования с открытым ключом — низкая производительность, которая может быть в 1000 раз меньше, чем при шифровании с симметричным ключом. Шифрование с открытым ключом также накладывает некоторые ограничения на размер текстовых данных, которые могут быть зашифрованы.

Хотя шифрование с открытым ключом можно использовать для защиты данных, практически все, что вы пожелаете сделать при помощи открытых ключей, можно выполнить с использованием других технологий. Поскольку открытые ключи лучше всего подходят для безопасного обмена ключами и цифрового подписания данных, я сосредоточусь на шифровании с симметричным ключом.

При выборе алгоритма шифрования имеет смысл выбрать самый надежный алгоритм с максимально длинным ключом. Самым надежным среди всех алгоритмов с симметричным ключом, поддерживаемых.NET Framework, считается одобренный правительством США алгоритм Rijndael (также известный как алгоритм Advanced Encryption Standard, или AES). Этот алгоритм поддерживает 128-, 192- и 256-битные ключи. Более подробную информацию о Rijndael см. в статье Джеймса Мак-Каффри в этом номере.

Алгоритм Rijndael обладает еще одним преимуществом по сравнению с другими алгоритмами с симметричным ключом, поддерживаемыми.NET Framework. Тогда как другие алгоритмы предлагаются в форме ≪тонких≫ классов-оболочек.NET Framework над имеющимися модулями CryptoAPI, Rijndael (реализованный как класс RijndaelManaged) написан полностью в управляемом коде. Замечу, что некоторые разработчики считают это недостатком и предпочитают использовать неуправляемую реализацию алгоритма Rijndael для большей производительности.

К сожалению, эта реализация алгоритма Rijndael поддерживается только в Windows XP и выше, а также в системах, где установлена.NET Framework. Если ваше приложение должно быть совместимо с неуправляемыми программами, работающими под Windows 2000 или ниже, используйте Triple DES — улучшенную версию менее защищенного алгоритма DES. Алгоритм Triple DES поддерживает ключи длиной в 112 и 168 бит, но рекомендуется использовать 168-битные ключи. Из-за разной трактовки битов четности (parity bits) ключа 168-битные ключи Triple DES иногда называют 192-битными. Если вы хотите предоставить управляемым и неуправляемым приложениям возможность зашифровывать или расшифровывать данные одинаковым ключом Triple DES, учтите, что кодовая фраза (или пароль), из которого формируется ключ, должна

содержать только печатаемые ASCII-символы; иначе сгенерированные

ключи не совпадут (вследствие ограничений.NET-реализации алгоритма Triple DES). Оригинальные алгоритмы DES, RC2 и RC4 в целом считаются менее стойкими, чем Rijndael и Triple DES, поэтому их следует избегать. Ни при каких обстоятельствах не используйте доморощенный алгоритм шифрования. Не воображайте, что никто не сумеет его взломать.

На рис. 6 показаны различные схемы шифрования данных, которые вы можете задействовать.