Possible Duplicate:
Can anyone provide references for implementing web application self password reset mechanisms properly?
I have website which sends generated password to any person who request it on website by entering email address.
I don't think this is a good solution, so I was wondering what is known to be most secure?
Also, I think I should run a dedicated machine to send and receive these mails I guess with rev dns and so on.
To be clear, I am looking to implement:
- Backend login, for administrator were he can upload new files
- Frontend for customers, were they can download files.
As I understand from the below answers:
For Frontend, crypted token is sent via email embedded into URL, and 1h window allows for user to enter new password via website. Now the note to this, that the request doesnt expire the previous password until it's changed.
For Backend, the same as with the Frontend, but the following might be added:
SMS Text confirmation via 3G/ethernet device (for registration and password recovery as with google, facebook and others)
- Payment Gateway confirmation via callback URL (for registration)
It is important to note, that the token should be random and crypted e.g. without repeated plaintext (same token twice), and the SMS gateway should use 5 random numbers, like 12345 to enter on the website.
The mobile text message seems OK since it's a nice backup for email confirmation, and it can be used in conjunction with payment gateway zero pound transaction or subscription, so you can buy services without spending anything, and then pay monthly for whatever usage generated pay as you go. So in this case SMS confirmation makes sense. This makes it really secure, as it's limiting number of cc and mobile numbers in performing the fraud, and helps to trace the abusers.
Psychological effect is an important factor as bad-intention hotlinking and page refreshing will be punished via additional costs and warning text and email messages.
Seriously text message is also good option for any potential breach and blockage, and unlocking the service, this might require a phone call and voice recording.
For this reason, that it's possible to steal resources, the best method is really to use something private which cannot be abused like email, which is in the public cloud.
For a customer management issues the mobile phone number seems to be the correct answer, and this is simply the method as it seems.
On Facebook and Google, this is used to prevent other people from accessing your data, so you are protected with SMS, so if you dont have backup account on school server, if your school server gets hacked, the accounts are not compromised, because it's impossible to breach like this multiple SMS numbers. This is especially valid for services, were there are business transactions used, there should be proper security like this.
Also delivering sms message is not a smallest problem, and you can have both mobile and email, text message takes second, and provides truly backup password recovery, which is best for customer management.
I have SMS client, and all mobiles in the DB, so I can switch new accounts to the mobile confirmation, it works like this:
./send_sms +44444444444 "12345"
And wait for user to confirm the token and then change the password.
From google:
Phone number Having a mobile phone number on your account is one of the easiest and most reliable ways to help keep your account safe and ensure that you can get back into your account if your account is hijacked or you forget your password. Your mobile phone is a more secure identification method than your recovery email address or a security question because, unlike the other two, you have physical possession of your mobile phone. Hackers target accounts without phones because they're easier targets. Add a phone and join hundreds of millions of other Google users who have helped stop hackers in their tracks.
Same applies for the backend interface, if it's business, if I hack it's exchange thru their cracked administrator account, I can obtain access to everything including facebook, leading to complete sabotage of online operations.
By having this on specified, and protected mobile phone number which is disconnected from the internet and lies on separate network is seriously a very nice option of protecting and ensuring availability of such workflow.
And the problem with changing numbers can be solved with update, like you have to enter token once a while, e.g. you can change number, but you dont forget the password, so if you forget and change number, then this is fully self-compromise which doesn't deserve support non-stop.
