Best practices for passwords on registration?

Question

I have a website which users register an account. On the registration field, the form fields are:

• Name
• Email
• Confirm email
• Username

But there is no password field. When they hit submit, they are emailed a password which is very complex, such as LHJVjhwnv%uu5 or RbWM9!jeDZUQb.

I have appealed to my developer to instead make it so that the users can set their own password on the registration form. To confirm that password on the form, and then be sent a confirmation link to their specified email. Then this way they can at least log in to their account and verify their email via confirmation link. Or if they didn't, every time they log into the site it could remind them to verify their email etc or else they can't do much on the site (example). This way even if they don't get the confirmation link, they can still update their account email to a different email and have it resent. At least at this stage, they can log into their account, instead of not at all.

The response I have received from the developer is as follows

"The problem with providing the password on registration is that you'll have loads of fake accounts. So people that just register with a non-existent email address. At least with the email validation you're proving the user exists, to a certain extent. If they register with the wrong email, they can just re-register."

I'd like to ask you all if the current approach the developer has employed is acceptable?

If not, what are some good reasons I could use to convince the developer to change?"

I've tried to explain the following

• Every day there are 9-10 people who register and then directly use the "password reset" form right after. This form involves them putting in their email address that they signed up with, and then it emails them a link to SET a new password. So if they are setting a new password anyway, why not just have them set it in the first place on the registration form? Why would there be 9-10 people every single day using the password reset field, directly after registration? I'm pretty sure its because they are seemingly struggling with these complex passwords (which I am not against) that are being emailed to them and are missing a key or character, or do not seem to be aware of copy/paste or something like that. If they could just set their own password the first time around, they wouldn't need to run to the password reset field right after because of their emailed password not working. I thought it was weird how everyday theres always password reset emails. Not for everyone, but a good 9-10 people a day ever since I started using Mandrillapp to track the outgoing emails. This is backed up by the next point.

• Every day there are at least 2-3 people who fill out the contact form indicating that the password they received is not working. Could all be avoided if they just could set it on their own. There may be even more that just don't bother contacting.

• Out of nearly 8000 accounts, 50% have never logged in. My strong suspicion is that the Registration email containing their password goes to their junk folder/spam folder. This is despite me having proper SPF, DKIM, etc setup. 2 months ago, I decided to start using Mandrill to send mail to ensure it goes to the inbox, but still there's at least 1-2 people/day that say that they did not get their email.. which perplexes me. If they could define their own password, they wouldn't have to worry about waiting for their password via email, or not getting it entirely. This just further highlights my initial concern.

Thank you for your time!

Answer 1

Your developer is trying to mix three different process into one: password registration, email validation and robot detection. Unfortunately, that makes the whole setup less secure and less resilient than it should be.

• Email is clear text and, nowadays, it pretty much guarantee to live forever and be included into several indexes and often kept for a long time in multiple servers along the way. If you sent someone a password via email, you're sure that you're making it very vulnerable. Email is not secure unless you explicitly secure it (S/MIME or PGP).
• Email isn't a synchronous process: there is no minimum time for an email to reach his target. In fact, it often can take several minutes for an email to get through the final mail server. This makes the whole process slow and unfriendly to the end user.
• Email isn't very reliable: as you've discovered, email can be lost for a variety of reasons without anyone being notified. As such, it makes it a really poor medium for transmitting important, time-critical information like initial connection info.
• For robot detection, this process is dreadfully inefficient: there are plenty of disposable email services that can easily be used to work around this process (or catch-all mail domains).

Now, there is no "correct" way of doing this: what will work best will depends a lot on what level of security you need and how you weight it against ease of use: it's not the same to design security for a banking web site than for a cooking receipt repository.

It is, however, important to remember these things when designing the system (and stay consistent, which is, in my opinion, the issue you're having with yours):

• What is your target audience. This will let you know how complex for the user you can make the registration process.
• What is the value of the registration to your web site for your users. This should tell you how much effort you can expect from them.
• What is the value of the registration for you. It should tell you how much effort you should put into verifying the registration detail.
• What is the value of the registration for a potentially hostile third party. It should tell you how much effort you should put into making sure the user information is secure.

OWASP has a cheat sheet describing the elements of a secure authentication process. Their guide to authentication is a little light on the subject but it does bring in some good element about how to do it right (or not do it wrong).

Answer 2

This is a complex subject if you ask me.

If you allow someone to type in the password and username upfront in the registration form of the sign up process and have them working immediately, then you have a problem when it comes to notifying your user for any reasons, if they are not notified by your messages in the provided e-mail. There are many reasons why it could happen, including:

• the user informed the wrong e-mail (typo or any other reason);
• the message is going to their SPAM folder;
• your system is not authorized by the user to send her any messages: some e-mail providers have some system where they would reply automatically with some e-mail providing instructions on how to proceed to get the messages delivered, in order to protect against most SPAM. Maybe the user would have to set up some exception in order to not require those steps from some senders;
• the mailbox is full;

Whatever the reason is, if the application requires e-mail validation in order to allow the user to access it then it's less likely your system will be unable to deliver messages to your users. Sending multiple e-mails to invalid users may increase the chances for your e-mail delivery system be automatically flagged as SPAM, and you don't want that.

There's another problem to consider. What if the user provided another valid e-mail due to some typo? Then there would be another user getting all those annoying messages. Or that other user could even take over that account if she would desire so. Those are some of the reasons why e-mail verification is desired.

So, one approach to user authentication is to simply ask for the user e-mail address in the first step of the sign up process. Don't ask for anything else to not bother the user registering to your application. Just the e-mail address. Then they would get a link with a generated random token valid for a few minutes. Once the user clicks the link she would be taken to the next step of the registration and that e-mail would be flagged as confirmed.

Something to consider in this approach is that someone could use this to, intentionally or not, SPAM another user with annoying messages asking the user to proceed with the sign up they haven't requested. I'm not sure how to prevent that, but it's probably a good idea to rate limit those messages. For example, a token could be valid for 10 minutes and while it's valid the system wouldn't send another token by e-mail. Those users could be still annoyed by messages every 10 minutes, but maybe you'd want to handle such cases once they happen.

There's absolutely no reasons to send any passwords to e-mails for recovery purposes. Tokens should be used instead and then the application could ask for a password. Just be aware that a password is not really required to authenticate a user if their e-mail address is valid. They could always request a token when they want to sign in, without ever providing a password.

If you still prefer to have the sign up full form displayed up-front, there's also the possibility of requiring the user to confirm their e-mail address in order to being able to get any messages delivered to them. This way, the system would never attempt to send any messages to unverified e-mail addresses. Whenever they are using the application, a notification icon could be shown to remind the user that her e-mail address is not yet verified, which means she wouldn't be able to recover from a lost password or get any notifications from the application by e-mail.

Also, be aware that usernames are not really required if you set a unique constraint on the e-mail address so that the e-mail could be provided instead of a username for authentication purposes. You may want to keep the e-mail addresses in a separate table in order to support multiple e-mails per account.