Skip to content

How to test password feature in web application?

Password_Lock_Security_TestingPassword enforcing rules

Not all users know about threats in security space. It is important for companies to enforce password rules to take care of user’s account not being compromised by attacks such as brute force dictionary based attack. Providing the rule like, at least 1 capital letter, 1 lower case letter, 1 special character and totally 10 minimum characters would safeguard them better.

 

Case sensitive versus case-insensitive passwords

Usernames may be case insensitive while passwords are not recommended to be case-insensitive. It is just like this, a person who is opening the door can change his appearance however; key to open the lock need to be same and should not be changed with respect to the keys teeth. Case-insensitive passwords are highly vulnerable compared to case-sensitive passwords.

 

CAPTCHA to avoid brute force

Most of the hackers love to see login form without CAPTCHA as it is easy to do automated password requests using software to crack the password. Account lockout policy or CAPTCHA is efficient way of securing your users account from being compromised.

 

Make sure you transmit password under SSL

HTTPS / SSL makes your password to not be seen as plain text by sniffing by malicious hackers who can steal the password and username which flows over the wire once the login form is submitted.

 

No maximum length restriction

Good to have a minimum length validation however, maximum length restriction should not be set anywhere less than 50 characters. It is seen some companies restrict it to 16 even though some users wanted to set more than it using a pass-phrase to have comfort feeling.

 

Change Password need to ask for Old / Current Password

Many web applications tend to not ask for old / current password while setting new one. Considering security, it is important to enter current password and then new ones to validate if the user is genuine owner.

 

Forgot Password Link Expiry

Important to expire the link after one use is a standard to avoid re-use of it by malicious hacker. Also, irrespective of whether the link is used or not, expire it after 24 / 48 / 72 hours based on business context. Last, but not least; check if the token value in the URL is at least 64 characters to avoid brute force. OWASP standards for forgot password is great source of information.

There are more tests that you could do with password feature. This is a kick-start for those who want some quick test ideas to test password feature.

SanthoshTuppad

I have been as a software tester for over 5 years. I am a hands-on tester and I've been winning bug battles & testing competitions across the world. I am a testing enthusiast, who conducts free workshops on security testing across India (Covered locations: Bengaluru, Pune, Hyderabad & Chennai. Invite him to come to your location), and monthly meets for testers in Bengaluru. I am also an avid testing blogger.

My interests include traveling, driving my SUV, health & fitness and many others. I mentor budding entrepreneurs, testers, teams in any profession.

Latest posts by SanthoshTuppad (see all)

Share/Bookmark

