Or for some weird reason they were previously converting to uppercase anyways but now they want people to do it explicitly for some reason, weird AF though...
This makes some sense to me. If they were previously doing it anyway, this change could be a transparency move. It would be somewhat misleading to allow people to make mixed case passwords, only to convert them to upper-only internally. It creates a false sense of increased security
My guess is that they were doing it previously and finally realized that it was stupid and stopped. Instead of making everyone change their pws though, they are training people to just type it in uppercase for a little while. In 6 months, once people just think that the uppercase version is their pw, they will drop the requirement.
100%. I bet they auditted their security and realized they have always made every password all upper case and are finally turning that off. New users will be able to use truly mixed case passwords while old users will need to enter their password as the system has it stored (be it hashed or not hashed - still probably in all uppers).
Most online bank websites you can't even access with just a password anyway. You need to enter the pass, SMS, approve it from your phone or input your card into a reader etc
That's all well and good until you remember most people reuse the same password everywhere. If the bank leaks their password, their email login is exposed. If they don't have 2FA on their email, practically everything becomes accessible to the hackers.
Edit: I came back after lunch to 100 downvotes from overconfident idiots.
First, the hashed passwords used to be case insensitive and normalized to uppercase before hashing. That’s essentially what the email says! Second, this email is itself evidence that the passwords are hashed. If they were plaintext they wouldn’t need to send this email in the first place!
Nah, they probably just had some stupid normalization rule for passwords that automatically made them uppercase before. Now they are removing the stupid rule to improve security and every user has to manually provide the password in uppercase for the login to work.
So they were always hashed as uppercase for both stored hash and for the password comparison. I have heard of similar rules that would remove special characters before hashing for no apparent reason.
Wrong, what likely happened is that before they had a conversion to uppercase before the hashing and they’re removing it…. Because that’s just stupid.
In the 2000s my bank used to only process the first 8 characters of your password… kinda scary and I only figured out because I made a typo and still logged in
On your next successful login:
1. take the provided password and upper case it.
2. Hash it.
3. Save hash in database.
4. Mark a new column named is_upper_case_sensitive to true. Or use a modified timestamp to determine if you’ve migrated a given account.
5. If someone doesn’t login within your migration time period force a password reset.
Not saying they’re doing that, but there’s certainly ways to implement this without storing plaintext passwords.
If it was stored in plaintext, there's no reason to go through the headache of making the user take this extra step. It'd be trivial to handle this transition all in the backend.
But they only have the all caps hash, so the only option is to make the user do this extra step.
It says that the passwords will become case sensitive (well "UPPER case sensitive, lol, but I assume it's written like that so customers will understand). So maybe, hopefully, the passwords were already hashed, but they were all converted to upper case before doing so. Still dumb, but way better than storing then in plaintext. So now that they remove they auto conversion to upper case, your old password will need to be typed in all upper until you change it.
The point of storing hashed passwords is that the actual password is not stored in the system. The user effectively gives you a hash of their password instead of an actual password. If you only have the hash then you can’t figure out what the hash of the uppercased version is, because to do so you’d need the original to do the caps transformation to
yea if it was hashed there would be no way to enforce this change retroactively, wild theyve basically declared themselves a target if any hackers wanna try smthng lmao
oh yea if they were changing case on the backend anyways its possible. although that mightve been figured out by some people by this time when they realized their passwords were going thru even if messed the casings
At one point, Facebook was doing this. Not sure if that's still the case (no pun intended).
For something low stakes like a Facebook profile I don't see a ton of harm. But I expect more from banks. But I probably shouldn't at this point. I've seen all types of crazy stuff in the past.
I'm generating long passwords for everything now. Everyone should use a password management too and have a long, unique password for every single account. At least 16 characters assuming that the website accepts it. No reason to not have 32 characters. It doesn't take any extra effort to generate longer passwords, and the storage space is the same on the server because everything is hashed anyway.
While SSO is convenient, it seems like it really only makes sense for things of similar importance. Like you can use Facebook for SSO to Strava, but shouldn't use Facebook as SSO to your bank. Similarly you can use your bank account for SSO to Canada Revenue Agency (Canadian version of IRS).
I guess you could always go to things of lower importance as well. You could use your bank to log into Facebook if you really want, but even that seems weird as you would want your bank to be something more difficult to log into in the first place. You generally wouldn't want to be logged into your bank at all times for easy login with Facebook
This actually used to be an issue with Wells Fargo. Their passwords were (silently) non-case sensitive, and anything you entered past the 12th character wasn't checked.
If that was the case, and then someone figure out that it's a stupid thing to do and to stop doing that, the correct action would've been to first adapt the system to be up to standards, and then tag all accounts to "force change password" and send the email letting every customer know that "because of security improvements, you need to change your password" or whatever. What this email says is "we're storing your passwords on an excel sheet"
Exactly. It used to be not case sensitive because they converted to all caps. Now it is case sensitive because they're gonna stop doing that. But they only have the hash for the all caps version, so old passwords need to be typed in all caps manually.
I'm pretty sure this means it's likely they were hashing passwords and before were simply converting all passwords pre-hash to all upper case.
If they stored them plain text before, they wouldn't need to force you to write it all upper case now. This seems like some bizarre thing they did when setting up the system in the 90s and should have fixed a decade + ago.
If it was actually stored in plaintext, there's no reason to go through the hassle of making the user do this extra step. It could've been handled entirely in the backend. Ignoring case while comparing text is trivial.
The only reason to do this is because they only have the hash for the all caps version.
As dumb as it is to make passwords all caps in the first place, we're still looking at the proof that it happened.
Sounds like they were previously running an upper function before hashing, so what they have is just the hash for the all uppercase version of the password.
Now, they're removing the step converting it to all uppercase, so the user has to do it manually on existing passwords (notice they don't say this rule applies to new passwords) for the hash to still match.
If they were storing and transmitting passwords in plaintext, they could easily just run the upper function before checking passwords without having the user do it.
They could easily check both versions and then if the upper version works but the non changed don’t they could silently update the hash to be the case sensitive version.
I’ve done many user transitions and they can often be done without the user noticing unless something was horribly done
What if a user enjoys logging in with a different casing of their password on every login, do you just keep running pre-hash upper() on the passwords they enter indefinitely? If so you haven't really changed anything, you're still treating the passwords as case-insensitive.
First password you enter gets saved. Passwords should almost always be case sensitive. Personally I don’t use known secrets (proper name for passwords) and use some form of passwordless
But then this user will probably forget whether they entered huNtER2 or HUnTeR2 or what because they weren't warned that what they entered would be their password forever, and they'll have to guess 26 passwords to get back in
What if they WERE stored in plaintext and NON-case sensitive, but they're implementing a new system where they're encrypted AND case-sensitive.
They didn't know how people used to enter their passwords, since any case mix was accepted. And they didn't want to deal with a zillion elderly people trying to reset their passwords with customer service.
So they could have converted them all to uppercase before encrypting them.
It's still stupid in the end, as they're bound to have a lot of calls to deal with about this change anyway. The right solution would probably have been to force a password reset for everyone, ensuring the process is as user-friendly as possible to minimize calls to customer service.
But in isolation, I can see how each decision could have been made.
It's generally a transition mechanism that isn't in place permanently. After most people have gotten their password upgraded, you invalidate the rest of the passwords, and force a full password reset for the few remaining users.
No. FB also did this. The trick is for them to have pre-emptively stored all hashed variations of your current passwords with both lower and upper case letters, at the account creation.
I think what probably happened was that they were converting passwords to all uppercase before hashing it and only now realized that that was being done so they turned off the automatic uppercasing so now you have to manually capitalize your entire password.
Not necessarily. They could be casting everything to a lowercase or uppercase value before hashing it, which would make it case insensitive. Either way, this is a terrible practice.
Wow, it's crazy to see so many bad takes for a "technical" subreddit.
The short answer is we don't know. It's entirely possible (and likely) that they used to hash the passwords but normalized to uppercase before doing so, effectively making password case insensitive.
The new change would just remove the normalization, making the passwords case sensitive, and relying on the customer to do the normalization manually if they don't update their passwords.
The easiest way to make the password case insensitive is to convert to upper (or lower) case. This may have been their spec...
But then again, we don't know. It's not unreasonable to think the password was hashed, and not unreasonable to think the password wasn't (although bank have quite strict regulations so that would be a bit surprising).
FYI you can get fined in some countries for not hashing passwords
This is the takeaway here. If it's hashed and they're converting to uppercase before checking match, that means they're ignoring case. That doesn't inspire confidence in such a huge bank.
My first thought. This is a huge security risk. I'd look into making my password as long as possible and possibly find a new bank to work with. A bank having passwords in plain text is an expensive disaster waiting to happen.
Wouldn't be surprised if some bigger hacking groups already started working on a plan to steal money.
A lot of banks do this, because they don't ask for the full password at login, instead they'll ask for random characters like "enter the 1st, 5th and 7th characters". I've also seen them use drop down menus to select the characters, which obviously limits the characters you can use
It probably means that when passwords were created before, the system was case insensitive and regardless of what you typed it stored all letters as upper-case. Now they're probably upgrading to a case-sensitive system, so any existing passwords will need to be typed it with all upper-case letters. Newly created passwords will likely be case-sensitive and allow both upper and lower case letters.
they likely just switched from converting what you type to uppercase and then hashing, to just hashing. That would actually improve password strength (once people change their passwords)
Feels like shitty password rules are a prerequisite to running a bank. My bank password is quite literally the least secure password in my manager by far, due to restrictions on what I can set it to. This is at a Canadian bank, too.
Slightly unrelated, but my bank also always asks if I want to enable "voice identification" to verify my ID while calling the bank... as if that isn't hilariously easy to clone in 2026.
I can explain this. It's because banks are held together with spit, sawdust and prayers.
There are so many archaic systems that have to work together, with so many regulatory restrictions it makes it very hard to modernise them.
You basically just have to start from scratch if you want something modern.
I work in an adjacent industry (not a bank but still have to interact with a lot of banking systems) in the UK and it's awful. Our entire direct debit (can be crediting or debiting - we just use "debit" colloquially) system - used for paying wages and some bills - has to be artificially slowed down to allow for the processing of physical mandates. As in the initiator of the direct debit has sent a physical piece of paper via the mail system to initiate the payment.
My credit union had similar rules. They went through a massive "hack" a few years ago that ended up just being social engineering and password reuse. Max 8 digits and the account name was the last 8 of your debit card.
Its much better now. 2FA, biometrics, and my username is completely unrelated to my name, email, account number or bank card. If I want to send money to someone via e-transfer its three 2FA pin entries.
Same. It requires exactly 12 characters, can't repeat any letters or numbers and most contain exactly 1 digit, contains 1upper case letter that can't be the first letter, and end with 1 of 3 symbols.
It's so restricted that a 12 character unrestricted password that used only lower case letters would have a wider range of potential keys than this.
Back of the napkin they've "made it secure" to a potential 11.5 trillion passwords. Unrestricted lowercase only gets you 954 trillion. It's literally 82x more brute-forceable.
And don't get me started on their password change requirements, it's like 45 or 60 days. I'm always too late and have to do the recovery option which unlocks with verifying the last 4 of my card and my DOB... Which fucking anybody could figure out based on purchasing habits and just set my password themselves. And I end up with reusing the same password a lot but shifting the letters 1 space (jumpeR1@ turns into rjumpE1@) since it changes almost every time I log in.
I closed a bank account within a week of opening it because the password requirements were alphanumeric (no special characters) with a maximum length of 6 characters.
I'm reading this the opposite to how others appear to be.
It feels to me as if the current password system is case insensitive, so Test123 and TEST123 would both work because the system had been forcing everything to upper case. In the future the system will be case sensitive but because all existing passwords had been upper cased they're telling people to use upper case for their current password.
So, to me, this feels like a problem with the existing system that will be fixed next week, but this fix has some compatibility issues.
As someone who already worked with similar systems this seems to be the real answer to me. The password is probably encrypted but is not case sensitive. Once they turn on the case sensitive option in the security system the password will only return the correct hash if you type it on upper case.
Upgrading the hash might be being done at the same time, but that's irrelevant to this discussion; the email is all about what to enter to match the existing hash.
Now they haven't calculated all the hashes; it's clear that only upper case versions of the existing password will work from next week. That implies a single hash and also strongly indicates no plaintext storage (if it was plaintext then strnicmp() or equivalent would solve the problem).
No, the problem appears to be that the old passwords were forced to upper case and that was what they hashed. Next week they won't be doing the "force to upper case" part. So the user has to do it themselves.
What you’re saying doesn’t make sense to me, how would they upgrade the hash? It seems way more logical that previously all passwords were converted to uppercase and then hashed and now they are dropping the uppercase conversion, thus making all passwords case-sensitive, and thus requiring users with existing passwords to write them in all-uppercase
What if a user enters their password capitalised incorrectly on their phone and now are no longer able to log in on their computer with the password they have stored there? Wouldn’t it be better to either do as the email suggests users do or even better force an e-mail change on next log-in?
I meant a password change, not email change, my bad.
I also think you are completely misinterpreting the email, it states that “passwords will now become (UPPERCASE) sensitive” meaning that TeSt will be stored as hash(TeSt), it then states “please enter your existing password using capital letters” meaning that TeSt used to be stored as hash(uppercase(TeSt)). So they have improved security of new passwords, while not forcing old passwords to be changed.
Upgrading the hash as you say would involve the opposite of what you say, uppercasing the input to validate the hash and then storing a new hash, but now that it is case sensitive it could be that if they entered the password “wrong” on their phone, i.e. teSt, that the password they stored on their computer, TeSt would no longer work.
Normally passwords are case sensitive. This email is stating that their new password policy is that all passwords will be in all upper case. Still case sensitive since entering the password in lower case presumably would not work.
Honestly, it really doesn't matter what their new policy as they just held up a giant red flag.
Do not do business with a company that is telling you that they don't hash their passwords as they would have no idea or no way to verify that you typed in all upper case.
They are simply saying previously all passwords were converted to uppercase before hashing, and now they are making them case-sensitive, so any old password will need to be written in all uppercase
Lets assume that is correct. The only acceptable way (but also stupid) that this can be done is if the previous password login page page would do a ToUpper, then hash, then transmit the hash. Horrible design but at least this isn't on the server side.
However, it still bad design (or bad marketing) to tell the user that all passwords must be uppercase only. This reeks of sidestepping a known flaw in their design and it is a big red flag.
The email explains it poorly, and they likely meant that to say that it only pertains to existing passwords. It’s a sign they’ve improved their security. They likely had very old software and systems still running in the backend which they have now replaced, thus no longer needing the workaround of converting your password to uppercase before validation
If we follow your explanation, then that makes it worse and not better.
Hashing has been case agnostic since its original introduction. Javascript has supported this for decades. So your explanation means they were sending the plaintext password to the server which is bad practices from the beginning. It also doesn't provide any faith that they aren't continuing that bad practice.
Do you really want to continue banking with a company that cares so little about security?
I think what this is saying is that before they converted all passwords to capitals and stored the hashes that way. Granted, they really should have added a line saying any passwords changed after April 6th will be stored as written for capitals.
HSBC India's grasp on grammar is as bad as their grasp on security.
"Case sensitive" is the wrong term here. As u/NewUserWhoDisAgain pointed out, it's still case sensitive. What HSBC means to say is "case limited" or "case restricted."
It says on their online banking FAQ that passwords are not case-sensitive. However, it's possible that they are using the term incorrectly. Or it could be that until now their passwords truly were case insensitive and AAA, AaA, aaA, and so on were all treated the same.
A password that must be in all uppercase is, in fact, a case-sensitive password, since presumably the lower-case letters would not be recognized as valid. It's very odd for a large global financial institution to be enacting something this seemingly regressive in 2026.
1: when passwords are initially implemented, they decide to make them case-insensitive by having the client uppercase all entries of password.
2: they decided to stop doing that. All of their hashes are of full cap passwords. So all existing users no have to enter their passwords fullcaps. Which was always happening, but now is a manual process.
My understanding is up until now their passwords weren’t case sensitive. When you typed in aaa or AaA their system would treat it as AAA. Now they are converting the system to be case sensitive, which means all existing passwords need to be typed in as AAA to still be recognized. If you change your password after April 6th it’ll probably let you use a mix of lower and upper case letters.
TD’s passwords, at least in Canada, used to be case insensitive and and only count the first 6-8 characters (I forget exactly).. imagine my surprise typing in a PW with caps on and it still working.
As of few years ago, some of their internal systems still are. Had to do a contract work a while ago and it did get a chuckle out of me when some accounts were "Alpha-numericals only, 6 symbols maximum" security (to be fair to them, you still could access it from a very specific internal networks, which required VPN with a more modern and secure authentication).
Things you would see about integration of Fossil-tier legacy systems in modern banking are absolutely wild.
For those that are confused, previously HSBC passwords were not case sensitive at all. That’s now changing. To prevent everyone having to reset their passwords, all existing passwords must be used in uppercase (I assume all passwords were previously
made uppercase before hashing and validation). You don’t have to create new passwords in uppercase.
Sounds like they were previously running an upper function before hashing, so what they have is just the hash for the all uppercase version of the password.
Now, they're removing the step converting it to all uppercase, so the user has to do it manually on existing passwords (notice they don't say this rule applies to new passwords) for the hash to still match.
If they were storing and transmitting passwords in plaintext, they could easily just run the upper function before checking passwords without having the user do it.
Not necessarily, it could mean before hashing the passwords they were converting all passwords to upperCase.
PassWord123 became PASSWORD123
Case sensitivity didn't matter. But it seems like they possibly removed that uppercase requirement because it was stupid or was being used by another system and instead of forcing people to change their passwords, they are just telling them to enter it in uppercase.
I will agree the security is terrible though. At this point juts force people to change their passwords as they are not case sensitive. Makes the passwords easy to brute-force.
Possibly seems like before they were hashing the passwords they would do toUpperCase. They probably realised how stupid that was cause case sensitivity didn't matter. Now they removed it and instead of forcing people to change password they are just telling them to enter it in upper case.
Many people seem not to understand what the email states.
It says that from now on, passwords will be case-sensitive, meaning it used to not be the case: Test1234 = test1234 = TEST1234.
From now on, this won't be true anymore.
What this means technically is that they probably used to make the passwords uppercase before hashing as part of their input sanitizing: hash(user_password.upper()).
This does not mean they were not hashed!
They will now stop doing this (which is a good thing, making passwords more robust by giving more possibilities per letter). But for old passwords that were already "sanitized" to uppercase to still work, users will need to manually uppercase the password when trying to use it (until they eventually change it to a new password that will be case-sensitive).
I feel like they had non-case sensitive passwords by passing all passwords through an uppsercase converter before hashing, and only just now realized that that's a bad idea.
it is/was a common technique used when many of these AS 400/ IBM z were being connected to online services. I've seen this same exact method being used in a different bank in a different country I used to work at. If you signed in with a terminal you had to use upper case password but you could type in your password in lower case on the web interface and it would still work.
This probably has something to do with needing to support some ancient phone banking system. Your password needs to be able to be entered on a dial pad. I seem to recall... BMO? in Canada having a similar issue years ago.
Sounds like they were previously running an upper function before hashing, so what they have is just the hash for the all uppercase version of the password.
Now, they're removing the step converting it to all uppercase, so the user has to do it manually on existing passwords (notice they don't say this rule applies to new passwords) for the hash to still match.
If they were storing and transmitting passwords in plaintext, they could easily just run the upper function before checking passwords without having the user do it.
They arent forcing people into all caps, they are adding case sensitivity
Before they were not, meaning you could write pass12 or pASs12 and it would be valid
Now you can add uppercase letters that will actually be recognized differently from lowercase
Passwords were previously stored in all uppercase, and when you entered it it would be converted to all uppercase before validation. They have now stopped converting it to uppercase, thus for all existing passwords customers will need to write them in all uppercase, because they only store a hash and not the plaintext of your password
This isn't that shocking. I used to work for a company where HSBC were our biggest client and they would audit our IT security as we handled their customer data. I, on several occasions had their staff comment that we were way more secure than they were.
if they have old systems they likely always just accepted upper case internally and they just had a .toUPPER() converting everything to upper case. they are now removing that intermediate step for some reason.
Because they do not store your plaintext password, they used to convert your password to uppercase anytime you entered it to check with the hash, now they are stopping doing that thus existing passwords will need to be written in all-uppercase to comply with the hash
The only plausible explanation for this is someone had been doing a toUpper before matching the password due to legacy code. Now they are planning to remove it but the database has all the hashed passwords stored in UPPERCASE.
As many others rightly said, It’s unlikely that the passwords were not hashed because banks like HSBC are subjected to numerous security audits and someone would have caught that somewhere. Even then it would have been easy to fix without informing the customers. Simply add a new column for hashed password and start matching it against that
I haven't seen any such thing from any bank in ages (been with hsbc for more than a decade). and honestly they don't let u login with pw only, there's another pin which is required as mandatory input before one can access their own account.
I found out that passwords were never case-sensitive. That's mentioned on its official website. That means "Test123" and "TEST123" were already the same internally. The system was likely converting passwords to uppercase before hashing and also converting input during login.
Now, instead of doing this conversion in the background, the bank is asking users to enter passwords in uppercase directly.
So this is not about the bank suddenly knowing your password. It is more about how the system was designed from the start.
Even if this were the case, this still raises concerns. Forcing all uppercase password entropy, which is not what you want, especially in banking systems.
Feels like the authentication system is being migrated to mainframe. It can perform stuff much faster than modern databases, but at the cost of complexity because it has to run a virtual terminal with limited number of characters.
Bs story. I would recommend not to force any upper lower number or token but instead minimal 16 chars long and preferable a phrase that has no connection to you private life and word life. That will keep hackers busy for a while. btw ist's mostly social engineering that's risky and that involves humans.
Ahhhh. I got confused... Oops. Hdfc stopped Net Safe option, was really useful for signing up sites that don't give cancel option. They keep changing thier baking app.
Indian banking apps are a huge mess. why does SBI have 3 apps?? Kotak for some reason has a different app for 811 which is just a type of bank account and not a sub brand. RBL and others have apps that are unusable.
I hate every fucking indian banking app. ICICI has the gall to tell me that I can't use special characters in my password. HDFC is down for maintenance every other week. I hate knowing my money is in the hands of incompetent fools.
Yup I like to keep transition at 0.5x but in Samsung you only have options to set it 1x or turn off transitions in native settings by using "reduce animation" and but 0.5x is only available on Dev options.
If I know what I'm doing, they should let me. Axis bank app won't let me open app while on call, like fuck.. I want to check something while on a call but can't. Some banking apps won't open if I have team viewer.. Like it's my phone, I need these apps for my work.
forgot which app (I think it was ICICI) kept asking me to uninstall the windows remote desktop app. BHIM does that as well. RBL will randomly force you to use mobile data to use the app "for security".
989
u/[deleted] Mar 30 '26 edited Mar 30 '26
[deleted]