Try as I might to contact Wells Fargo regarding an almighty issue of issues regarding their authentication logic.
So let’s say your password that you set purposely to “SuperDuperPassword” or better yet your actual password if you use Wells Fargo you can try this at home. Back to the monologue; so you want a secure password for your account? Who wouldn’t? So you add lower cases and upper case into the mix. Try to make your password all sexy and shit right?
Now imagine this, none of the complexity that you created means anything. Login to your account with all upper case, lower case or mixed case it doesn’t matter.Click here to Read More
Now take into consideration that the minimum password length is 6 and max is 14, certain special characters disallowed, and not case sensitive… honestly without any sort of lockout you could easily brute force probably a quarter of their customer’s accounts.
TLDR; Wells Fargo login does not check case sensitivity for passwords. If you care to read on for more technical information and theory behind some of these assertions and assumptions you’ll find that below.
All of this begs a pretty interesting question regarding how these credentials are handled on the backend…
Suppose I set my password to SuperDuperSecurePassword (Thats hoping they didn’t set to all lower or uppercase at first set). Now picture your password being stored on the backend in a super secure manner, generally you’d want to hash and salt to store it so users can login. Hashes are exact matches of a certain string or value, there are ways to force a collision in some instances but that is in a attacker scenario, not a banking app.
Alright back onto it; the following are hashed values of various formats of this super secure password we made based on our original password.
***Case Sensitivity Test***
SuperDuperPassword – Our original password
ED1170E378F9D2204CB0EE0678E6EAFA – MD5
F67B8C584323A9C12DD0469E3CA0E1C18A24944E – SHA1
E0B9072ACCFA63F4D754CDD0D2753F8BA8B387ECECE625AEAD1E6D9873DED463 – SHA256
superduperpassword – all lower case
3F0F04576E1BC3ACF916BFE3E63C075F – MD5
50B0FF56A91F64D21C8A7FFD2E3FF7A8B2C184AE – SHA1
2EF0ECE59A893120840BCCE18264C9A88EF4F6F80695FC9D472A389770FB2FF4 – SHA256
SUPERDUPERPASSWORD – all upper case
F8FC15E5771FEEA832BF5614388F8201 – MD5
F0204A6BE2D28B317818F7655127A58334D3C31A – SHA1
1A79FD55DACEEB24AE7B11E946B8174C40E83634D7DF11F5CBB25D6BD300EE5D – SHA256
Note: All these password strings in this scenario would be accepted by the application without question.
Now given that the web application allows passwords to be case insensitive we can establish that there is no way the password being sent is being matched by hash (which says all sorts of scary things about the backend) and is instead being looked up possibly by plain text.
Another theory of mine is that all passwords are set as either all upper or lowercase. After which the hash is generated by that string in a controlled environment and is then stored. Then at each login regardless of case, all passwords are made either all upper or lowercase and then the hash is generated and then queried in the database.
Realistically the above is more assumption based on observations and assertions, however the fact remains that somewhere in the logic between the database and the web app passwords are not case sensitive in any manner.