On 12.07.2017 12:27, NdK wrote: > Il 12/07/2017 12:01, Binarus ha scritto: > >> Not sure about that. Similar to serious websites which don't store your >> password in clear text, but do store the password's hash instead, I >> would expect that banks don't store your PIN in clear text as well. > Even with 6-digits PIN it would take *seconds* to an attacker to brute > force hashed PINs once he gets the hashed database. [...]
While this is correct, it is no reason for not doing it that way (if we choose to ignore the endless possibilities cryptography offers and decide to store the PIN in some form in a backend at all). Salted hashes would > multiply the needed time by the number of PINs (approx). > So keeping such a database would be a really stupid thing to do -- > unless it's kept in a HSM. Of course, I was talking about salted hashes. Besides that: https://security.stackexchange.com/questions/88711/how-can-my-bank-issue-a-new-credit-card-with-the-same-pin-number https://security.stackexchange.com/questions/62306/a-second-bank-card-arrived-with-the-same-pin Some comments / answers in the first one claim that the PIN might be stored in hashed form in some database. Most comments / answers in the second one claim that the PIN is stored on HSM (they don't seem to be sure if it is in clear text or encrypted there) (if I had more time for research, I probably had found better explanations ... the two links basically were on the first result page on Google when searching the respective keywords). But whatever: My key point was that the PIN *never* is stored (or transmitted) in clear text outside an HSM, meaning that software which could examine the PIN according to certain criteria will have to run inside that HSM. I do not think that any bank has implemented such a thing. Regards, Binarus _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
