что нужно сделать чтобы авторизоваться
Авторизация: что это такое и для чего нужно?
Несмотря на то, что интернетом пользуется огромное количество людей по всему миру, ежедневно многие пользователи только начинают познавать этот виртуальный мир. Пользователи часто сталкиваются с определениями, которые они прежде не слышали. Вот, к примеру, авторизация — что это такое?
Авторизация (от английского слова authorization, что можно перевести как «разрешение») — это предоставление прав пользователю или группе лиц на выполнение тех или иных действий. Не поняли? Допустим, вы прошли регистрацию в Яндекс.Почте. Для того, чтобы попасть в свой электронный почтовый ящик, вам необходимо пройти авторизацию, то есть в данном случае ввести логин и пароль, который вы указали при регистрации.
Вот как выглядит поле для ввода данных Яндекс.Почты:
Соответственно, как только вы введете логин и пароль, система распознает пользователя и предоставит доступ к почте, а кроме того, доступ к другим сервисам компании Яндекса.
Разумеется, с авторизацией вы можете встретиться и на многих других сайтах. Взять тот же Сбербанк Онлайн: чтобы попасть в личный кабинет, нужно ввести логин и пароль.
При этом в случае со Сбербанком Онлайн используется так называется двухфакторная авторизация: помимо ввода логина и пароля пользователю необходимо ввести дополнительный код, который приходит к нему на телефон в виде СМС-сообщения. Это сделано для дополнительной безопасности. Только после ввода кода можно войти в личный кабинет.
Авторизацию в социальных сетях вы наверняка прекрасно знаете. Вот пример на основе ВКонтакте:
Есть другой вид авторизации, тоже, кстати, в банковской сфере. Допустим, вы оплачиваете покупку в интернете. Лимит на покупку товаров без авторизации — 2000 рублей. Вы же покупаете товар за 3000 рублей. Без авторизации в этом случае вы не сможете оплатить товар: для этого обычно необходим либо пароль, который вы сами же создаете, либо код, который придет в сообщении на телефон.
Важно также отметить, что не во всех случаях пользователь сам может зарегистрироваться на сервисе и получить данные для авторизации. Есть такие сервисы, где регистрация возможна только в определенном учреждении, в котором пользователь получает данные для доступа (авторизации).
Что такое данные авторизации?
Обычно данными авторизации являются логин и пароль, но не всегда. Зачастую это может быть фамилия или имя пользователя, а также пароль. Бывает так, что пользователь знает только логин для входа в систему, а пароль приходит ему в СМС-сообщении.
Чаще всего пользователь сам вправе менять свои данные авторизации, однако логин в некоторых случаях изменить невозможно. Например, если говорить о почтовых сервисах, логин изменить не получится, а вот пароль — пожалуйста.
Какие плюсы у авторизации?
Это зависит от сервиса. Если брать те же банковские услуги, то большинство услуг пользователю доступны только после регистрации в сервисе и получении данных для авторизации.
Если говорить про обычные сайты, зачастую авторизация предлагает возможность получения большего количества функций. Кроме того, на тех же форумах нельзя общаться без авторизации. Кстати, сейчас можно использовать аккаунты социальных сетей для регистрации и последующей авторизации во многих сервисах. Это удобно, поскольку не требует дополнительных действий.
Уважаемые пользователи! Если наш сайт вам помог или что-то в нем не понравилось, будем рады, если вы оставите комментарий. Заранее большое спасибо.
Авторизация и регистрация: почему это две большие разницы
На смартфонах устанавливают приложения. И далее, не задумываясь, открывают их с помощью одного или двух тапов. Приложение готово к работе. Если же входить куда-либо через браузер на компьютере, ноутбуке или на смартфоне, то появляются две кнопки для входа пользователя: авторизация и регистрация. Какая между ними разница и почему их нельзя путать?
На некоторых сайтах, в электронной почте, в социальных сетях, в интернет банке, если их открыть через браузер на компьютере или смартфоне, обычно есть два варианта для входа. Первый вариант – это авторизация для «стареньких» пользователей, которые ранее прошли регистрацию. Второй вариант – это регистрация для «новеньких» людей, еще не зарегистрированных на данном ресурсе.
Что такое регистрация
Регистрация – это необходимый этап для того, чтобы пользователь получил доступ к тем возможностям, которые предоставляются на каком-либо интернет-ресурсе. Регистрацию проходят только один раз (в идеале). После того, как человек ее прошел, ему становятся доступны те возможности, которые имеются на данном ресурсе.
Как происходит регистрация? Когда пользователь первый раз где-либо регистрируется, то при этом, как правило, ему нужно придумать логин и пароль. Именно придумать, создать новый логин и к нему новый пароль.
В качестве логина может выступать либо адрес электронной почты, либо номер мобильного телефона, либо фамилия и имя, либо никнейм. Зачастую при регистрации есть важный момент: необходимо подтвердить свой Email, либо удостоверить свой номер смартфона.
Казалось бы, зачем такие сложности? Ведь для того, чтобы подтвердить свою почту, нужно ее открыть, найти там письмо для подтверждения или выполнить иные инструкции. На телефон в качестве подтверждения того факта, что номер принадлежит вам, приходит код для подтверждения, либо звонок-сброс, либо еще указание на какое-то необходимое действие.
Для чего все это, может, можно как-то попроще пройти регистрацию? Нет, потому что только таким образом можно доказать два необходимых факта. Во-первых, проверяется, что у вас есть доступ к почте или к телефону. Во-вторых, подтверждается, что вы правильно, без единой ошибки ввели адрес своей почты или номер своего мобильного.
Как подтвердить email-адрес или мобильный при регистрации
Допустим, при регистрации в качестве логина нужно ввести свой email-адрес. Как его подтвердить? Как уже отмечалось выше, нужно открыть свою почту и найти там письмо с того сайта, где вы проходите регистрацию. Письмо может прийти не сразу, а спустя несколько минут или более.
Кроме того, стоит проверить папку Спам в почте, письмо по ошибке могло попасть туда. Если же прошло достаточно времени, но письмо не удается найти, то, возможно, была допущена ошибка при вводе email. Стоит попробовать заново пройти регистрацию.
Если же письмо для подтверждения электронного адреса пришло, его нужно открыть и прочитать. Как правило, следует кликнуть по ссылке в этом письме. Этот клик по ссылке является доказательством того, что вы являетесь реальным пользователем почтового ящика.
Как быть, если при регистрации в качестве логина выступает номер смартфона? Как подтвердить мобильный? На телефон обычно приходит смс с кодом подтверждения или пуш-уведомление. При этом дается короткая и понятная инструкция, что необходимо сделать пользователю для подтверждения номера мобильного.
Для подтверждения номера мобильного иногда используется звонок-сброс. На него не нужно отвечать. Надо определить последние цифры в том номере, с которого звонят. Обычно следует ввести четыре последних цифры. Например, поступил звонок с номера +7 123 456 78 90. Тогда для подтверждения надо ввести код 7890.
Я рекомендую записать в блокнот, записную книжку и т.п. название сайта (приложения), логин и пароль, либо как-то иначе сохранить эти данные. Пароль чаще всего можно восстановить с помощью электронной почты или смартфона. Для этого на сайте может быть ссылка «Забыли пароль?».
А вот с логином сложнее, восстановить его в случае забывчивости удается далеко не всегда. В любом случае меньше стресса и потери времени будет, если есть возможность где-то у себя в записях найти свой логин и пароль.
Что означает повторная регистрация
Частенько бывает так, что пользователь либо забыл логин или пароль, либо не помнит и то, и другое вместе взятые. Также часто случается ситуация, когда человек уверен в том, что логин и пароль введены верно. Но при этом все равно появляется неприятная красная надпись: «Неверно введен логин или пароль».
В таких ситуациях стоит убедиться, что логин и пароль введены верно. О том, как можно это сделать, писала ЗДЕСЬ на примере соцсети Одноклассники. Описанные там приемы для проверки пароля или логина действуют для всех ситуаций.
Хороший выход в случае, когда забыт пароль, состоит в том, чтобы нажать на ссылку «Забыли пароль». Затем по предложенной инструкции можно попытаться восстановить пароль.
Однако некоторые пользователи не делают никаких попыток для восстановления прежних данных: логина или пароля. Они принимают решение о том, что нужно пройти новую регистрацию и проблема будет решена.
Проблема новой регистрации состоит в том, что пользователь становится «новеньким». Что это означает?
Помните, как в школе говорили, когда в класс приходил новый ученик: «У нас новенький (новенькая)!». При новой регистрации автоматически пропадут все накопленные ранее бонусы, баллы, подписки, купленные ранее билеты, курсы и прочие «плюшки», которые были «нажиты непосильным трудом». Придется начинать все по-новому, то есть, жизнь пойдет «с чистого листа». Придется опять зарабатывать карму, авторитет, бонусы, прочие преимущества старых клиентов сайта перед новыми.
Увы, при новой регистрации, как правило, уже нельзя восстановить те билеты, подписки, курсы, бонусы, баллы, которые хранились при прежней регистрации.
При новой регистрации вы автоматически становитесь «новеньким в интернет классе». Вероятно, это хорошо, если в «старом» классе были проблемы, карма была плохой и от нее необходимо избавляться. Но если все было хорошо, были заслуги в виде каких-то преимуществ (скидок, бонусов и прочего), то новая регистрация благополучно похоронит наработанные успехи и жизнь на сайте начнется все «с нуля».
Авторизация: вход после регистрации
Регистрацию проходят один раз. Потом для входа на какой-либо ресурс следует пользоваться кнопкой «Авторизация».
Авторизация на сайте или в приложении – это процесс, в котором ранее зарегистрированный пользователь вводит свой логин и пароль, чтобы система могла его опознать.
Слово «авторизация» произошло от английского authorization, что в переводе означает «авторизация», «полномочия», «разрешение».
Авторизация на каком-либо сайте (или интернет-ресурсе), по сути, означает «повторный вход» или «вход после регистрации». Если есть вход на сайт, то, вероятно, должен быть и выход. Но вот с выходом не все так однозначно, как со входом.
Выход: а что это такое
В современных приложениях на смартфоне сложно найти кнопку или значок для выхода, а зачастую это вообще невозможно. На компьютере обычно есть параметр «Выход», но многие пользователи никогда не используют эту возможность. Один раз зашли и больше никогда не выходят. Это хорошо, если техника всегда работает, никогда не подводит, либо не нужно заводить второй аккаунт на сайте.
Я думаю, что если есть возможность для выхода, то нужно этим пользоваться. Конечно, после выхода придется потом входить. То есть, нужно нажимать на кнопку «Авторизация», вводить логин и пароль.
Выход и последующий вход – это соблюдение безопасности в некотором роде, а также тренировка собственной памяти при вводе логина и пароля.
Рассмотрим примеры с кнопками для регистрации и авторизации для Яндекс.Почты, Yoomoney, РЖД, Ростелеком, Фейсбук, ВКонтакте. Приведенные примеры работают через браузер на компьютере или на смартфоне.
О приложениях на смартфоне здесь не упоминается. На телефоне устанавливается приложение, вводятся личные данные для регистрации или авторизации. И, как правило, на этом всё, потом уже не встречаются кнопки для регистрации или для авторизации.
Видео: Авторизация и регистрация, почему это две большие разницы
Яндекс Почта: Создать ID и Войти
В Яндекс.Почте кнопка «Создать ID» (цифра 1 на рис. 1) служит для регистрации нового почтового адреса (email). ID (читается «ай-ди») — это часть английского слова «identifier», что можно перевести как «идентификатор».
«Создать ID» означает, что нужно зарегистрировать, то есть создать новый логин и пароль для Яндекс.Почты. После того, как ID (логин и пароль) будет зарегистрирован, его можно использовать для того, чтобы пользоваться всей экосистемой Яндекса. Сервисов у Яндекса очень много, их количество постоянно пополняется.
Кнопка «Войти» (2 на рис. 1) предназначена для тех, кто уже один раз прошел регистрацию. В этом случае нужно ввести логин и пароль. После этого откроется почта с полученными письмами. Если же сделать новую почту с помощью «Создать ID», то там не будет тех писем, что были в старой почте.
Юмани: Создать кошелек и Войти
Юмани – это электронные деньги, которые ранее были Яндекс.Деньги. Потом сервис был приобретен Сбербанком и сменил название. Были Яндекс.Деньги, стали Юмани.
Кнопка «Создать кошелек» (цифра 1 на рисунке 2) означает появление нового кошелька, как правило, с нулевым балансом. Другая кнопка «Войти» (2 на рис. 3) позволяет войти в старый кошелек. Возможно, там уже есть рубли и накопленные баллы.
РЖД: Регистрация или Вход
РЖД является сокращением от «Российские Железные Дороги». Сайт РЖД предназначен для получения информации о поездах, расписании, наличии мест. Для приобретения билетов на поезд необходимо создать личный кабинет на сайте РЖД, он называется «Мои заказы».
Для создания личного кабинета РЖД, а также для входа в правом верхнем углу на сайте РЖД есть единая кнопка «Вход» (цифра 1 на рисунке 3). Кликнув по ней, появятся две вкладки «Вход» (3 на рис. 3) и «Регистрация» (2 на рис. 3).
Чтобы создать новый личный кабинет, следует нажать «Регистрация». В новом кабинете «Мои заказы» НЕ будет билетов, приобретенных ранее на сайте РЖД. После регистрации там можно будет только купить новый билет.
Для доступа к прежнему кабинету, надо использовать кнопку «Вход». Там можно найти билеты, приобретенные ранее на сайте РЖД, а также купить новые билеты.
Ростелеком личный кабинет: Зарегистрироваться и Войти
На сайте Ростелекома можно создать новый личный кабинет с помощью кнопки «Зарегистрироваться» (цифра 1 на рисунке 4). В личном кабинете можно проводить оплату, получать и тратить бонусы, писать запросы в техподдержку и т.д.
Если же личный кабинет уже был создан, следует ввести логин (или телефон, или почту, или лицевой счет) и пароль. После этого нажать на оранжевую кнопку «Войти».
Если создать новый кабинет вместо старого, то все баллы, бонусы и прочие плюшки, накопленные ранее, увы, пропадут.
Фейсбук: Создать аккаунт и Вход
Знакомый пенсионер активно осваивал Фейсбук. Он часто присылал повторные приглашения в друзья, потому что постоянно создавал новые аккаунты. На старый аккаунт он не мог попасть по разным причинам. Новая регистрация ему была нужна, потому что он никогда не записывал старый логин и пароль, не сохранял, не запоминал. Он уверен, что это для него лишняя, утомительная процедура.
При этом знакомый удивлялся, почему у него так мало друзей и почему в новом аккаунте все друзья пропадают. А как Фейсбук догадается, что тот или иной человек создал сразу несколько разных аккаунтов? Кстати, если Фейсбук догадается, то может предупредить о неправильных действиях, так как у одному человеку желательно иметь один единственный аккаунт.
Кнопка «Создать аккаунт» (цифра 1 на рисунке 5) предназначена для создания новой личной странички, где нет друзей, и все «с чистого листа». А кнопка «Войти» предназначена для входа на личную страничку, ранее уже зарегистрированную, и возможно, там уже есть друзья.
ВКонтакте: Регистрация и Войти
Чтобы создать новую страничку ВКонтакте, следует ввести имя, фамилию, указать дату рождения и нажать на зеленую кнопку «Продолжить регистрацию».
Для входа на свою страничку, ранее уже зарегистрированную, следует ввести телефон или email, пароль и нажать «Войти».
Надёжная авторизация для веб-сервиса за один вечер
Предыстория
Осень 2015-ого. Примерно полтора года назад, когда мне случилось стать участником разработки проекта, где пользователей существенно больше пары десятков человек, я наконец-то впервые в своей жизни задумался о надёжности авторизации.
По сути, авторизация — это то, с чего начинается процесс взаимодействия зарегистрированного пользователя с системой (для незарегистрированного пользователя всё начинается с регистрации, и эти два процесса, как вы уже догадались, очень сильно взаимосвязаны). Я внезапно осознал, что во всех проектах, что я делал до этого, с безопасностью всё очень плохо.
Достаточно рассмотреть простейший пример: кто-то подобрал пароль, или человек каким-то образом скомпрометировал его. Конечно, у нас в базе данных хранятся хэши с использованием соли, мы даже настолько продвинуты, что используем только HTTPS… Но это никак не спасёт нас от человеческого фактора.
Что делает в случае взлома грамотная система? Блокирует аккаунт (совсем хорошо — если автоматически, по ряду необычных признаков в поведении пользователя), в дальнейшем предлагая средства для восстановления: привязанный телефонный номер, контрольный вопрос, и т.д. Привязка сотового — отличная мера с крайне высокой надёжностью. К сожалению, у нашего проекта не было на это средств, поэтому приходилось обходиться без этого. Благо, блокировку можно реализовать, посадив человека на специальный почтовый ящик, или даже принимать экстренные звонки на сотовый.
И тут традиционный метод, который применяют многие начинающие разработчики (найденный в книгах, либо в статьях в интернете) даёт осечку. Дело в том, что этот метод предполагает хранение авторизации в сессиях. Это статья не относится к конкретному языку, и справедлива для любой платформы, но я буду иллюстрировать всё на примере PHP.
Стандартная реализация
Итак, сессия в PHP по умолчанию хранится в файле. Её id сохраняется в cookie (если куки отключены — задействуется механизм передачи через адресную строку, если это не отключено в конфигурации). Время жизни такой сессионной куки по умолчанию — до момента закрытия браузера (и обычно его никто не меняет). Поэтому более продвинутые программисты реализуют галочку «запомнить меня», либо реализуют её функционал по умолчанию, без возможности отключить. Что они делают? Просто сохраняют в собственной куке айди пользователя. Но поскольку просто айди хранить как-то уж слишком стрёмно (любой может поставить любое число и получить доступ к произвольному аккаунту), то часто вместе с айди за компанию сохраняют и пароль. В открытом виде.
Если кто-то не понимает, чем это плохо — представьте себе, что у нас пользователь пользуется очень старым, либо очень плохо реализованным браузером. Мы ведь не можем гарантировать, что браузер надёжно шифрует куки? Да и вирусы всякие могут быть у пользователя на компьютере, и в случае особо серьёзной малвари может не спасти и шифровка — зловред может попытаться считать значения прямо из памяти, когда они расшифрованы. Человек, случайно оказавшийся у вашего компьютера в ваше отсутствие — сможет просто скопировать себе все интересующие куки, и в новых браузерах этот процесс стал ещё проще. Дыры в безопасности браузера могут потенциально привести к тому, что ваша кука станет доступна стороннему сайту (да, сейчас это крайней маловероятно, но чем чёрт не шутит).
Ну и самое главное — если у нас SSL используется только при авторизации (а на остальных страницах его решили отключить ради выигрыша в скорости, либо чтобы лучше работало промежуточное кэширование)… То наш пароль всё время передаётся открытым текстом. При каждом запросе. А пароль меняют редко, то есть это некий токен, который имеет долгий срок жизни. А теперь представим себе, что наш трафик кто-то перехватил…
Как быть?
Очевидно, с этим надо что-то делать. Да, можно сразу бежать покупать сертификат и подключать SSL. Но можно сделать кое-что ещё до этого, и существенно снизить тем самым необходимость в нём. В конце концов, в том же ВКонтакте SSL стал принудительным всего полгода назад, а до этого как-то ведь жили.
Первое, что приходит на ум — хранить вместо пароля хэш от него. Это не особо поможет, если кто-то перехватит трафик, и не поможет при краже кук. Но вот в ситуации «кто-то открыл настройки и прошёлся по кукам, пытаясь запомнить значения» — сильно усложнит жизнь злоумышленнику.
Можно пойти дальше, и при создании хэша использовать юзер-агент. Теперь взломщику придётся использовать браузер той же версии, что и у нас (а в случае с IE ещё и с тем же набором плагинов тех же самых версий, что выходит уж очень маловероятно, особенно если взломщик не догадался подсмотреть юзер-агент).
Но если пароль всё же утёк — мы по-прежнему бессильны. Даже сменив пароль через форму восстановления либо изнутри системы — взломщик останется залогинен, пока не закроет браузер. Ведь в основе авторизации у нас всё ещё лежит сессия.
Можно, конечно, на PHP получить id сессии при логине, записать его куда-то в базу, а при сбросе пароля стартовать по очереди все сессии с айдишниками из базы и делать session_destroy()… Возможный вариант, но не обязательно следовать ему.
Итак, мы сформулировали основной список требований к нашей системе:
1. Быть простой в реализации
2. Желательно не зависеть от используемой серверной платформы
3. Позволить «выкинуть» взломщика из системы, завершив все открытые сессии, либо некоторые из них (на основе браузера/операционной системы/времени логина)
4. Видеть список всех своих открытых сессий в системе, просматривать его
5. Максимально затруднить атаку в случае отсутствия SSL (например, открытый Wi-Fi)
6. Не создавать неудобств легитимным пользователям
Приступаем к работе
Перво-наперво создадим в нашей базе данных (будем считать, что мы используем реляционную СУБД) таблицу для хранения сессий. Наших сессий (не путать с PHP-шными!). Таблица будет иметь следующие поля: id, user_id, ip, user_agent, time. В качестве времени будем хранить время создания сессии. Можно хранить и время последнего доступа, но вскоре мы увидим, что это избыточно, и можно к этому прибегнуть лишь в рамках денормализации, чтобы ускорить выборку данных. Создаваться сессия будет в момент авторизации, а также при регистрации (мы хотим, чтобы после регистрации пользователю не приходилось заполнять форму логина, и тут же авторизуем его). Также создадим вторую таблицу — log, с таким же набором полей. Туда будем добавлять запись при каждой авторизации (через форму входа или по кукам).
Теперь мы можем хранить на клиенте id сессии, и сверять его с базой. При этом сервер может проверить, что у нас совпадает юзер-агент и IP. Если хотя бы что-то одно не сходится — считаем, что пользователь не авторизован, и направляем его на страницу логина.
Но этого как-то мало — IP клиента взломщик может знать (и если он перехватывает трафик, то уж точно его знает), то же самое касается юзер-агента (который вообще получить не составляет никаких проблем). Нам хотелось бы хранить в cookie не пароль, а некую производную от пароля, привязанную к сессии… то есть к юзер-агенту и IP. Соответственно, если что-то стало отличаться — доступ прекратится. Поэтому, как вы уже догадались, разумно использовать хэш от этих переменных, и сохранять в куке его. При этом просто посмотрев на хэш, взломщик не только не сможет узнать пароль, но даже точно определить, какие именно компоненты были использованы при его создании (и с какими модификациями).
Создадим в таблице сессий ещё одну колонку — hash. Будем использовать её для хранения хэшей наших сессий.
Вопрос удобства
Но тут мы сталкиваемся с другой проблемой. Клиент может переключаться между разными IP (как минимум между домашним Wi-Fi и 3G в дороге, а ещё рабочим защищённым Wi-Fi, как пример). И было бы очень негуманно заставлять его вводить заново логин и пароль каждый раз при смене IP адреса. Как быть, хранить в куке целый список хэшей? При запросе на сервер отсылать его? Можно, но это несколько усложняет реализацию. Кроме того, это раздувает размер куки (при том, что нам основную часть времени может требоваться всего один хэш, мы будем хранить все когда-либо использовавшиеся), а при очистке кук мы (как пользователь) потеряем их все, и опять придётся с каждого IP адреса вводить пароль вручную.
Что, если привязать хэш только к юзер-агенту? Можно, но это существенно снизит безопасность. Нам нужен компромиссный подход.
Делегирование полномочий
Что нам это даёт? Мы можем запихать в этот скрипт сколь угодно хитрую логику, вплоть до анализа последних действий пользователя и добавления его в бан-лист по IP, либо блокировки его аккаунта на тот или иной срок. Но сперва реализуем очень базовую функциональность: будем сверять значение хэша, пришедшего из куки, с тем, что должно было бы получиться, если хэш не был искажён. Сервер знает IP, знает юзер-агент, знает пароль текущего пользователя… Кажется, всё готово!
Разобьём начальную стадию нашего внешнего скрипта (это тоже можно вынести в отдельный файл, но в данный момент это не важно) на два этапа. На первом мы смотрим, установлена ли обычная сессия PHP. Если нет — сразу перебрасываем пользователя на форму авторизации. Но форма при загрузке проверяет наличие кук, и если кука с хэшем нашей сессии существует, и хэш совпадает с ожидаемым (хэш-функция от пароля* и юзер-агента), то ставим переменные сессии (в первую очередь user_id), делаем запись в таблицу log, и обратно перебрасываем пользователя туда, откуда он пришёл (адрес раздела для возврата разумно передавать прямо в ссылке). Итак, если нет PHP-сессии, но есть куки, и куки соответствуют браузеру — пользователь залогинен.
Теперь рассмотрим вариант, когда сессия есть (после того, как пользователь залогинен по паролю из формы или по кукам, он тоже попадёт на этот шаг). И вот тут вступает в игру наш скрипт security.php. Вот его код:
Если нам нужна система банов — можно раскомментировать последние две строки. И не забываем, что чтобы не произошло бесконечного зацикливания, в скрипт авторизации проверку на бан тоже надо включить!
Скрипт прост как дважды два. Мы проверяем наличие сессии с нашими текущими параметрами и нашим текущим хэшем. Если что-то не совпало — нас попросят пройти повторную авторизацию через редирект. И вот тут происходит самое вкусное. Если у нас поменялся только IP — мы пройдём проверку, для нас создастся новая сессия, если её нет для этого IP (этот момент надо включить в код авторизации), и создастся новая кука.
Если у нас поменялся браузер (угнанная кука) — придётся вводить пароль, которого у взломщика нет, иначе зачем ему воровать куки. При этом IP скорее всего будет другим, но может быть и тем же (взломщик находится с нами в одной локальной сети). В случае, когда взломщик в одной сети с жертвой, и имеет тот же юзер-агент — к сожалению, мы никак не сможем отличить его от настоящего пользователя. Привет, беспарольный Wi-Fi.
Если поменялся только хэш (поменяли куку вручную? побились файлы на жёстком диске?) — придётся авторизоваться заново, ничего не поделать.
Наконец, можно очень эффектно моментально отключить доступ к аккаунту. Для этого даже не обязательно удалять строку с сессией. Достаточно удалить/поменять/добавить один символ в хэше (последнее поле). Пример из жизни — если легитимный пользователь по счастливому стечению обстоятельств первым успеет воспользоваться кнопкой смены пароля в кабинете — взломщика выкинет, причём при первой же перезагрузке страницы. У настоящего пользователя уже будет новая кука (в хэше будет использован новый пароль), старые сессии будут полностью удалены из таблицы, а новая сессия создана с новым хэшем. А взломщик останется со старым невалидным хэшем, который не пройдёт проверку в security.php. При первом же непрохождении будет сброшена сессия PHP, и выполнен редирект на авторизацию. Которую, опять же, нельзя пройти, имея неактуальный хэш от старого пароля.
Всё хорошо?
Почти. Данная система по-прежнему не защищает от кражи хэша из кук при открытом канале и отсутствии SSL. Кроме того, сложно обеспечить своевременную блокировку, если доступ к аккаунту утерян (особенно если взломщик уже сменил пароль). В этом случае очень помог бы сброс пароля через смс-команду с привязанного телефона — но для этого уже нужна возможность принимать и отправлять смс. А если она есть — то можно сразу внедрить двухфакторную авторизацию, которая снимет массу проблем. Но не проблему с необходимостью в SSL — поскольку всё равно результатом любой авторизации является получение некого токена доступа, работающего ограниченное время. И этого времени может быть достаточно, чтобы сделать от нашего имени что-то, что нам не понравится.
Данный код можно, наверное, сделать ещё лучше и надёжнее. Если у вас есть по этому поводу соображения — пишите их в комментарии. Пока что система зарекомендовала себя с очень хорошей стороны, и была использована уже минимум в трёх проектах, два из которых имеют массовый доступ.