3

I'm working on updating a web application. It currently creates a password for a user during sign up. Is asking the user to create the password themselves safer than relying on a generated password?

essefbx
  • 172
  • 12
Jamie Little
  • 35
  • 5
  • As long as you send the "generated password" to the registered users email, and empower them to change it on their first login, you should be fine. :) – user2339071 Apr 28 '15 at 17:47
  • 2
    Sending passwords to an e-mail address is generally not secure. I would recommend implementing a password policy during the signup process. – Jeroen Apr 28 '15 at 17:49
  • I don't think sending the password via email is insecure on this scenario. The user has just signed up, and s/he can be required to change it on the first logon. There's just a little time between an attacker could grab the password before the user has changed it. – ThoriumBR Apr 28 '15 at 17:55
  • On one hand the generated password is likely to have higher entropy than the average password chosen by a user. On the other hand communicating the password to the user securely might not be trivial. – kasperd Apr 28 '15 at 23:34
  • I'm with @ThoriumBR: If the passwords needs to be changed as part of activating the account (and importantly: _before_ the user fills in the Personal Info part of registration) then even if the email is intercepted, the attacker has gained what? An empty account? That's a tricky attack to pull off, for no gain. – Mike Ounsworth Apr 29 '15 at 00:02

3 Answers3

4

That totally depends on your application and its requirements.

If your applications needs to verify users' email addresses, then you can send them a randomly generated token (one-time use and valid for a limited time period) for the first-time login, on the email address that they provided during sign-up. And ask them to set their own password after they use that random token to login. This way you are also verifying their email address.

If you are not concerned with email verification, you can simply ask them to choose a strong password during the sign up. In this case, don't forget to re-authenticate the users just after they sign up.

In any case, make sure that your users choose a strong password, by complying with a strong password policy. Also make sure that all password related functionality in your application (forgot password, reset password, etc.) also comply with your application's password policy.

Rahil Arora
  • 4,259
  • 2
  • 23
  • 41
  • One should also make sure the token is single-use only, so that if someone else reads their email and uses the token to log in, then the honest user will hopefully notice that there was a problem. –  Apr 28 '15 at 20:51
1

If your generation method has enough length and good character set, it will be more secure than asking the user for password.

The problem about this way which makes websites not to use it, is because auto-generated passwords are hard-to-remember and don't offer good user experience.

MTP1376
  • 33
  • 4
0

I would advise against it. Your web application should have a policy that passwords are only ever input, never output. I find that with following this approach, your application will be more secure in general.

There is also a further problem of how to give the password to the user. Displaying the password on screen (either in an email or when they register) carries the risk of a shoulder surfer seeing the password. If displayed on the page there are also risks of the page being stored in the browser or proxy cache. Yes, response headers should be set to prevent this, however it is easy to forget.

A better approach would be to generate a random link as part of the sign up process, which is emailed to the user. The approach also protects against user enumeration and validates the email at the same time. The link should expire, so if the email is left in the user's inbox and then later discovered, it cannot be used to log into the account. At registration, expiring this link is effectively the same as deleting the account. This is useful in the case that someone has entered the wrong email address - this accidental account is then not blocking the owner of the real email address from registering.

If an attacker still wanted access to the account on an email address they had managed to gain access to, yes they could generate a new registration to that email address. However, this leaves an audit trail behind so you can later determine what has happened. Using the link lets the application convey more information about what has happened. e.g. clicking an expired link could render a message to the effect of Sorry, this registration has expired, please register again. However, if a user is trying to log in with an expired password then you cannot give any further information regarding the account without reducing security. Revealing that the account has expired would be a user enumeration vulnerability, revealing that the password has already been changed also leaks information about the state of the account.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178