Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

Безопасное обращение с учетными записями пользователя

by
Difficulty:BeginnerLength:LongLanguages:

Russian (Pусский) translation by Liliya (you can also view the original English article)

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

Заключение

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

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

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.