3

I'm a developer working on a website for the first time and have a question about new user activation.

The way our site is setup now a user creates a new account and they get emailed a temporary password. The temp password gets hashed then saved in our database. The user logs in and they are told to reset their password (if we keep this method we'll force a password reset).

My concern is that I've never seen a site that does this. For new sites I always get emails with links that verify my account, and then I'm allowed to log in.

My question is which of these methods is more secure and why?

Sentient
  • 133
  • 4

2 Answers2

3

If the end user is the one who initiates the account setup and they provide a password, the use of a temporary password that they will have to change upon first logon provides no benefit. And will only serve to annoy the user.

Temporary passwords are useful when someone else initiates the account set up. As an example, a new employee coming into a company is typically provided with a domain account. You wouldn't want to let users self-register and create whatever domain account they wanted. You would typically provide them a temp password so you could control the accounts being created and to ensure that it was only them who could configure that account. With a temporary password the end user, and the administrator know that no one has used that account if upon authenticating, they're required to change the password the first time. If the user tries their password and it's incorrect, you have the suspicion that the account may have been compromised or used by someone who acquired the temporary password and can investigate as necessary.

The non-temp password option is the most secure. Because it takes anyone other than the end user who knows the password out of the equation.

JasonS
  • 31
  • 1
  • Thanks for your answer! You brought up some issues I hadn't thought of.. I chose the other answer 'cause it addressed the security issues more directly. – Sentient Jan 22 '15 at 17:10
3

It isn't terribly common, but it isn't terribly uncommon either. It's simply a way to do email validation without having to store extra state information.

So, it's simple, which has some benefits in that complexity is the enemy of security, so simple solutions are typically better for security than more complex alternatives that do the same thing.

HOWEVER...I would suggest that in this case, it is not only not better, but in fact less secure, and less than ideal.

The primary reason is that it is always a bad practice to send passwords in email. Even temporary ones. It's much better to send a link that lets the user set a password by following the link. This works for email validation, for accounts created asynchronously (by an admin, or a batch job, for instance) and password resets when a user has forgotten their password. This requires a bit of extra state as I mentioned before (the link has to be unique, and you have to remember the value for when the user clicks the link and returns) but this is not all for naught. It not only means that the password never need be sent out into the ether in plaintext, but it also gives you a single point (the token) to expire if it hasn't been used in a reasonable time, and to check to prevent re-use. (A single token should only work once.)

So, the link is decidedly more secure. Tokens are easier for you to protect with security controls than passwords, and you should never send passwords in plaintext, which begs for abuse and misuse.

Xander
  • 35,616
  • 27
  • 114
  • 141