RFC: 2196
Оригинал: Site Security Handbook
Предыдущие версии: RFC 1244
Категория: Информационный
Дата публикации:
Автор:
Перевод: Семенов Юрий Алексеевич

4.1.4. Надежность пароля

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

  • Важность надежных паролей
  • Во многих (если не во всех) случаях проникновения в систему, атакеру нужно получить доступ к аккаунту системы. Единственным способом выполнить это является подбор пароля легального пользователя. Это часто осуществляется с помощью автоматической программы вскрытия паролей, которая использует очень большой словарь. Единственной защитой от вскрытия пароля таким способом является тщательный выбор пароля, который трудно подобрать (т.e., комбинации чисел, букв и знаков препинания). Пароли должны быть настолько длинны, насколько способна поддержать система и могут выдержать пользователи.
  • Изменение паролей по умолчанию
  • Многие операционные системы и прикладные программы устанавливаются с паролями и аккаунтами по умолчанию. Они должны быть изменены немедленно на что-то трудно угадываемое.
  • Ограничение доступа к файлу паролей
  • В частности, узел хочет защитить часть файла с шифрованными паролями так, чтобы атакер не имел туда доступа. Эффективной методикой является использование теневых паролей, где поле паролей стандартного файла содержит пустышки или фальшивые пароли. Файл, содержащий легальные пароли, защищен и находится где-то в другом месте.
  • Старение паролей
  • Когда и как завершается действие пароля является предметом дискуссии среди специалистов в области безопасности. Считается общепринятым, что пароль прекращает работать, когда аккаунт выходит из употребления, но активно обсуждается, следует ли вынуждать пользователя менять хороший пароль, который активно используется. Аргументы в пользу изменения пароля относятся к предотвращению использования вскрытого аккаунта. Однако оппоненты возражают, что частая смена паролей заставляет пользователей записывать их в легко доступных местах (например, непосредственно на терминале), или выбирать очень простые пароли, которые легко угадать. Следует заметить, что атакер использует, вероятно, вскрытый пароль скорее рано, чем поздно, с учетом этого замена старого пароля предоставит несущественную защиту.

    В то время как нет определенного ответа на эту дилемму, политика паролей должна непосредственно определять это и задавать то, как часто пользователь должен менять пароль. Конечно, ежегодная замена паролей обычно не составляет труда для пользователей, и нам следует рассмотреть такого рода требование. Рекомендуется, чтобы пароли менялись, по крайней мере, всякий раз, когда скомпрометирован привилегированный аккаунт, произошло критическое изменение персонала (особенно, если это администратор!), или когда аккаунт скомпрометирован.

  • Блокировка пароля/аккаунта
  • Некоторые узлы считают полезным аннулировать аккаунт, после заданного числа неудачных попыток аутентификации. Если ваш узел решает использовать этот механизм, рекомендуется, чтобы механизм не "раскрывал" себя. При неудачной аутентификации даже при вводе правильного пароля сообщение должно уведомлять лишь о неудаче, не раскрывая ее причины. Реализация этого механизма потребует, чтобы легальные пользователи связались со своим системным администратором для реактивации аккаунта.
  • Немного о демоне finger
  • По умолчанию, демон finger предоставляет достаточно большой объем системной и пользовательской информации. Например, он может отобразить список всех пользователей, использующих в данное время систему, или все содержимое специального файла пользователя (plan file). Эта информация может использоваться атакером для идентификации имени пользователя и угадывания его пароля. Рекомендуется, чтобы узлы модифицировали finger, чтобы ограничить выдаваемую информацию.
2007 - 2017 © Русские переводы RFC, IETF, ISOC.