Парольные системы уязвимы для самых разных атак. Во–первых, противник может войти в систему под учетной записью, которая ему не принадлежит и пользоваться которой он не имеет права. При этом совершенно необязательно, что пароль был скомпрометирован. Например, перехватив и затем воспроизведя трафик, можно обойти протокол проверки пароля и войти в систему, вообще не зная пароля, а просто послав копию чьих–то зашифрованных данных.
Во–вторых, надо иметь в виду, что противник может узнать чужой пароль. Это опасно не только потому, что он сможет войти от имени чьей–то учетной записи, но и потому, что этот пароль может использоваться для доступа в разные системы. По крайней мере, узнав один пароль пользователя, будет проще догадаться о других его паролях.
Существует множество простых способов обойти парольную защиту. Самый легкий из них вообще не связан с техникой, это социальная инженерия, когда противник обманом убеждает пойти навстречу своим неблаговидным намерениям. (Зачастую для этого необходимо иметь навыки общения, одной лжи может оказаться недостаточно.)
Одна из распространенных атак методом социальной инженерии заключается в том, чтобы позвонить в отдел поддержки клиентов, притвориться пользователем X и сказать, что забыл собственный пароль. Успеху весьма способствует знание персональной информации о жертве, тогда шансы получить новый пароль заметно возрастают.
Часто из человека можно вытянуть пароль под каким–нибудь простым предлогом, например представившись репортером, который пишет статью о паролях. В случае атаки «заманиванием» (phishing) противник рассылает электронные письма, убеждая людей зайти от своего имени на указанный сайт, который выглядит вполне прилично, но его единственной целью служит собирание имен и паролей. Это пример социальной инженерии, не основанной наличном контакте.
Другая распространенная проблема, тоже не связанная с техническими деталями парольной защиты, – это оставление стандартных учетных записей с паролями по умолчанию. Часто пользователи не изменяют их, даже если в инструкции явно сказано, что это следует сделать.
Серьезная проблема состоит в том, что если человеку позволено самостоятельно выбирать пароль, то он, скорее всего, возьмет такой, который легко угадать. Если же это запретить или настоять на том, чтобы пароль был достаточно сложным, то возрастают шансы на то, что человек запишет пароль на бумажке и оставит ее на своем рабочем столе.
Есть и другие физические опасности, угрожающие паролям. Противник может установить программу, протоколирующую нажатия клавиш, или иным способом перехватить ввод пароля, например с помощью видеокамеры. Это особенно просто, если набираемый пароль отображается на экране.
Пароль можно перехватить и в других местах. В зависимости от используемого протокола противник может подключиться к проводной линии. Или перехватить пароль на стороне сервера: либо в момент копирования из сети в память, либо уже после сохранения на сервере. Иногда пароли записываются в файлы–протоколы, особенно если пользователь неправильно вводит имя.
Чтобы избежать перехвата паролей на сервере, рекомендуется не хранить их в открытом виде ни в файлах, ни в базе данных. Это имеет смысл, потому что у типичного пользователя нет никаких причин доверять людям, имеющим физический доступ к серверу, в частности системным администраторам. К сожалению, что–то, связанное с паролем, хранить так или иначе приходится. Например, это может быть односторонняя свертка пароля, с помощью которой проверяется, что пользователь действительно знает пароль. Любые данные, хранящиеся на сервере с целью удостовериться в том, что пользователь знает пароль, мы будем называть валидатором. Противник, заполучивший такой валидатор, может воспользоваться компьютером, чтобы подобрать пароль. Он просто перебирает различные пароли и смотрит, соответствует ли им данный валидатор (такую атаку обычно называют офлайновым полным перебором или атакой грубой силой). Иногда задача упрощается, особенно в случае, когда одинаковые пароли всегда дают одинаковые валидаторы. Существует общий прием, называемый «затравливанием» (salting), смысл которого в том, что сопоставить одному паролю разные валидаторы.
Существует также опасность перехвата пароля на стороне клиента, особенно если система дает возможность хранить пароли в браузере или другом локальном хранилище. Такая методика «однократной регистрации», конечно, удобна для пользователя, но создает дополнительные риски. Впрочем, большинство людей считают, что это приемлемый компромисс.
Опасности офлайновой атаки с полным перебором подвержены даже сети. Большинство протоколов аутентификации защищают данные криптографическими методами, но противник обычно может перехватить зашифрованный пароль и позже подвергнуть его атаке грубой силой. Иногда для этого достаточно простого подключения к проводу, а иногда приходится притворяться клиентом или сервером. Если протокол проверки пароля плохо спроектирован, то противник может перехватить данные клиента, воспроизвести их с другого компьютера и войти от имени другого пользователя, даже не зная настоящего пароля.
Разумеется, противник может попробовать и онлайновую атаку с перебором, когда он просто многократно пытается войти в систему, предлагая каждый раз новый пароль. Если пользователям разрешено выбирать слабые пароли, то такая стратегия может принести успех. Вы можете попробовать ограничить число попыток входа или применить другие средства обнаружения вторжений, но если в результате учетная запись блокируется, то возрастает риск отказа от обслуживания. Предположим, к примеру, что противнику понравилась какая–то вещь, выставленная на онлайновом аукционе, а торги заканчиваются утром. Если противник наблюдает за тем, кто еще повышает ставки, то где–то в середине ночи он может начать входить от имени каждого из своих конкурентов до тех пор, пока их записи не окажутся заблокированными. Тогда к утру ему уже не о чем волноваться, потому что основные конкуренты будут заняты попытками разблокировать свои учетные записи, а не торговлей, тем более что многие подобные сайты требуют высылать персональные данные по факсу.
Есть и еще один класс проблем, связанных с так называемым побочным каналом. В этом случае противник может получить информацию об именах и паролях пользователей, наблюдая, как система реагирует на попытки входа. Например, если хакер хочет войти в систему, но не знает ни одного имени пользователя, то он может попробовать несколько кандидатов. Если система говорит «неверное имя пользователя», но в случае ввода неправильного пароля выдает какое–то другое сообщение, то противник легко поймет, когда наткнется на существующее имя (после чего можно провести атаку с угадыванием пароля). В грехе 13 описан реальный пример такого рода ошибки в почтовом сервере IBM AS/400. Даже если в обоих случаях система выдает одно и то же сообщение, промежуток времени до его появления может меняться в зависимости от того, существует указанное имя или нет; в этом случае у хакера появляется еще один способ выявить существующие имена.
Родственные грехи
Проблемы паролей – это проблемы аутентификации, которые подробно рассмотрены в грехах 10,15 и 17. Многие проблемы можно сгладить за счет введения адекватных мер защиты сети (грех 8). В частности, если вы примените надежную схему аутентификации сервера и зашифруете канал (например, с помощью протоколов SSL или TLS, как описано в грехе 10), то шансы взломать пароли, когда они передаются по сети, резко падают.