password reset logic

[anatak]

What would be a good way to reset a password ?

 

I was thinking

1 user requests reset password page or after faulty login suggest reset password page

2 fill in email address

3 check if email address exists

4 if address exist insert a random key into database

5 create a password reset url with random key and send to registered email address

6 after user clicks url in mail use $_GET to retrieve random key from password reset url

7 check if url exists in database

8 let user choose new password

9 check that password strenght is valid

10 encrypt password

11 write password in db

12 confirm page that password has been changed

 

Are there any obvious mistakes in this logic ?

 

This application will be aimed at 70-80 years old people so it has to be as easy to use as possible.

security questions and captcha's will be not really possible I am afraid.

 

thank you very much

anatak

Edited June 8, 2014 by anatak

[Jacques1]

We've already discussed this just a few threads before yours: hashing a token for password reset.

 

I'm not gonna repeat everything, so just a few problems of your scheme:

• What if the e-mail address does not exist? Do you simply do nothing? Then a user who accidentally entered the wrong address will wait forever for the password reset mail. Do you show an error message? Then you leak private data. The only solution is to send an e-mail in any case. If the address isn't registered, you explain that in the e-mail.
• The password reset token is equivalent to a password, so you may only store a hash of it in the database. Do not store the plaintext token.

• “encrypt password”? I hope you meant that you hash all passwords with bcrypt?

• Are you sure your rest tokens are random? That's usually the biggest problem. The output of functions like rand(), mt_rand() or uniqid() is not random and can be predicted with a bit of effort.

[anatak]

thank you for the link I did not read it till the end but I am pretty sure it is what I was looking for but did not find it since my search terms where different.

 

If the email does not exist the user will get the message that the inputted email is not recognized and will be asked to input his email address again and make sure that there are no mistakes.

 

passwords and tokens are ran through sha512 and salted in the database.

 

thanks again
 

[Jacques1]

If the email does not exist the user will get the message that the inputted email is not recognized and will be asked to input his email address again and make sure that there are no mistakes.

 

That means your application exposes the e-mail addresses of your users. You're allowing anybody to check which e-mail addresses are registered at your website.

 

 

 

passwords and tokens are ran through sha512 and salted in the database.

 

Hashing passwords with SHA-512 is not acceptable, regardless of whether you salt them or not. Current PCs can calculate hundreds of millions of SHA-512 hashes per second, making it easy for an attacker to find out the passwords with simple brute force. This is particularly bad if the users are likely to choose weak passwords, which is probably the case for older people.

 

You need an actual password hash algorithm like bcrypt.

 

Salting the tokens and hashing them with a relatively slow algorithm like SHA-512 is nonsensical and only wastes resources.

 

Maybe you should read the other thread until the end, because we've discussed those very mistakes.

Edited June 9, 2014 by Jacques1

[anatak]

yes I read the other thread and I agree with your position

I have one question. How do you send the password information from the user to the server ?

and is this really needed when I use HTTPS

 

at the moment the password is hashed with sha512 and then send to the server.

server side the password is salted and stored in the database.

 

I will look into password_hash() to encrypt the password.

 

by sending an email when the address is not in the database and explaining that it does not exist in the database, you do the same as I do but with an extra step of sending an email to an address that might not exist or is in the hands of some one with bad intention. I am sorry but I don't see the difference between your method of sending an email anyway and explaining the email address does not exit and displaying a message saying the email address does not exist.
would you care to elaborate why you prefer your method ?
 

[Jacques1]

at the moment the password is hashed with sha512 and then send to the server.

server side the password is salted and stored in the database.

 

You're hashing the password client-side? This is useless*. It means that the hash is the password. Anybody who knows the SHA-512 hash can log in, regardless of whether or not they know the original password. All you're doing is replace the user-chosen password with a different password.

 

So in any case, you need to send the password to the server via HTTPS and then hash it with bcrypt. There are some alternative authentication schemes, but they're too complex for an average website.

 

 

 

* For the record: Client-side hashing in addition to bcrypt hashing on the server does have a small benefit for the user, because it conceals their original password choice. If the same password is used on different websites, then an attacker who obtains the SHA-512 hash at least won't get free access to those other sites. But they do get access to your site. And as already explained, SHA-512 doesn't provide much protection, anyway.

 

 

 

