Bug #37410 for bind9-public: PKCS#11 PIN length is silently limited to 32 characters [patch]

On 8.10.2014 18:25, Francis Dupont via RT wrote: > On Wed Oct 08 16:06:09 2014, pspacek@redhat.com wrote: >> It seems that all versions of BIND with native PKCS#11 support are >> limited to >> 32 bytes of PIN length and didn't actually check the PIN length which >> can later cause login failures. > > => yes, the PIN length should be limited to something > reasonable and 32 octets seemed the right value. > In fact the PIN maximum length is a property of the HSM > so I'll dig in the new PKCS#11 v2.40 specs I copied from OASIS > some hours ago to see if there is useful about it in them... > >> First patch adds check for PIN length to prevent too long PINs from >> causing login failures later. > > => IMHO it is a good idea. > >> Second patch extends maximal PIN length to 1023 bytes so it should be >> enough for everyone including me :-) > > => 1023 octets are a very large value for a PIN. BTW > with an enforced low limit of retries a short (4 digits) value > is common, i.e.: > - a PIN is not a password I'm not opposing to that however I do not see a reason to artificially limit PIN length on *client* side. HSM will deal with it if the PIN value is too long for that particular implementation of PKCS#11. IMHO maximum PIN length advertised by HSM for purposes of PIN initialization to let user know what PIN he can enter for that particular HSM. > - no limit at all on retries is a *bad* idea > (explain this to Apple with its cloud :-). In this particular case I'm using SoftHSM so there is no secure way how to enforce limit on retries. That is the reason why I wanted to use very long PIN. I hope it explains my motivation. (And yes, I know that SoftHSM is really cheap HSM :-)) Have a nice day! -- Petr Spacek @ Red Hat

---

On Wed Oct 08 16:29:21 2014, each@isc.org wrote: > > => 1023 octets are a very large value for a PIN. BTW > > with an enforced low limit of retries a short (4 digits) value > > is common, i.e.: > > Seems reasonable, since HSM PINs are always 1234 anyway. :) => the reason is the PIN must be available somewhere in clear (usually in a file) to make the HSM operable by applications as bind9 (this doesn't mean PINs are useless, only they are for other things, and security is from a set of means...).

---

On 8.10.2014 18:56, Francis Dupont via RT wrote: >> I'm not opposing to that however I do not see a reason to artificially >> limit PIN length on *client* side. > > => laziness... (i.e., it is more complex to manage > a dynamically sized piece of memory :-). That is why I used 1024 byte buffer :-) I don't want to be bold but... aren't we spending too much time on such a minor thing? Feel free to amend the buffer size or refuse the second patch completely if you feel that 31 byte PIN is good enough for everyone :-) >> In this particular case I'm using SoftHSM so there is no secure way >> how to >> enforce limit on retries. That is the reason why I wanted to use very >> long PIN. > > => a long PIN won't save you, in particular with SoftHSM > which doesn't really protect it (BTW mainly because it can't > in an easy way. I know how to reset the PIN in the case I used > something which is not 1234 and I'd like to keep objects, and > I did it more than once :-). I'm not an SoftHSM expert but I have to ask: Are you talking about SoftHSM v2? Looking at src/lib/data_mgr/SecureDataManager.cpp it seems that all values with CKA_PRIVATE = TRUE are encrypted with key which is derived from PIN. Sure, it can't help against on-line attack where the key is in memory but it should help against off-line attacks. Also, we want to run SoftHSM in separate process so bugs which allow attacker to read server's memory will not expose keys. >> (And yes, I know that SoftHSM is really cheap HSM :-)) > > => I added a large amount of code in SoftHSMv2 so now > I am in its developer list! But if SoftHSM is a very good tool > to debug/practice/etc PKCS#11 code it was *not* designed > for strong security at all. I'm aware of that. Customers who want real security are encouraged to buy real HSM but SoftHSM is good enough for those who do not care. SoftHSM should not be worse than keys stored in plaintext on disk, right? Thank you for the discussion and your time! -- Petr Spacek @ Red Hat

---