Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

He almost certainly meant that sha256(card number) can be bruteforced to figure out what card number was hashed. 10^12*256 bits is only 29 TiB.

So providing a hashed card number to a potential scammer is just as bad as providing the card number.



So just ask the other party to give you a salt they generate on the spot? And/or you do so on your end?

You can still get targeted for a direct attack but much less likely to end up caught in a dragnet approach.


That would prevent using a pre-generated lookup table but doesn't help much with brute force attacks. All possible card numbers is a finite set, and if you have the sha256(card number + salt), you can figure out which card number was used as input given the improbability of sha256 collisions within that set.

Keep in mind this in the context of an account holder asking the bank to authenticate themselves on a phone call using data only the bank and the account holder should know. sha256(card number) was an example of something that is obviously inappropriate, and I don't think sha256(card number + salt) is any different qualitatively.


Not to mention, how many bits of salt can you transmit by voice in this context without this turning into a whole song and dance?

> That would prevent using a pre-generated lookup table

Only for a healthy pinch of salt, not a couple grains, right?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: