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