Skip to content

Password – Flaws / Risks / Design suggestions and more

This blog post will try to educate you on vulnerabilities / problems / issues with respect to “Password / Forgot Password / Change Password and etc.” & give you hints on how you can start learning to help yourself in your testing activity.

Here I go,

When I forget my password, the first thing that, I think about is to get it back through “Forgot Password” / “Reset Password” / “Retrieve Password” feature which the product provides. Here, in this blog post I am going to talk about the risks associated with some of the design which I have come across. You might want to consider them as issues / design flaws / bugs etc.

Here are few problems / vulnerabilities that I have come across ranging from low severity to high.

1.       The button says, “Retrieve Password” but in my e-mail I get the password which is reset by the system. [What does retrieve mean? What does reset mean?] – Low Severity

2.       Once I saw that I had changed my e-mail address from my account settings, the old e-mail wasn’t wiped from the database records. When I invoked the reset password, the password was sent to both the old and new e-mail. Bad stuff! I had changed the e-mail because it was cracked by hacker, and now the system is sending the password to old e-mail unknowingly by helping the hacker to get the credentials of this account as well. – High Severity

3.       If you have been using WordPress, you must know that the maxlength of password is 20. Let’s say I have set the password for my username as 20 characters. Now, the hacker can easily cut down the difficulty level by using Forgot Password [Here, it is designed to reset the password to 12 character]. So, now you see it is brought down to 12 characters from 20. Wow for a hacker! – Medium Severity

4.       Claims test: While registering they claim to enter at least 6 characters and they even have a validation. But, after registration I could go to my profile and change the password to 1 character. [Oracle used: Inconsistency within the same module in different areas]

Few considerations by the design team or requirement team,

1.       Minimum characters to be entered for password / Maximum characters to be entered for password [ If there is no maximum, then think about what are the risks when end-user enters many characters as password – Let’s say 1,000 or more ]

2.       Password strength indicator – It should be a complex algorithm. I have seen applications where by just using a1! Is treated as Very Strong password. Even though they want minimum characters as 6 the password strength indicator indicates that it is a very strong password and valid one.

3.       Consistency in “Change Password” in all the different areas

4.       Front-end and backend validation of Password maxlength

5.       Encryption techniques used while transmitting the password over the web

6.       Hard for the end-user to understand how the Password Strength indicator works

7.       Using _GET_ method for login form might be a BOOM!!! If it’s _POST_ method then after submitting the form the password can be seen in the URL. If the history is not deleted then the other user might get to know the password and get the access in an unauthorized manner

Tools / utilities / add-on that you can use to help in your testing activity to find the problems / issues / bugs related to Password,

1.       WireShark – Network Monitoring tool

2.       Fiddler – Web Debugging tool

3.       HexEditor / WinHex

4.       Behind the Asterisks – Mozilla Firefox add-on – This add-on helps you in looking at the password as plain text when you move the mouse pointer to password field [ All the masked characters will be shown as plain text – This could be used for identifying the boundary value as well – Think about it ]

Learning that you might want to have,

1.       About hash algorithms / Reading books on Cryptography

2.       Learning about encryption / decryption in different technologies like Java, PHP, Oracle and more

3.       Practicing Security Testing at – I personally consider this as basic level practicing for the newbie

4.       Using brute force attacking tools and trying to crack the password [Learn to use it in your test environment, don’t use it on any product without the permission until and unless you are a BlackHat Dude :D]. Example: Brutus, John The Ripper, Dictionary Attack Tools and many more – You got to have exploring skills in you. If you do not have, then start exploring now.

Few questions that you might or might not have asked to yourself,

1.       When I submit the form, how exactly is the data being sent over the network?

2.       Desktop Applications – Is the password being stored in any file in some location or in stealth mode

3.       In LAN, if someone is using WireShark or any network monitoring tool, can they see the password which is being submitted by some “X” user?

4.       System allows storing 1 character as password, any problem?

5.       How much is the coverage on Password which I have done? How many types of character set exist? What might happen when Chinese / Arabic character set is used in password text field?

6.       Many more questions – You get more questions when you educate yourself by learning more about passwords

