Customize PBKDF2 iterations

[fnkr]

I would like to increase the number of PBKDF2 iterations used.

[Hemant Kumar]

Hi @fnkr,

We would love to increase the number of PBKDF2 iterations, but the slow speed of some of supported platforms (Windows Phone and BlackBerry) restricted us to come with the optimum value of 24K.

We will look forward for it in future as the faster devices are coming in market.

Thinking of more security always!

[fnkr]

50 minutes ago, Hemant Kumar said:

but the slow speed of some of supported platforms (Windows Phone and BlackBerry) restricted us to come with the optimum value of 24K

That sounds like you're sacrificing security for the sake of performance.  And you're absolutely right, it really is a trade-off between security and performance.

57 minutes ago, Hemant Kumar said:

We will look forward for it in future as the faster devices are coming in market.

That's why I'd suggest to make it configurable. With KeePass I had set this to 200M iterations and it only took a second to open/save the database on my Desktop.

If you fear complicating the user settings dialog, you could add an "expert settings" tab.

[rudenaggar]

Using RFC2898DeriveBytes with a non trivial iteration count should be better than using a straight hash function for authentication purposes. The Rfc2898DeriveBytes class can be used to produce a derived key from a base key and other parameters. Rfc2898DeriveBytes is an implementation of PBKDF2. PBKDF2 uses a pseudorandom function and a configurable number of iterations to derive a cryptographic key from a password. Because this process is difficult to reverse but can also be configured to be slow to compute, key derivation functions are ideally suited for password hashing use cases. More about...Password Encryption

Ruden

[Kristian]

I would like to have more influence in the security as well and configure iterations. Another up-vote from me.

Additionally I would love to have the option to define the encryption bit size as well. While it's currently 256 bit AES, I always like to go the extra mile and increase the standard value - probably 512 here. And yes, I definitely don't mind to trade-off performance. Especially because my PCs (the only devices I use Enpass on) are very powerful.

Please give us more options to increase the security by our own. I like the idea to have an "Expert Settings" tab.

Best regards,
Kristian

[Xinamo]

NIST guidelines recommend at least 10K of iretations. So I'm pretty sure the current 24K rounds is more than enough ->

Password with 8 letters + numbers + punctuation OR 4 random Diceware words would take 3250 years to crack if you use 10K rounds. So that's that

 

Edited September 13, 2016 by Xinamo

[My1]

On 13.9.2016 at 11:43 AM, Kristian said:

While it's currently 256 bit AES, I always like to go the extra mile and increase the standard value - probably 512 here.

I am pretty sure that AES cannot do 512 bit.

On 13.9.2016 at 2:52 PM, Xinamo said:

NIST guidelines recommend at least 10K of iretations. So I'm pretty sure the current 24K rounds is more than enough

I personally dont care about NIST.

and if the aliminuin hat fraction wants to increase the iteration so that it takes a whole minute for key calculation, why not let them is isnt as if this would affect you or is it?

On 13.9.2016 at 11:43 AM, Kristian said:

Please give us more options to increase the security by our own. I like the idea to have an "Expert Settings" tab.

I fully agree to this as long as the options arent complete snakeoil.

one thing that could be done would be having an option for scrypt which allows the user also to get more RAM usage for the key calculation which helps against parallelization.

On 13.9.2016 at 2:52 PM, Xinamo said:

Password with 8 letters + numbers + punctuation OR 4 random Diceware words would take 3250 years to crack if you use 10K rounds. So that's that

on what machine? I think having the choice of choosing stronger values for futureproofing would be great.