I thought this was normal? They'd have two separate mailings sent from two locations such that they would only meet at the destination's mailbox on separate days. Then, after receiving the card, it'd have to be activated by calling an 800 number and giving some information, at which point they might also force a PIN change.
Also, he worries about the PIN being stored somewhere in plain text. If one-way hashes were used, anyone obtaining the hash would only need to test it against 10k possible values to get the original.
They should at the very least generate a new pin when it needs to be sent in the post though? Don't just send out the old one. I bet loads of people reuse them across cards. Just don't do it. Never send out credentials that aren't freshly generated.
That would be fine if activation required calling that number and providing a token that wasn't transmitted via the same channel as the card. One way to activate though is by simply using the ATM and entering your PIN... not good.
Hashing doesn't have much of a use when there are only 10k possible inputs.
Even using bcrypt set to take 1 second to verify a hash wouldn't be great -- it'd take about two hours and 45 minutes to break a PIN. And yes, while this is significantly better than not hashing at all (where it takes no time to get a pin) it would be trivial to target specific people to get their pin's given the hashed database.
Sure, you could make it take 10 seconds to verify a hash, but now all you've done is make me take a day to break the pin.
If the attacker doesn't have the key, he will have to bruteforce the full hash and not just 9999 values. Or what is the different use here? The root post was referring to storing hashes and not passwords (better to store HMACs and not hashes).
I don't know of any attack. However, my point is just that HMAC means using hashing for a message authentication code. Encrypting hashes makes more sense as to what's going on.
Comments
I thought this was normal? They'd have two separate mailings sent from two locations such that they would only meet at the destination's mailbox on separate days. Then, after receiving the card, it'd have to be activated by calling an 800 number and giving some information, at which point they might also force a PIN change.
Also, he worries about the PIN being stored somewhere in plain text. If one-way hashes were used, anyone obtaining the hash would only need to test it against 10k possible values to get the original.
They should at the very least generate a new pin when it needs to be sent in the post though? Don't just send out the old one. I bet loads of people reuse them across cards. Just don't do it. Never send out credentials that aren't freshly generated.
That would be fine if activation required calling that number and providing a token that wasn't transmitted via the same channel as the card. One way to activate though is by simply using the ATM and entering your PIN... not good.
Hashing doesn't have much of a use when there are only 10k possible inputs.
Even using bcrypt set to take 1 second to verify a hash wouldn't be great -- it'd take about two hours and 45 minutes to break a PIN. And yes, while this is significantly better than not hashing at all (where it takes no time to get a pin) it would be trivial to target specific people to get their pin's given the hashed database.
Sure, you could make it take 10 seconds to verify a hash, but now all you've done is make me take a day to break the pin.
My BofA PIN is 6 digits, so you'd need to hash a million values.
Still a pretty small rainbow table, I guess.
Use HMAC and not plain hashes.
HMAC's verify the integrity of a message; they don't have any use in this setting.
If the attacker doesn't have the key, he will have to bruteforce the full hash and not just 9999 values. Or what is the different use here? The root post was referring to storing hashes and not passwords (better to store HMACs and not hashes).
There is a difference between a HMAC and encrypting a hash, or a HMAC and a salted a hash.
HMAC means Hash based Message Authentication Code.
http://en.wikipedia.org/wiki/HMAC
I thought HMAC was equivalent to an encrypted hash.
From that link:
HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)).
Why would HMAC be inappropriate in this case (of storing user credentials)? Is there a vulnerability?
HMAC(key, password) instead of hash(password) or hash(salt+password)
I don't know of any attack. However, my point is just that HMAC means using hashing for a message authentication code. Encrypting hashes makes more sense as to what's going on.