12 Comments

  1. Anand Ramdeo wrote:

    Nice article Santosh.

    There are few more simple things i normally try for checking password

    – Error messages for wrong password / username combinations
    – Simultaneous access from different devices / browser
    – JS disabled mode
    – Appropriate authorisation (If applicable)
    – Leading, Trailing white spaces and unicode characters

    and so on..

    Also, password checking is one thing which is often not covered in automated testing. One of the reason I created RESTFul interface for getting string based on Regex (At http://www.TestSpicer.com) was to use it during registration process.

    In my experience, I have often seen same password used for all the tests, however it would be much better to have different password for every execution to increase sample size in automated testing.

    Tuesday, December 31, 2013 at 1:02 am | Permalink
  2. Thank you Anand :)

    Tuesday, December 31, 2013 at 3:36 am | Permalink
  3. Tejas wrote:

    Nice Article, Got to know many usability points related to Security.

    Tuesday, December 31, 2013 at 2:40 pm | Permalink
  4. Deepak wrote:

    Hi Santhosh,
    Again an informative article from you.

    We try to implement as many rules as possible for PW field. But the thing that bothers is, on an average, a user may need to importantly remember at least 10-15 passwords and maybe 5-10 more for not- often used apps.

    The common problems of a user:
    1) How do I remember all these if every pw has to be unique?
    2) How do I remember if I need to choose a combination of CAPS, normal, number, spl character for every unique pw?

    Of course some solutions like OPENID or PASSPHRASE exist, but if even pw is tough to remember, maybe we can’t expect to remember many passphrases.

    As a tester, I am also inclined towards usability. Please let us know any additional info/articles/research resources related to this which provide user BOTH SECURITY AND CONVENIENCE?

    Tuesday, December 31, 2013 at 5:34 pm | Permalink
  5. Deepak malladad wrote:

    Good Article:)

    Wednesday, January 1, 2014 at 9:28 pm | Permalink
  6. Deepak, Here is what I think for the below questions.

    < <1) How do I remember all these if every pw has to be unique?>>

    < <2) How do I remember if I need to choose a combination of CAPS, normal, number, spl character for every unique pw?>>

    One of the thing that I do is, I keep a pattern for the passwords with slight or bigger change which I can remember. We all can remember the passwords very well, but we do not practice. Remember, how we used to memorize so many answers or formulas in our school days :) It is just we are not used to it. I remember at least 100 passwords.

    Also, pass-phrases are good to remember. I remember keeping my IRC passwords like something below,

    “OurE@rthIsGre@tAndIsThe1stPl@netWhichH@sLife”.

    I have mixed set above. This depends on the memory of individual. As all brains store things differently, in my opinion; one of the solution is to practice or find a way by themselves.

    Also, if I forget passwords that doesn’t really bother me as I am comfortable using “Forgot Password” every time. It doesn’t take much time for me and I need not memorize it for applications which I do not use frequent enough.

    To add “Security” I would personally enforce password rules while to add Usability I would see “Forgot Password” is not buggy and is very well designed which could help end-user to use it efficiently and set new password quickly.

    Thanks for your comment :) and I am glad you liked it.

    Thursday, January 2, 2014 at 4:22 pm | Permalink
  7. Pradeep Lingan wrote:

    Nice article Santhosh. I have few more points that I consider while I test password.
    1.Asking to enter current password twice.
    2.Characters encrypted.
    3.Avoiding plain text.
    4.Current password and old password match.
    5.Number of time restriction to reset password per hour(probably).
    6.Java script enabled/disabled

    Thursday, January 2, 2014 at 11:59 pm | Permalink
  8. 1. Why 10 characters as minimum instead of 6 (which is common) ?
    2.CAPTCHA to avoid brute force
    I couldnt find any ecommerce website which does like this.Is it compulsory?
    3. Is it compuslory that we need to set not less than 50? – Any attacks for this reason?
    4. Is it good to send Username and password in a mail ?

    Friday, January 3, 2014 at 8:40 pm | Permalink
  9. 1. Why 10 characters as minimum instead of 6 (which is common) ?

    It is concept of Brute Force attack. 6 characters combinations are comparatively lesser than 10. However, 6 characters are more vulnerable and to make it difficult for attackers, it could be made 10. However, it depends on what monitoring that the company is doing whenever brute force attacks happen. So, it can give time for the company to monitor when it is set to 10 instead of 6 characters which could be cracked and by the time it is monitored, customers account is already compromised. There may be many other reasons which will impact on deciding whether we go with 10 characters or more or less.

    2.CAPTCHA to avoid brute force

    Nothing is compulsory. Some people implement CAPTCHA when they see lot of spamming or bot registrations are being done. Some people have it from day 1 of the launch itself. Some people will not implement itself as they have a team which keeps cleaning all the junk.

    3. Is it compuslory that we need to set not less than 50? – Any attacks for this reason?

    It is again not compulsory. It is more of what survey the company does on passwords set by different users [Target audience]. It can be even 100 too based on some other deciding factors. However, it gives more freedom to users to set maximum characters. In my experience, I have not seen people exceeding 50 characters as password except me :)

    You might even remove the max attribute itself for passwords if your system can handle lot of data when a lot of data is entered and submitted for malicious purpose [To crash the database or cause some problems in database or server].

    4. Is it good to send Username and password in a mail ?

    Considering shoulder surfing [Social Engineering Attack], I wouldn’t do that if I were to develop a software. All Password need to be set from Application itself. There are other problems like where anyone can annoy the customer by using Forgot Password e-mail and resetting the password automatically even when the genuine customer had not forgotten it.

    Also, if the software is sending the same password instead of resetting, it can give hint to hacker that; password is not being hashed in the database which may provoke him / her to exploit or initiate hacking the database itself.

    May be one can send the username in the e-mail or it could be done even from the application itself. This is what I can think of now in the given time while I was typing this comment :)

    Thanks!

    Monday, January 6, 2014 at 5:04 pm | Permalink
  10. Some months back, I have comented the same: I got the reply as “If they send you your password that you had saved rather than a temporary key to reset the password, that means they are not behaving very badly. The actual password should not be saved in the system. A salted hash should be saved in their systems instead of the actual password.”

    Monday, January 6, 2014 at 7:46 pm | Permalink
  11. I guess I did not understand your comment completely. However, here is my answer to whatever I understood. OTP (One Time Passwords) can be sent to the user which acts as temporary key and at this time the actual password is not changed in the software. Only when OTP is used and then the password is changed, then actual password is changed and new one is set. There could be different implementations as well. This is just an example of what I conveyed.

    Yes, Salted Hash needs to be saved in the software instead of actual password. Please ping me on Skype if you want to discuss more on this.

    Tuesday, January 7, 2014 at 3:22 pm | Permalink
  12. Santosh, very nice article on testing passwords!

    Saturday, February 1, 2014 at 3:49 am | Permalink

One Trackback/Pingback

  1. Testing Bits – 12/29/13 – 1/4/14 | Testing Curator Blog on Monday, January 6, 2014 at 6:34 am

    […] How to test password feature in web application? – Santhosh Tuppad – http://tuppad.com/blog/2013/12/30/how-to-test-password-feature-in-web-application/ […]

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*