3 ms·
Typically when I implement user self-registration for my portal-website clients, I use a variation of your third option: 1. Enter email address and some out-of
by DougWebb 9y ago
Typically when I implement user self-registration for my portal-website clients, I use a variation of your third option:
1. Enter email address and some out-of-band information that only an existing-account-holder should know. Eg: a web portal for a utility company could ask for the account number and amount due from a recent bill.
2. Send confirmation email with a code/link.
3. After user enters a valid code, continue registration by gathering additional user details, password, and (usually) recovery Q&A.
The user account is not created until step 3; if they provide a fake email, it's as if the registration attempt never occurred. Absolutely no access is granted until after the final step.
The extra details in step #1 only works for website registration of a user that has a pre-existing relationship with the company, of course. For a new account, email address is all you should request at that point.
- stephen_g 9y agoI wish requiring validation was still the norm. I get that services and sites want to reduce “friction” and get people using it right away, but anybody like me with fairly generic gmail address knows, many people don’t know their own email address. I must have hundreds of active accounts linked to that email that I didn’t sign up for (although I’m sure a lot of them can’t be logged into anymore and the people can’t recover their passwords). That account became unusable, I got my own domain account a decade or so ago to replace it but still look in there occasionally. Please though, anybody implementing signups - if you are going to let people sign up without validating email addresses, put a “I didn’t sign up for this account” link in every email you send.
- fyi1183 9y agoPlease don't use recovery Q&A. As a user, I cannot trust that a website gets the recovery flow right. Some websites will allow you to bypass email and password if you know the answer to the question. Because of that, I cannot put in the real answer, as that would be a massive security risk. So I usually put in some random garbage, which means it's essentially a second password. Well, if I lost my first password, chances are good that I lost the second password as well. So please, don't do security questions. Just send a password reset link by email. If you're worried about stuff like payment info stored in the account, just ask me to re-enter those details after I changed my password.
- DougWebb 9y agoFair points, and I'm not a fan of the recovery Q&A either. But here's the process that I use: 1. User must enter their email address, and I send them an email with a recovery code. 2. After they enter the code, validating control of the email address, I show them the Question they chose and let them enter the answer. 3. After they enter the correct answer, I force them to update their password, and I send a confirmation email about the password update. The emails all provide contact information and ask the user to get in touch if they didn't initiate any of these actions. You're right about the answer being essentially a second password, and I treat it as such: only an encrypted hash is stored, type=password fields are used to enter it. One of my clients did request getting rid of the Q&A, which I was able to do pretty easily because email verification step and reset code were already implemented. On a personal note, I never use real answers for security questions. I use randomly generated strings, just like my passwords. If I can choose my own question I use a random string for that too.