5 comments

[ 2.9 ms ] story [ 16.4 ms ] thread
I'm all for a good laugh at the practices of large corporations, but this is probably just because they need to support telephone banking. EDIT: Looks like it's not for telephone banking, ouch!
This was at the "developer zone" where you keep track of your API keys and other stuff to access Mastercard services as a developer.
The fact that they have a maximum (20) and a low maximum at that, and also have issues processing specials, suggests to me that they're storing in plain text.

Even DES could handle specials, the only thing that cannot is running an SQL query with the plain text string within that (not even using a parameter), and only having the column set to 20 characters. I can think of no hashing algorithm old or new which had these kind of limits.

Try doing a password reset, do they email you your old password?

Yeah, that's the same sort of thing I think about whenever I see this crap too. It's understandable with banking systems, they're often forced to interface with old and antiquated mainframes with formal constraints, but it's simply unacceptable in a modern system.

Even if the solution winds up being storing the hash as the credential and simply hashing it in transit with middleware, it's better than this garbage.

I hate this stuff. They are trying to make it more secure by forcing you to mix it up a bit, but they end up making it less secure. Quite a few people are going to follow the "recipe" exactly.

It's just like a few of the banking sites I use that prevent pasting of passwords and some of them break 1Password. That just makes me choose a far less secure password so I don't have to futz with entering "HBmpRJukt=[WbBynhTm8s" every time