Пароль? Какой пароль?

На первый взгляд самое простое — это создать свою собственную систему хранения паролей. Но тут есть одно «но»: откуда мне знать, что мой пароль будет храниться у вас надлежащим образом? Точнее — не будет храниться в открытом виде и не будет перехвачен в процессе работы?

Полбеды, если кличку вашей любимой кошечки, которую вы используете в качестве пароля, узнает порядочный во всех отношениях администратор сайта. Куда хуже, если контрольная пара — адрес электронной почты и пароль — попадет в руки к злоумышленнику, особенно в случае если эта «пара» у вас едина для всех сайтов.

Так что давайте разбираться.

Прежде всего запомните сами и скажите об этом своему программисту: пароли не должны храниться в открытом виде, только в хэше! Что такое хэш? Это специальный алгоритм шифрования данных, результатом которого является длинная строка, состоящая из «нечитаемых» букв и цифр разного регистра. Пример: gJkd8trkPls.... и далее еще пару десятков «крокозябликов».

Обычно хэш получают путем шифрования парольной пары (адрес электронной почты + пароль): если хэш введенных пользователем данных совпадает с эталоном, хранящимся в базе, то доступ разрешается, нет — соответственно.

Конечно, даже зашифрованные данные можно подобрать. Но они не столь очевидны, как если бы жулик узнал, что ваш пароль «nezabudka».

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

Для доступа к закрытой части сайта используйте SSL – шифрованный канал для передачи данных между клиентом и сайтом: даже если трафик и будет перехвачен, то толка от него немного; дешифрование занимает слишком много времени, а потому бессмысленно. Для использования SSL необходимо получить специальный сертификат, установить его, после чего все данные передавать из защищенной зоны сайта: отличить ее от обычной можно по адресной строке. Начинается с https://? Отлично, еще одной проблемой меньше.

Прекрасная альтернатива фокусам с паролями — использование протоколов OAuth или OpenID, а если понятным языком, то авторизации через социальные сети. Принцип прост: нажав на вашем сайте кнопку «войти через фейсбук» клиент перенаправляется на сайт соцсети, где ему предлагается подтвердить это действие. Если все ОК, то сайт получает ответ «такой человек действительно существует» и довеском — список запрашиваемых параметров. Как правило это email, имя и ссылка на профиль пользователя. Никаких паролей!

Этот способ прекрасен тем, что клиенту не приходится запоминать тучу паролей, да и доверяет он свой пароль только одному, давно проверенному сервису, - своей соцсети. У сайта, использующего такой способ авторизации, тоже свои плюсы: клиент заведомо «настоящий», то есть уже проверенный соцсетью, а значит получаемые данные, прежде всего email, являются действующими.

Подобный сервис предлагают практически все социальные сети и крупные сетевые службы: facebook, google, microsoft, vkontakte, mail.ru, yandex, ok.ru и ряд других. Что делает использование данного способа верификации еще более желанным, ведь подобным образом можно реализовать не только авторизацию, но и регистрацию новых пользователей.

Все вышесказанное было нами лично опробовано и реализовано в новой версии www.minuvalik.ee: мы очень дотошно подошли к вопросу безопасности и упрощения верификации пользователей. Как следствие — менее чем за месяц получили прирост пользовательской базы почти на тысячу человек: рискну предположить, что многими двигало банальное любопытство — аутентификации через соцсети, которые у нас представлены во всех мыслимых вариациях.

В то же время в Эстонии, особенно в госучреждениях и банках, больше практикуется авторизация через ID-карту, а в последнее время и MobileID. Никаких особых секретов и тайн тут нет: пройдя процедуру верификации (технически реализуется за пару минут) сайт получает персональный код человека, который сравнивается с данными, хранящимися в локальной базе. Если совпадение найдено — разрешается доступ к ресурсу; все как и с парольными парами.

У этого способа куча своих плюсов, но есть и минусы: ничего кроме метрики (имя, фамилия, персональный код) сайт на такой запрос не получает. То есть, ни email, ни телефон получить нельзя: клиент как бы есть, но в то же время его и нет, - ни написать ему, ни позвонить.

Поэтому аутентификацию через ID карту разумнее использовать тогда, когда вы изначально занесли человека в свою базу, заведомо указав его персональный код. В противном случае толка от такой авторизации немного. Кроме, собственно, сверки персонального кода клиента.

Есть вопросы? Спрашивайте: [email protected]