Hacker News new | ask | show | jobs
by reaperducer 2576 days ago
A couple of years ago one of my banks "upgraded" its web site, forcing me to change my password to comply with its revised password guidelines since my old password was no longer permitted.

The result was a password that was shorter, less varied, and less secure than the previous one.

Good job, Chase.

4 comments

I had a similar problem with Lloyds - every time I wanted to transfer money using the mobile app, I had to type in the password manually as they had disabled the "paste" option. Given my password was auto-generated and 16 characters long - and the password field wiped every time I did an app-switch, I just gave up.
It's very disturbing to see that your worst passwords are for your bank accounts. Each bank I've worked with has some weird limitation like this. Not to forget that the only form of MFA that most banks allow is SMS - assuming they even offer MFA.
Banks are probably still running on the old mainframe (old as in upgraded in 1998 when y2k forced it), with password storage that was state of the art in 1960 (plain text, but the file is actually protected well so hackers can't get it). That isn't to say better password cannot be used, just that they have never enabled it.
I don't understand that - I get that the system that holds the data is old, but when creating an online banking system shouldn't the piece that holds the data be a good half dozen steps removed from the website and authentication?
Not if you want a single sign on. Of course customers only use the web login, but internal people have to deal with all these different logins.
I have a Keepass app on my phone, Keypass2Android:

https://play.google.com/store/apps/details?id=keepass2androi...

It has a keyboard bundled into it that will ghost type in the currently opened username and password. Works awesome for stupid stuff like your story.

> my old password was no longer permitted.

But how did they know? They should just have the hash...

If they implemented it properly they could have checked the current password against the revised guidelines on the next login. No need to store it in plain text
The website can check the password during login without storing it in plaintext
The login form usually sends the password in cleartext and it's then hashed on the server-side prior to comparing it to the hash stored in the database.

So they can just determine the password's strength at the time when the user is logging in

FirstDirect's "digital secure key" Android app, which allows me (or someone else who happens to get hold of my phone while it is unlocked) to transfer a few grand out pretty easily, limits passwords to "between 6 and 9 characters". And offers fingerprint based auth as an alternative, because we all know how infallibly secure that method is.
People were forgetting their passwords and using up valuable support time.

Since the responsibility for password storage is on the customer anyway, we might as well make our password a maximum of 6 characters!