aboutsummaryrefslogtreecommitdiff
path: root/hashsig.h
diff options
context:
space:
mode:
authorRob Austein <sra@hactrn.net>2017-04-26 20:01:01 -0400
committerRob Austein <sra@hactrn.net>2017-04-26 20:01:01 -0400
commit9c9f26fa04882cdc1ddb01410688f4d2651782af (patch)
tree1ff34435d1aef80e208e105d376074849d386dda /hashsig.h
parentbf19937394ad4286d4c0e820ca128ea0cc95e35a (diff)
Lower PBKDF2 password iterations and add delay on bad PIN.
Consistent user complaints about HSM login taking too long. Underlying issue has both superficial and fundamental causes. Superficial: Our PBKDF2 implementation is slow. We could almost certainly make it faster by taking advantage of partial pre-calculation (see notes in code) and by reenabling use of FPGA hash cores when when checking passwords (which mgiht require linking the bootloader against a separate libhal build to avoid chicken-and-egg problem of needing FPGA to log into console to configure FPGA). Fundamental: The PBKDF2 iteration counts we used to use (10,000 minimum, 20,000 default) are in line with current NIST recommendations. The new, faster values (1,000 and 2,000, respectively) are not, or, rather, they're in line with what NIST recommended a decade ago. Well, OK, maybe the Coretex M4 is so slow that it's living in the past, but still. The fundamental issue is that anybody who can capture the encoded PIN can mount an offline dictionary attack on it, so we'd like to make that expensive. But the users are unhappy with the current behavior, so this change falls back to the ancient technique of adding a delay (currently five seconds, configurable at compile time) after a bad PIN, which makes it painful to use the login function as an oracle but does nothing about the offline dictionary attack problem. Feh. Note that users can still choose a higher iteration count, by setting the iteration count via the console. It's just not the default out of the box anymore.
Diffstat (limited to 'hashsig.h')
0 files changed, 0 insertions, 0 deletions