For any questions that you might have please leave a comment or write to me at Santhosh [dot] Tuppad [at] gmail [dot] com or tweet @santhoshst.


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)



  1. Raghavendra Pujar wrote:

    Hi Santhosh,
    I did not understand the “Front-end and backend validation of Password maxlength.”
    Can you please explain this?

    Monday, January 10, 2011 at 5:19 am | Permalink
  2. @Raghavendra,

    Thanks for asking your question.

    Front End Validation & back-end validation
    Let’s take an example where there is a login form with username and password text fields. The password text field boundary value is 10 and that has been written in the code which looks like, “”

    Now, you might want to see if editing that value using Firebug add-on or any Developer Tools would break the front-end validation. You change it to 20 from 10 and then enter 20 characters as password and submit the form. If the password is accepted then it means there is no back-end validation done in the database.

    So, the developer had just used maxlength in the login form but had not included 10 characters size in the database.

    I hope this answers your question.

    Let me know if you have any question(s).


    Monday, January 10, 2011 at 5:31 am | Permalink
  3. Awesome post Santosh I liked it lot.

    Keep up the good work.

    Tuesday, January 11, 2011 at 8:17 pm | Permalink
  4. @Nitin, Thank you.

    Wednesday, January 12, 2011 at 11:40 pm | Permalink
  5. > 7. Using _POST_ method for login form might be a BOOM!!! If it’s _POST_ method then after submitting the form the password can be seen in the URL. If the history is not deleted then the other user might get to know the password and get the access in an unauthorized manner

    I guess there is a slip of pen. It should be GET method.

    BTW, I have experienced some other issues during my forgot password type of testing:

    1. Very rarely found in the forgot password page, when an email address is provided, the email is matched using like query (WHERE email like ‘%forgotemail%’). Severity: High

    2. The reset password link sent to your email account never expires. I mean you can reset password using the same link multiple times. Severity: High

    3. When a username is asked in the forgot password, sometimes the corresponding email address is shown saying that “your password has been sent to“. This is terrible because many of the sites ‘admin’ is a default user. The hacker may not know the corresponding email address used for ‘admin’ user. Then he can try the forgot password and know the email then try to hack that email address. Severity: low

    4. Forgot password option is a good and easy accessible place where hackers try to inject SQL. So this place should be SQL injection safe. Severity: High

    5. The password reset link is sometimes found as changepassword.php?uid=23415. Be careful about this bad user will definitely try uid=1. Severity: High

    6. Funny bug, I found in one of the applications that asked for my old password while I tried to reset my password using forgot password. Severity: High

    Smart and secure application may ask some other information like security questions, last four digit of your credit card while resetting the password using forgot password. This way an application can save a victim’s account who’s email address has been hacked.

    Just like other field, password should also be trimmed SPACE in both side if space is not allowed as password character.

    If you register using a password combining single quote and/or double quote, there’s good chance that you will not be able to login to the system next time. I found this problem in some PHP applications I tested. It’s because of not properly using addslashes() function.

    Some application forces to use only numbers as password (a local bank in my country do this). And the numbers must be 8 characters. This is not good at all. Things goes to worse when the same application forces to change the password bi-weekly. And finally it becomes worst change password form do not take last 3 used passwords.

    Many more to say…

    Saturday, January 15, 2011 at 3:20 am | Permalink
  6. @Monirul,

    Err, you are right. Thanks for noticing it and letting me know :) *Now, it’s corrected in the blog post*. Thanks!

    Sunday, January 16, 2011 at 12:30 am | Permalink
  7. > 7. If it’s _POST_ method then after submitting the form the password can be seen in the URL.

    Did you notice you fixed it just one place but the other one remained untouched :). The similar problem we see among developers, when a bug is reported they fix the one they only see.

    Monday, January 17, 2011 at 5:11 am | Permalink
  8. Prashanti wrote:

    Hi Santhosh,

    I just love your blog. And congratulations on starting Moolya

    Tuesday, January 18, 2011 at 10:25 pm | Permalink
  9. Thanks and I am glad to hear, that you love my blog :)

    Tuesday, January 25, 2011 at 11:50 pm | Permalink
  10. @Monirul, I cannot comment on that. I can treat it as, “You read whole thing and you did not find anything else” and that is why I did not think of reviewing.

    And it was not in the priority list of mine. There are several reasons and it is not similar problem that you see here which you have seen in developers. Context is different. No comparison.

    To keep it simple, you reported and I fixed :) That is all.

    I personally do not compare any thing like that. Developers might be busy with other tasks and may not have seen that because they aren’t testing due to whatsoever reasons. So, we do not call it as a problem.

    Everything depends on the context :)

    Tuesday, November 26, 2013 at 10:33 pm | Permalink

One Trackback/Pingback

  1. […] This post was mentioned on Twitter by Santhosh Tuppad, Santhosh Tuppad. Santhosh Tuppad said: Password – Flaws / Risks / Design suggestions and more via @AddToAny […]

Post a Comment

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