Has some one experience in “Reset password” testing. What is the best efficient way ?
The efficient process is to specify the reset procedure upfront. Make sure you answer the following questions:
- are we asking for a username or an email or both?
- are team administrators involved in approving the password reset procedure?
- are we asking additional questions to validate the authenticity of the reset request like what is your full email (showing j***.**e@x**l.com for firstname.lastname@example.org)?
- do we notify about non-exiting username/email reset request?
- how long are we allowing the reset token to live?
- do we allow one time usage of the reset token?
- what is the procedure for an invalid reset token?
- what is the procedure for an expired reset token?
- do we allow previous used passwords?
- do we enforce strong passwords?
- do we stop the session after a successful new password creation and have the user authenticate again?
- do we notify the user about the new password creation? If yes, which forms of notification are used/required?
- do we need to propagate the new password on other systems as well?
Once you have clear answers you can work out test cases you execute.
I hope this answers your question a bit.
Thanks Michelangelo your questions are very help full :-). Greetings from the sunny Netherlands
I agree with Michaelangelo that you should understand and scrutinise the procedure first. I’ve had experience with a password reset procedure that “worked” as originally requested, but what was originally requested was grossly insecure.
For example, all new passwords sent via email and generated from a limited bank of saved passwords… No requirement to mask the password when the email was recorded on the system notes…
It “worked” but it was awful. Test the requirements as well as the product
Thanks Cassandra for the great tip
“do we notify about non-exiting username/email reset request?”
We do not. Under any circumstances. Anything other than an actual communication failure should be treated as a success with an appropriate 200 returned. It is a data leak and a security hole otherwise.
By the same token, we should always return a generic authentication failure on login regardless of whether it was the username, the password, or both that failed. Again, this is a data leak and enumeration vector for attack.
Reference in the same vein - https://www.owasp.org/index.php/Testing_for_Account_Enumeration_and_Guessable_User_Account_(OTG-IDENT-004)
Hey @davidshute, I completely agree with you about best practices and improved security, but I still see lots of web applications presenting a nice error if the email address is not found. Nicest example is at pingdom.com.
So stepping away from security aspects, if it’s a business requirement you still need to test for it. And some sites send you in clear text your original password which is even worse, but these sites still exist and are hard to ignore them.
Usernames and Passwords are very essential for creating any account like email accounts, Social websites accounts etc. Nowadays, e-commerce is growing very rapidly and we need to remember a lot of passwords. So, ‘Reset Password’ is very important aspect for every application. Most of Software testing companies pays a lot of attention to test this. To test ‘Reset password’, we generally perform following steps :
- ‘Reset Password’ link should be displayed on Login screen.
- On clicking link, ‘Forgot password page’ should gets loaded.
- For most secure sites, following click-able options are displayed:
a. Security Questions (Questions with answer are submitted during registration) like Favorite teacher name, Birth place etc.
b. OTP verification (Mobile Number saved at the time of registration).
- Clicking ‘Security Questions’ link, directed to ‘Security questions’ page on which adding correct answers leads to Next (Reset Password) page.
- On Clicking ‘OTP verification’ link, directed to ‘OTP verification’ page where on adding correct OTP code from registered mobile number leads to Next (Reset Password) page.
- Contents available on ‘Reset password’ page are:
a. New Password with editable field
b. Confirm Password with editable field
c. ‘OK’ click-able button
- Criteria applied on both ‘New Password’ and ‘Forgot Password’ fields should be like (Its not mandatory):
a. At-least six characters
b. At-least one ‘Numeric’ data
c. At-least one ‘Special’ character
- On clicking ‘OK’ button after adding correct and same data in both ‘New Password’ and ‘Confirm Password’ fields, pop-up message for ‘Password successfully changed and now login again’ link appears.
- On clicking ‘Login again’ link, helps in redirecting on main Login page.
- Check that, user able to login to the account with new Password.
Hope this information will be helpful for you.
Hi @soconnor2017 it can be automated to make testing more efficient. Create a test login on sign up and use some free temporary email service like Guerrilla Mail (using a long, randomly generated email address). Then you can automate the password reset functionality and automate the checking, as it is all web based.