Личная передача
Наиболее банальный способ передачи информации о входе – личная форма. Данные всегда можно было бы передавать при встрече, но при распределенной структуре предприятия (или клиентской базе, разбросанной по районам города) разъезды только ради сообщения 20 – 30 символов, - слишком накладное мероприятие. Впрочем, обратный вариант, т.е. попытка заставить пользователя лично приходить за получением данных учетной записи, также не всегда работоспособен, поскольку он вовсе не повышает лояльность клиентов.
Однако личная передача информации в любом случае остается наиболее защищенным методом. Поэтому отношение к связанным с ней неудобствам в значительной степени зависит от конкретной задачи. К примеру, в распределенной филиальной сети крупной компании может оказаться так, что ИТ-сотрудник присутствует в каждом офисе. В этом случае легко организовать защищенную передачу данных сотруднику (используя, к примеру, ассиметричное шифрование), чтобы он лично передал их пользователю. При такой схеме личная передача уже не выглядит столь неудобной.
Устная передача по телефону
Еще один достаточно простой способ – передача голосом по телефону. К сожалению, для этого способа характерна высокая вероятность возникновения ошибок, упирающихся в пресловутый человеческий фактор (не так услышали, неправильно записали услышанное). Кроме того, телефонную связь (особенно, если речь идет о стационарной телефонии) достаточно легко прослушать.
Но главная проблема даже не в этом, а в том, что по телефону пользователя тоже надо как-то авторизовать. Банки для телефонного обслуживания используют кодовые слова, заранее известные паспортные данные и десятки других характеристик (вплоть до того, что при активации кредитных карт могут начать заново спрашивать анкетные данные о предыдущих работодателях и смене фамилий). ИТ-службе вся эта информация недоступна изначально, и вряд ли кто-либо согласится ее открыть, основываясь только на заявлениях о критически-важном вопросе безопасности.
Смена пароля при первом входе
Простейший способ защиты пользовательских данных при «электронной» форме передачи – отправка ему данных для входа любым доступным методом с последующей обязательной сменой пароля при первом же обращении к системе.
Установка разового пароля, как совершенно верно отметил один из участников дискуссии, действительно решает массу проблем. Однако, как самостоятельный вид передачи (не задействующий дополнительные инструменты авторизации), такой способ не может гарантировать, что пароль получил именно тот клиент. Быть может, его почтовый ящик давно взломан, и учетные данные ушли злоумышленнику. Или же ящик давно не используется (т.е., фактически, данные для входа в систему канут «в никуда» и будут ждать своего часа, как «бомба замедленного действия», пока, к примеру, клиента не сломают).
Несколько улучшает ситуацию практика ограничения срока действия временного пароля. Когда срок этот ограничен 24 часами, даже если пароль ушел на неиспользуемый ящик, уже через сутки этот факт не будет иметь никакого значения. Срок можно установить и меньше. В этом случае, правда, передачу первоначального пароля, как высказывались участники беседы, проще осуществлять по телефону. Прямо в режиме реального времени пользователю создается учетная запись с временным паролем, пароль передается голосом по телефону (не заботясь о его сохранности), пользователь тут же входит в систему и устанавливает более безопасный пароль, известный только ему. Со своей стороны ИТ-отделу остается только проверить, что операция смены пароля действительно произошла.
Использование двух факторов для авторизации
В системах, для которых критичным является уровень безопасности, распространена методика использования нескольких независимых факторов для подтверждения личности клиента (обращающегося по любому каналу связи). В простейшем варианте это может быть электронная почта и сотовый телефон. При этом пароль передается по электронной почте, а через SMS осуществляется подтверждение входа в систему или передача пароля к зашифрованному сообщению по почте.
Хотя вариант часто вызывает скепсис (пользователю свою голову не приставишь – и не объяснишь, что с расшифрованным сообщением надо обращаться соответственным образом), можно придумать достаточно безопасную схему. В конце концов, те же банки считают такой вариант авторизации во многих случаях оптимальным для платежей в сегменте B2C.
К сожалению, не всегда корпоративные правила допускают использование таких личных атрибутов (как номер сотового сотрудника) для авторизации. Т.е. иногда подобный подход невозможен из-за внутренних ограничений.
Аппаратная защита
Вариант, применяющийся в единичных компаниях, но обеспечивающий более четкую привязку человека к его паролю – аппаратные токены. Правда, выдача любых инструментов аппаратной защиты должна быть прописана политикой не только ИТ-отдела, но и всего предприятия: токен необходимо передавать человеку уже при приеме на работу, одновременно отправляя его данные в ИТ-отдел, и забирать во время увольнения.
Стоит отметить, что выбор методики зависит не только от предпочтений ИТ-шников. Важную роль здесь играют требования клиента по безопасности решения.