by sending an email when the address is not in the database and explaining that it does not exist in the database, you do the same as I do but with an extra step of sending an email to an address that might not exist or is in the hands of some one with bad intention. I am sorry but I don't see the difference between your method of sending an email anyway and explaining the email address does not exit and displaying a message saying the email address does not exist.

would you care to elaborate why you prefer your method ?

 

The difference is that you allow anybody to check who's in your database. I only let people check their own address.

 

If your site is online, I could go to it right now and start trying out different e-mail addresses. Each time, your application would tell me immediately whether or not this address is registered. That's obviously a violation of privacy.

 

On the other hand, I don't tell visitors anything about an e-mail address. All I do is send a message to the address so that the owner knows if they're registered. This does not create any security risk at all. If the address is not registered, then I only tell the user exactly that: “Sorry, this e-mail address is not registered in our system. Maybe you've used a different address?”

 

Of course this does mean that my application might occasionally send unwanted e-mails to people who have nothing to do with my site. But every registration procedure has the exact same problem: Anybody can enter an arbitrary e-mail address, and then this person will get a message about their registration. There's not much we can do about that.

[anatak]

* For the record: Client-side hashing in addition to bcrypt hashing on the server does have a small benefit for the user, because it conceals their original password choice. If the same password is used on different websites, then an attacker who obtains the SHA-512 hash at least won't get free access to those other sites. But they do get access to your site. And as already explained, SHA-512 doesn't provide much protection, anyway.

 

 

On the other hand, I don't tell visitors anything about an e-mail address. All I do is send a message to the address so that the owner knows if they're registered. This does not create any security risk at all. If the address is not registered, then I only tell the user exactly that: “Sorry, this e-mail address is not registered in our system. Maybe you've used a different address?”

 

Of course this does mean that my application might occasionally send unwanted e-mails to people who have nothing to do with my site. But every registration procedure has the exact same problem: Anybody can enter an arbitrary e-mail address, and then this person will get a message about their registration. There's not much we can do about that.

 

I think I misunderstood your original explanation..
if a user enters and email address to receive a new token to reset his password there, you don't give any feedback on the site itself.
Then I understand the use of your logic.
I will probably copy that.

 

traffic of the site goes over https so I never really understood the use of hashing a password
I will probably use the logic you posted in the other thread.

 

 

thanks for the discussion.

Not a lot of people I can talk about that in my area.

[paddy_fields]

Just to play devils advocate here, but if you don't provide feedback to the user if an unregistered email adress is entered, then there is the chance they could slightly mispell their own email address and be none the wiser. They will then be waiting indefinitely for their email to arrive (you'd assume they'd try again after while, but still)

 

I completely undertand the privacy issue, but I think the level of importance may be down to what sort of industry the site you're making falls into?

 

I did some random testing on large well-know sites, such as Outlook, and Ebay, and they provide feedback when an unregistered email address is entered.

Edited June 10, 2014 by paddyfields

[Jacques1]

Just to play devils advocate here, but if you don't provide feedback to the user if an unregistered email adress is entered, then there is the chance they could slightly mispell their own email address and be none the wiser.

 

Yes. The same happens if you get your e-mail address wrong in the registration form.

 

But what's a minor inconvenience in a few cases compared to exposing the e-mail addresses of everybody?

 

 

 

I completely undertand the privacy issue, but I think the level of importance may be down to what sort of industry the site you're making falls into?

 

If the addresses become a target for spam, then it's irrelevant what kind of website leaked them.

 

For that matter, no, I don't think any website may expose e-mail addresses without the explicit consent of its users. Even the smallest and most irrelevant site is responsible for keeping its data safe.

 

 

 

I did some random testing on large well-know sites, such as Outlook, and Ebay, and they provide feedback when an unregistered email address is entered.

 

So? eBay also thinks it's a good idea to limit the password to only 20 bytes and block pasting, which means I can't use a passphrase and can't use my password manager without a workaround.

 

Many websites, including those of large companies, do incredibly stupid things. That doesn't mean we should do the same.