Hacker News Reader

Hacker News

Comment by codetrotter | Hacker News Reader

Parent Full thread

codetrotter

Thinking about this a bit more, I believe that there is another problem with how account creation is done.

In general we do it in two steps:

1. User detail and password

2. E-mail confirmation

Instead, if we did

1. User details but NOT password

2. E-mail confirmation and subsequently entering the password on the page that was sent via e-mail.

Actually, I think the most optimal would be

1. Enter e-mail address only

2. E-mail confirmation and entering all details

This would simultaneously protect the person that initated account creation and the owner of the e-mail address from one-another.

View on HN

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.

I 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.

Please 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.

Fair 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.

Maybe I don't understand the second option, but it seems to me that if you do the second option and a wrong email address is provided in step 1, then in step 2, the wrong person can take ownership of the account and provide his own password. So I agree with codetrotter that the third option is best of the three, to protect the two people from each other.

The possible disadvantage I see with the third option however is that if you are at a service desk, and they are trying to sign you up for a membership of some sort, they can't complete your registration on the spot. You would have to go home and use the computer to complete your registration (unless you can use email client on your smartphone). Which means they may lose a possible member if they don't ensure that you finish the registration right there and then.

For that reason it may be better to collect the email address, all customer details, and the desired password (typed twice). Then when the confirmation link is sent, the confirmation link should take you to a link that asks you for your password again (once) before your account is validated. This ensures that the person at the service desk is really the person using the email account to do the validation. Mere access to the email account should not be enough. The main advantage here is to make sure as little work as possible is left to the customer to do by himself when he gets home. I agree that this is a lot more messy than Doug Webb's approach, because the only accounts in that approach are validated accounts.

However to the extent that one does not want to lose a possible new membership because someone went home and decided not to continue the process because it is a lot of work, it may be worth it.

Second solution seems pretty optimal for security but not sure if users up for that.

Reply on news.ycombinator.com