The reason for the character limitation is a lot more straightforward - on the backend its stored on a very legacy system (in plaintext.. but I didn't tell you that), and to increase the length of the database field would cost 7 figures.
At a past job, the mainframe "copybooks" required an extra digit for certain price fields (cars never used to cost > 100K). It was a months-long project which required tons of coordination with other clients systems. One could argue that the 27 other ways the company didn't have its house in order made the project costly, but the 30+ hour flatfile data conversion was an inherent part of the plan.
This doesn't make sense to me. Any "legacy" systems involved surely pre-date online account access by consumers. They would not have ANY password field or even any notion of a "user" in the sense of someone who is able to access a specific account.
This would have all been built as a web application talking to the backend through a CICS gateway of some sort. The web app would be responsible for authenticating the user, not the legacy mainframe system.
why not just throw a hash function in the middle? technically you're not increasing the search space for a brute-force attack (but that's not the goal), but you are probably slightly increasing entropy. and most of all, you avoid bad PR like this. :)
that said, it's probably still quite expensive and this PR isn't that bad.
Comments
The reason for the character limitation is a lot more straightforward - on the backend its stored on a very legacy system (in plaintext.. but I didn't tell you that), and to increase the length of the database field would cost 7 figures.
Wikileaks, dude...
It's COBOL, isn't it? (Not being sarcastic; that's the only system I can think of that would cost 7 figures to change a field length in the database.)
At a past job, the mainframe "copybooks" required an extra digit for certain price fields (cars never used to cost > 100K). It was a months-long project which required tons of coordination with other clients systems. One could argue that the 27 other ways the company didn't have its house in order made the project costly, but the 30+ hour flatfile data conversion was an inherent part of the plan.
Edit: Legacy COBOL, of course.
This doesn't make sense to me. Any "legacy" systems involved surely pre-date online account access by consumers. They would not have ANY password field or even any notion of a "user" in the sense of someone who is able to access a specific account.
This would have all been built as a web application talking to the backend through a CICS gateway of some sort. The web app would be responsible for authenticating the user, not the legacy mainframe system.
They probably keep the password in an 8-char record that used to store something else.
why not just throw a hash function in the middle? technically you're not increasing the search space for a brute-force attack (but that's not the goal), but you are probably slightly increasing entropy. and most of all, you avoid bad PR like this. :)
that said, it's probably still quite expensive and this PR isn't that bad.
http://benlog.com/articles/2008/06/19/dont-hash-secrets/
Interesting post. But it doesn't make the case that the title promises.
Why not just hash the password and use the first 8 characters of the hash? That would at least stop things from being stored in plain text.
C'mon - why is the troll/joke comment being upvoted? It doesn't add much to the discussion :(
It's being upvoted because it is probably true, despite being entertainingly worded.
I'm not a fan of meaningless speculation I guess (it more saddens me this is the top comment when all the value, the best of HN, is below it....)
Because it is almost certainly true. I used to work at Amex, it wouldn't surprise me if all banks are in similar situations.