12 рекомендаций по учетным записям пользователей, авторизации и управлению паролями

задняя часть

12 рекомендаций по учетным записям пользователей, авторизации и управлению паролями

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

К счастью,Google Cloud PlatformВ (GCP) есть несколько инструментов, которые могут помочь вам принимать правильные решения в отношении инноваций, обеспечения безопасности и авторизации учетных записей пользователей (в данном случае тех клиентов и внутренних пользователей, которые аутентифицированы в вашей системе). будь тыGoogle Kubernetes Engineнесет ответственность за хостинг веб-сайта, илиApigeeAPI на , или приложениеFirebaseИли любое другое приложение с аутентифицированной пользовательской службой, эта статья покажет вам лучшие практики, чтобы убедиться, что у вас есть безопасная, масштабируемая и удобная система аутентификации учетной записи.

хэшировать пароль

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

Ни при каких обстоятельствах не храните пароли в открытом виде. Вместо этого ваша служба должна хранить хешированные необратимые пароли, например, с использованием таких алгоритмов хеширования, как PBKDF2, SHA3, Scrypt или Bcrypt. В то же время при перемешиванииС сольюВ то же время значение соли не может совпадать с информацией аутентификации, используемой для входа в систему. Не используйте устаревшие методы хеширования, такие как MDS и SHA1, и ни при каких обстоятельствах не используйте обратимое шифрование илиПопробуйте изобрести собственный алгоритм хеширования.

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

Еще один момент: если вы можете генерировать пароли в открытом виде из паролей, предоставленных пользователем, значит, с вашей системой что-то не так.

Разрешить третьим сторонам обеспечивать аутентификацию, если она доступна

Используя третью сторону для проверки подлинности, вы можете положиться на надежную внешнюю службу для проверки личности пользователя. Google, Facebook и Twitter являются широко используемыми поставщиками аутентификации.

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

Различать понятия удостоверения пользователя и учетной записи пользователя.

Ваш пользователь не является ни адресом электронной почты, ни номером телефона, ни уникальным идентификатором, предоставленным в ответе OAUTH. Они являются конечным результатом всех уникальных, персонализированных данных и опыта, связанных с вашим сервисом. Хорошо спроектированная система управления пользователями имеет низкую связанность и высокую согласованность между профилями разных пользователей.

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

Позволяет связать несколько удостоверений с одной учетной записью пользователя

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

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

Не ограничивайте длинные или сложные пароли

NIST недавноСложность и надежность пароляОбновленное руководство по . Теперь, когда вы используете (или скоро будете) использовать надежный криптографический хеш для хранения паролей, большинство проблем решено. Независимо от длины ввода, хеш-значение всегда будет генерировать выходное значение фиксированной длины, поэтому ваши пользователи должны устанавливать свои собственные пароли пользователей в соответствии с их предпочтительной длиной. Если вам необходимо ограничить длину пароля, установите максимальное значение POST, разрешенное вашим сервером. Практически говоря. Обычно это более 1 млн.

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

Не навязывайте необоснованные правила для имен пользователей

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

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

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

Разрешить пользователю изменять имя пользователя

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

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

Выберите правильные правила для своей платформы, но убедитесь, что они позволяют вашим пользователям расти и меняться с течением времени.

Попросите ваших пользователей удалить свои учетные записи

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

В некоторых случаях вы можетеюридически обязаны соблюдатьПользователям необходимо своевременно удалять свои данные. Точно так же вы значительно увеличиваете свою подверженность риску, когда происходит утечка данных из «закрытых» аккаунтов.

Сделайте разумный выбор продолжительности разговора

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

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

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

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

Используйте двухэтапную аутентификацию

учитываться при выборе пользователемдвухэтапная проверка(также известный как двухфакторная аутентификация или просто 2FA) и фактические последствия взлома учетной записи. Аутентификация SMS 2FA из-за множества недостатковпротив NIST, однако, это, вероятно, самый безопасный вариант, который примут ваши пользователи, учитывая, что это тривиальный сервис. Пожалуйста, предоставьте самую безопасную аутентификацию 2FA, которую вы можете предоставить. Поддержка сторонней аутентификации и добавление их двухфакторной аутентификации поверх — это простой способ повысить вашу безопасность без особых усилий.

Идентификаторы пользователей не чувствительны к регистру

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

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

Создайте безопасную систему аутентификации

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

дальнейшее чтение

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

  • NIST 800-063B охватывает сертификацию и управление жизненным циклом
  • OWASP продолжает обновлять шпаргалку по хранилищу паролей
  • OWASP Deep Dive с памяткой по сертификации
  • Сайт Google Firebase Certified содержит обширную библиотеку руководств, справочных материалов и примеров кода.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории