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

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

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

Любой язык подвержен этому греху.

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

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

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

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

Часто из человека можно вытянуть пароль под каким–нибудь простым предлогом, например представившись репортером, который пишет статью о паролях. В случае атаки «заманиванием» (phishing) противник рассылает электронные письма, убеждая людей зайти от своего имени на указанный сайт, который выглядит вполне прилично, но его единственной целью служит собирание имен и паролей. Это пример социальной инженерии, не основанной наличном контакте.

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

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

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

Пароль можно перехватить и в других местах. В зависимости от используемого протокола противник может подключиться к проводной линии. Или перехватить пароль на стороне сервера: либо в момент копирования из сети в память, либо уже после сохранения на сервере. Иногда пароли записываются в файлы–протоколы, особенно если пользователь неправильно вводит имя.

Чтобы избежать перехвата паролей на сервере, рекомендуется не хранить их в открытом виде ни в файлах, ни в базе данных. Это имеет смысл, потому что у типичного пользователя нет никаких причин доверять людям, имеющим физический доступ к серверу, в частности системным администраторам. К сожалению, что–то, связанное с паролем, хранить так или иначе приходится. Например, это может быть односторонняя свертка пароля, с помощью которой проверяется, что пользователь действительно знает пароль. Любые данные, хранящиеся на сервере с целью удостовериться в том, что пользователь знает пароль, мы будем называть валидатором. Противник, заполучивший такой валидатор, может воспользоваться компьютером, чтобы подобрать пароль. Он просто перебирает различные пароли и смотрит, соответствует ли им данный валидатор (такую атаку обычно называют офлайновым полным перебором или атакой грубой силой). Иногда задача упрощается, особенно в случае, когда одинаковые пароли всегда дают одинаковые валидаторы. Существует общий прием, называемый «затравливанием» (salting), смысл которого в том, что сопоставить одному паролю разные валидаторы.