Секреты и ложь. Безопасность данных в цифровом мире

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

Первая – это «вызов/ответ». Знак – устройство идентификации – карманный калькулятор с цифровой клавиатурой и маленьким экраном. Когда пользователь хочет подключиться, он вызывает удаленный хост. Он отправляет этот вызов со своего знака. Знак подготавливает соответствующий запрос, который передает в компьютер, а тот переправляет его хосту. Хост производит аналогичные вычисления и, если результат соответствует ожидаемому, подтверждает подлинность.

Вторая технология основана на временной синхронизации. Знаком является аналогичный карманный калькулятор с одним экраном. На экране регулярно сменяются номера, обычно раз в минуту. Удаленный компьютер просит пользователя напечатать то, что показано на экране. Если ответ пользователя соответствует тому, что ожидает удаленный компьютер, он производит подтверждение подлинности. Таким образом работает адаптер SecurID[29].

Конечно, полная система может также включать пароль, знак вызова/ответа, для начала работы может даже потребовать дополнительно ввода пароля; и другие вспомогательные меры безопасности. Основная идея все-таки в том, что некое секретное вычисление происходит внутри электронного ключа, который подменить нельзя. Нападающий не станет притворяться, будто у него есть знак, потому что не знает, как рассчитывать ответы, основанные на вызовах, или не знает, как рассчитывать величины, основанные на временной синхронизации. Сделать это можно только одним путем – имея настоящий знак.

Это работает в большей или меньшей степени. Шифровальные техники, кодирование или хэширование обеспечивают безопасность. Удаленный компьютер знает, как провести расчеты, так что система безопасна в такой же степени, что и ключевой код главного хоста. Любой, кто перепроектирует знак, сможет выяснить, как произвести расчеты; таким образом, система безопасна ровно настолько, что и знаки (см. главу 14). Но это достаточно хорошо и, конечно, намного лучше, чем «голые» пароли. Проблемы безопасности возникают в сети и при подтверждении подлинности компьютера.

Напоследок обсудим еще один знак: записанный пароль. В сообществе, занимающемся проблемами безопасности, существует реакция коленного рефлекса на запись паролей, но если это сделано должным образом, то может значительно улучшить защиту. Кто-нибудь, кто записывает свой пароль, превращает то, что он знает (свой пароль), в то, что он имеет (клочок бумаги). Эта уловка позволяет ему использовать более длинные пароли, которые являются более надежными. Здесь есть все проблемы простого знака: он может быть скопирован или украден. Защита не будет работать, если Алиса написала свой пароль на желтом липком листочке, наклеенном на монитор ее компьютера. Для нее будет лучше положить свой пароль в бумажник – это надежнее. Возможно, лучшим решением будет иметь две части пароля: одну будет помнить Алиса, а другая будет записана на листочке, лежащем в ее бумажнике.

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

Протоколы аутентификации

Протоколы аутентификации – это криптографические способы подтверждения подлинности личности Алисы через сеть. Основной протокол аутентификации достаточно прост.

1. Алиса набирает свое имя пользователя и пароль на компьютере-клиенте. Клиент отправляет эту информацию серверу.

2. Сервер ищет указанное имя пользователя в базе данных и отыскивает соответствующий пароль. Если он соответствует паролю, набранному Алисой, ей предоставляется доступ.

Проблема в том, что база данных паролей должна быть защищена. Решение в том, чтобы хранить не пароли, а хэш-функции паролей.

1. Алиса набирает свое имя пользователя и пароль на клиенте. Клиент отправляет эту информацию серверу.

2. Сервер хэширует набранный Алисой пароль.

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

Уже лучше. Главная проблема со вторым протоколом в том, что пароли открыто посланы по сети. Кто-нибудь, рыскающий по сети, может собирать имена пользователей и пароли. Решение включает в себя хэширование пароля перед тем, как отослать его (более старые версии Windows NT делают это), но словарные нападения в состоянии справиться и с этим.