Статьи

Безопасная обработка учетных данных пользователя

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

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

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

Давайте рассмотрим несколько соображений безопасности при работе с логинами и паролями на ваших сайтах.

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

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

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

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

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

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

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

Как уже было отмечено, удаление конкретного сообщения для недопустимого имени пользователя приводит к повышению безопасности и ухудшению качества работы пользователя. Сообщение о том, что логин не существует, поможет пользователю легче заметить такие опечатки, как ввод john вместо jon . Это сообщение также помогает пользователю, который не помнит, какое имя пользователя они использовали на вашем сайте. Помните, что сообщения такого типа дают хакерам простой и легкий способ проверить, существует ли пользователь на вашем сайте.

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

Введение увеличивающегося времени задержки после каждой неудачной попытки входа в систему также помогает предотвратить хакеров. Первая попытка входа происходит нормально. Второй вход в систему задерживается на долю секунды перед возвратом результата. Дальнейшие попытки задерживаются все дольше, прежде чем возвращать ответ. Эта задержка допускает минимальные сбои для легитимного пользователя, который допустил ошибку, но замедляет попытки хакера взломать сайт.

Для более конфиденциальных данных можно использовать более сильный подход, заблокировав учетную запись после нескольких неудачных попыток. Блокировка учетной записи отключает ее временно или навсегда. Блокировка останавливает атаки методом перебора, так как после определенного момента вход в систему не будет работать. Временное отключение должно оказывать минимальное влияние на пользователя, пока отображается сообщение о причине блокировки. Постоянная блокировка требует, чтобы пользователь обратился в службу поддержки, чтобы решить проблему и лучше соответствовать логинам, защищая важные данные.

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

Пароли должны храниться в засоленном и хешированном виде. Соль — это случайно сгенерированное уникальное значение, которое сохраняется для каждого логина и добавляется перед хэшированием. Добавление соли не позволяет идентичным паролям иметь один и тот же хеш, а также не позволяет хакеру заранее составить список результатов хеширования возможных комбинаций паролей. При добавлении случайного хэша пароль abc123 (пожалуйста, никогда не используйте ничего подобного в качестве фактического пароля) приведет к разному хешу для каждого пользователя.

Хэш-функция превращает пароль в значение фиксированной длины. Существуют функции, специально разработанные для паролей, такие как PBKDF2 или Bcrypt . Процессоры GPU в современных графических картах могут выполнять вычисления, необходимые для хеширования, и могут быстро сломать многие слабые алгоритмы. Выделенные машины с целью взлома паролей могут определить любой восьмисимвольный пароль или менее, менее чем за шесть часов .

Пользователи часто используют один и тот же пароль для большинства сайтов, где у них есть учетные записи. Многие сайты начали проверять открытые учетные данные, полученные в результате взлома основных учетных записей, по сравнению с их собственными учетными записями и связываться с пользователями, чьи комбинации имени пользователя и пароля совпадают. Evernote и Facebook недавно изучили учетные данные для входа в систему, выпущенные Adobe, и предупредили пользователей, используя те же учетные данные.

Самый простой способ правильно обрабатывать пароли — это использовать инструменты, включенные в ваш веб-фреймворк. Безопасность паролей сложна, и если сделать что-то неправильно, пароли пользователя могут быть открыты для атаки. pH pass предоставляет публичную библиотеку для PHP с использованием Bcrypt. Старые встроенные поставщики членства .NET использовали более слабые хэши, но новые универсальные поставщики используют PBKDF2. Rails также предоставляет гем Bcrypt .

Когда вы правильно защищаете пароли, чтобы их нельзя было восстановить, вы теряете возможность предоставить пользователю забытый пароль. Затем вам нужно предоставить альтернативный способ для пользователя, который законно забыл свой пароль, для безопасного сброса пароля.

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

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

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

Сброс пароля по электронной почте также делает безопасность вашего сайта зависимой от целостности электронной почты пользователя. Если к электронной почте можно получить доступ, то этот человек может сбросить пароль. Сайты могут добавлять вопросы безопасности, на которые необходимо ответить перед сбросом пароля. Вопросы безопасности обеспечивают немного дополнительной безопасности, если ответы легко найти. Секретный вопрос «Какой мой родной город?» обеспечивает небольшую безопасность, если ответ можно найти в профиле человека на Facebook. Подробнее о разработке хороших вопросов см. Http://goodsecurityquestions.com/ .

Логин и пароль требуют только одну пару информации для доступа к веб-сайту. Когда эта информация предоставляется, то предполагается, что пользователь является правильным человеком. Чтобы сделать кражу учетных данных менее эффективной, вы можете добавить второй этап процесса аутентификации. В дополнение к тому, что пользователь знает (имя пользователя и пароль), пользователь также должен использовать что-то, что у него есть, обычно мобильный телефон через SMS или приложение для этой цели.

Банки, вероятно, были первыми, кто реализовал этот процесс с использованием специального оборудования для генерации кода, зависящего от времени. Google популяризировал использование текстовых сообщений SMS или приложения в качестве второго шага. Многие сайты теперь используют логин, совместимый с реализацией Google RFC 6238 . Вы можете найти библиотеки, уже реализующие эту технику для большинства популярных сред, таких как ASP.NET , ASP.NET # 2 , Ruby on Rails , PHP и Django .

Чтобы избежать этих проблем, у вас есть другой вариант, разрешите кому-то еще разобраться со всем этим путем интеграции с третьей стороной для аутентификации, такой как Twitter, Facebook или OpenID. Это предлагает преимущества и недостатки. Это устраняет большинство проблем безопасности, которые мы обсуждали здесь, поскольку кто-то еще занимается этими проблемами. Тем не менее, эти другие сайты также, вероятно, более хакерская цель, чем вы. Если вы используете другой сайт для обработки аутентификации, то, если этот логин скомпрометирован, хакеры получат доступ к вашему сайту.

Использование известного третьего лица может как помочь, так и навредить репутации и социальной точке зрения. Преимущество разрешения входа через Facebook или Twitter состоит в том, что у многих пользователей уже есть учетные записи, и они с удовольствием их используют. Другие посетители могут рассматривать интеграцию с этими сайтами как негативную функцию и не использовать ваш сайт из-за этого или если это единственный вариант, предоставленный им.

Логин вашего веб-приложения играет жизненно важную роль в обеспечении безопасности вашего сайта. Забота о защите вашего логина сделает многое для защиты вашего сайта, пользователей вашего сайта и их личной информации. Чтобы безопасно работать с логинами, минимизируйте объем данных, которые ваши страницы логина и пароля могут потенциально предоставить хакеру. Кроме того, установите меры безопасности, чтобы было сложнее угадать пароли вашего пользователя с помощью грубой силы.

Защита паролей является важнейшей задачей любого сайта. Плохо защищенные пароли облегчают работу хакера и могут закончиться раскрытием учетных данных вашего сайта. Использование хешированных и соленых паролей значительно усложняет работу хакера. Кроме того, добавление опции второго шага к процессу входа в систему может обеспечить больше защиты пользователям вашего сайта. Вы также можете использовать стороннюю систему для обработки входов на ваш сайт.