OMX Baltic−0,36%290,31
OMX Riga0,05%926,08
OMX Tallinn−0,27%1 907,64
OMX Vilnius−0,02%1 271,86
S&P 500−0,05%6 734,11
DOW 30−0,65%47 147,48
Nasdaq 0,13%22 900,59
FTSE 100−1,11%9 698,37
Nikkei 225−1,77%50 376,53
CMC Crypto 2000,00%0,00
USD/EUR0,00%0,86
GBP/EUR0,00%1,13
EUR/RUB0,00%94,02

OMX Baltic−0,36%290,31
OMX Riga0,05%926,08
OMX Tallinn−0,27%1 907,64
OMX Vilnius−0,02%1 271,86
S&P 500−0,05%6 734,11
DOW 30−0,65%47 147,48
Nasdaq 0,13%22 900,59
FTSE 100−1,11%9 698,37
Nikkei 225−1,77%50 376,53
CMC Crypto 2000,00%0,00
USD/EUR0,00%0,86
GBP/EUR0,00%1,13
EUR/RUB0,00%94,02

13.04.15, 10:54

Внимание! Этой статье более 5 лет, и она находится в цифировом архиве издания. Издание не обновляет и не модифицирует архивированный контент, поэтому может иметь смысл ознакомиться с более поздними источниками.

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

Однажды вы обязательно столкнетесь с проблемой авторизации пользователей на своем сайте. Если он у вас есть, конечно. Для нужд «самообслуживания», обратной связи, покупок, комментариев и так далее. Но как сделать так, чтобы ваш пароль не попал в руки злоумышленников?

Андрей Касьяненко
Foto: ДВ Передовица

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

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

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

Статья продолжается после рекламы

Не храните пароли в открытом виде

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

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

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

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

Используйте SSL

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

Авторизация через социальные сети

Горячие новости

13.11.25, 11:28

Быстрые изменения в торговых центрах Нарвы: три арендатора уходят, четыре приходят

12.11.25, 14:45

Выкупленная эстонцем ИТ-компания за считанные дни перешла к новому владельцу

12.11.25, 18:03

Отказ от трамвая на улице Лийвалайя может оставить Таллинн и без ветки в Пельгуранна

13.11.25, 15:01

Думаете о расширении производства? Нарва готова вас принять

Статья продолжается после рекламы

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

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

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

Личный опыт

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

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

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

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

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

Андрей Касьяненко