Недостатки методов, предусматривающих регламентацию срока действия пароля

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

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

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

Во-вторых, что еще более важно, пользователи просто не желают придумывать новые пароли и запоминать их. Практика показывает, что на предприятиях, использующих пароли с 30-суточным истечением срока действия, больше чем 90% пользователей сменяют свои пароли на чрезвычайно предсказуемую (и поэтому легко раскрываемую) комбинацию слов или слов/чисел. Эта тенденция часто развивается до такой степени, что приблизительно 50% пользователей задают одинаковые пароли, например, сообщив друг другу, насколько легко можно ввести комбинацию букв и цифр в формате МММГГ, где МММ- месяц, а ГГ- год. Например, задавая пароль на январь 1996 года, такие пользователи вводили в качестве пароля алфавитно-цифровую комбинацию JAN96. Очень скоро почти все сотрудники предприятия начинают действовать подобным образом.

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

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

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

денными паролями, но не задавайте этот срок слишком непродолжительным, поскольку иначе пользователи возмутятся и начнут использовать слабые пароли. Сам автор предлагает менять пароли не чаще, чем через 90 суток, и не реже, чем через 180 суток.

Длина и состав пароля

к счастью, сфера применения программного обеспечения SQL Server распространилась и на эту область. В предыдущих версиях SQL Server даже при использовании средств безопасности SQL Server невозможно было обеспечить достаточно приемлемый контроль над длиной и составом паролей. А в последней версии SQL Server предусмотрена возможность предписывать правила парольной защиты Windows (а эти правила можно уточнять, используя утилиты Windows).

Длина пароля

Степень защищенности пароля весьма значительно изменяется в зависимости от его длины. Достаточно отметить, что с добавлением к паролю каждого возможного алфавитно-цифрового знака пользователем количество возможных паролей увеличивается по меньшей мере в 36 раз (в действительности, учитывая то, что в пароле разрешается также использовать некоторые специальные символы, такое увеличение еще значительнее, но даже увеличение в 36 раз весьма впечатляет). Иными словами, количество паролей, состоящих из одного алфавитно-цифрового знака, равно 36, а при увеличении длины пароля до двух знаков количество паролей возрастает до 1296. После добавления еще одного знака пароли становятся трехзначными, и их количество увеличивается до 46 656. А добавление четвертого знака приводит к тому, что количеств во паролей превышает миллион. По мере добавления все новых и новых знаков указанная тенденция становится все более ярко выраженной. Но в связи с этим возрастают сложности, поскольку для пользователей становится все более затруднительной задача запоминания паролей, а также подготовка новых паролей. Автор подозревает, что попытка заставить пользователей придумывать и применять пароли, состоящие больше чем из 5 или 6 знаков, приведет к тому, что они поднимут настоящее восстание.

Состав пароля

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

Реализуя правила парольной защиты, отличные от тех, которые применяются по умолчанию в операционной системе Windows, обязательно предусмотрите требование, согласно которому в пароле должен быть хотя бы один алфавитный символ и один цифровой. Это позволяет исключить возможность использования несложных чисел, которые легко угадать (например, многие вводят в качестве паролей номера своих карточек социального обеспечения, номера телефонов и даже даты рождения), а также всех слов из повседневного словаря. Благодаря этому пользователь все еще имеет возможность создать легко запоминающийся пароль, скажем, VVpizzas, но этот пароль нельзя найти по словарю. В таком случае любому взломщику придется опробовать каждую комбинацию символов, чтобы подобрать пароль и проникнуть в систему.

Количество попыток регистрации

Независимо от того, в каком месте физически хранится информация о пользователях и паролях, в окне регистрации необходимо реализовать требование, согласно которому количество попыток регистрации, предпринимаемьгх пользователем, должно быть ограниченным. Будет ли реакция на то, что пользователь исчерпал допустимое количество попыток регистрации, достаточно мягкой или очень жесткой, не столь важно по сравнению с тем, что должен быть предусмотрен механизм, позволяющий предотвратить под1Слючение к окну регистрации какой-либо процедуры, с помощью которой можно было бы проверить все возможные пароли программным путем.

Допустимое количество попыток регистрации также не имеет большого значения, при условии, что это количество не слишком велико; сам автор обычно разрешает использовать три попытки, но на практике иногда допускается применение четырех-пяти попыток, что также является вполне приемлемым.

Если используются средства принудительного введения в действие правил парольной защиты Windows, то в СУБД SQL Server проверяется количество попыток регистрации с неправильным паролем на основе этих правил.

Хранение информации о пользователях и паролях

Настоящий раздел представляет интерес в основном для тех разработчиков, которые пытаются создать собственную систему безопасности, отказавшись от встроенных систем безопасности Windows и (или) SQL Server (но такая мера является вынужденной применительно ко многим приложениям для Web), причем чаще всего задача хранения информации о профилях пользователей и паролях не является слишком сложной. Тем не менее при этом необходимо учитывать некоторые перечисленные ниже требования.

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

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

Воспользоваться новыми технологиями шифрования SQL Server для шифрования и расшифровки данных учетных записей, хранящихся в базе данных.

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

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