Это разумный процесс регистрации пользователей?

Question

Я работаю над процессом регистрации внутреннего приложения. Мой первоначальный дизайн ниже.

Мой главный вопрос: действительно ли нужно включать registration_confirmation_code. Защищает ли оно приложение от реальной угрозы или просто добавляет ненужную сложность? Я не уверен в этом.

---

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

• Если это действительный адрес агентства, приложение создает новую строку в таблице пользователей.

  • В таблице есть столбец registration_confirmed, который по умолчанию равен false. Приложение не позволит пользователю войти в систему, если registration_confirmed не равен true.

  • В таблице есть столбец registration_confirmation_code, который является случайно сгенерированной строкой.

• Приложение отправляет электронное письмо на адрес, введенный пользователем. Он содержит ссылку на страницу, которая позволит пользователю подтвердить свою регистрацию и задать имя пользователя и пароль.

  Ссылка содержит пользовательские id и registration_confirmation_code в строке запроса:

  http://agencydomain.com/users?id=123&registration_confirmation_code=fab49dk34nw97d

• Нажав на ссылку, пользователь подтверждает, что введенный адрес действителен и имеет к нему доступ.

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

  • registration_confirmed равно false. Они должны иметь возможность подтвердить свою регистрацию только один раз.

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

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

• Когда они отправляют форму с действительными данными, приложение устанавливает registration_confirmed на true, и они регистрируются.

Answer 1

Другой подход заключается в использовании централизованной аутентификации и пропуске всего процесса регистрации.

При первой попытке входа в систему создайте профиль пользователя из шаблона.

Аутентификация может быть выполнена несколькими способами. В идеале, что-то вроде LDAP (или Active Directory, если вы так качаетесь). Также возможно использовать почтовый сервер для аутентификации, в зависимости от того, как он настроен.

Answer 2

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

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

Answer 3

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

Небольшой вопрос; зачем делать это в два этапа? почему бы не позволить пользователю сразу ввести пароль? Обычно это намного удобнее для пользователя.

Кроме того, вместо того, чтобы использовать регистрационный_конфигурационный_код, вы можете рассмотреть возможность использования хеша MD5 (или подобного) адреса электронной почты пользователей. Таким образом, вам не нужно дополнительное поле, и вы можете даже опустить идентификатор, если хотите.

-Dave

Answer 4

Система OpenID была изобретена для решения этой проблемы. В основном, кто-то приходит на ваш сайт и говорит: «Я XYZ, и вы можете проверить это, проверив ABC». Затем у вас есть провайдер OpenID (который, вероятно, будет сервером в вашей компании; если у вас есть LDAP, вы уже прошли большую часть пути), убедитесь, что они являются теми, кем себя называют (войдя на сайт провайдера OpenID). Если вы можете доверять провайдеру OpenID, и учетная запись OpenID не была скомпрометирована, то вы только что проверили своего пользователя. Вероятно, вы можете обойтись без формальной процедуры регистрации ... просто отправьте их на экран настройки учетной записи (при условии, что вам нужно больше, чем пароль + адрес электронной почты в вашем примере, так как оба они предоставляются через OpenID) при первом входе в систему.

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

Он имеет то преимущество, что не требует от пользователя предоставления вам пароля, который он может забыть (и он может изменить свой пароль у поставщика OpenID, и он будет изменен для всех их сайтов, использующих OpenID). Для большинства основных языков доступны библиотеки OpenID, и сворачивание собственных не должно быть слишком сложным.

Answer 5

Вы, кажется, делаете очень много усилий для внутреннего приложения? Сколько мошенничества вы ожидаете?

Answer 6

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

IOW, если вы оставите этот шаг, «атакующий» может:

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

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

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

Answer 7

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

это исключает один шаг из процесса и значительно упрощает регистрацию.

Answer 8

Вам все еще нужно отправить код подтверждения по электронной почте.

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

Answer 9

Защита вашего приложения от даже менее проверенных, чем обычно, пользователей - это хорошо, но еще лучше то, что вы защищаете случайных людей от спама из вашей системы. Требуя согласия, вы гарантируете, что X не может зарегистрироваться в вашей службе, утверждающей, что это Y, и заставляете отправлять электронную почту Y каждый раз, когда вы хотите связаться с пользователем. Это также дает Y возможность сказать «что? Нет, это не я» и щелкнуть «отклонить», отправить отчет ARF или иным образом сообщить, что кто-то вас пригласил.

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

Answer 10

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