Consider scrypt or some memory-intensive hash rather than pbkdf2

[jnicholls]

Just a thought: consider using a memory-intensive KDF like scrypt instead of pbkdf2. I noticed on the TODO list the option of setting one's own interation count. This would be a way to skip that need. And as such, recommend to folks to setup the wallet on a powerful desktop and just suffer the increased latency on mobile phones. Making it dynamic would be difficult since Web APIs don't offer a means to querying system resource information, so the amount of memory and cpu can be configurable...

...and now that I'm typing it all out, maybe allowing one to set their own pbkdf2 interation count is easier, lol.

[jaimehgb]

It's almost done too :P

https://github.com/jaimehgb/RaiWebWallet/blob/master/js/custom.js#L1444
https://github.com/jaimehgb/RaiWebWallet/blob/master/wallet.php#L250

I was thinking on how to store its value, in a field near the wallet at the database or serialized with the wallet data. The problem with the first one is what happens if it fails to update the value in the database due to connection issues or whatever and the ciphered wallet with the new iteration number is stored successfully (they are independent functions, maybe putting them together will do the trick). And the problem with the second one is compatibility with old wallets, I should add a mechanism to distinguish between both formats and then decipher the packed data in one way or another (https://github.com/jaimehgb/RaiWebWallet/blob/master/Wallet.js#L1359).

[thiscantbeserious]

If you're going the hard way you might want to consider argon2id instead of scrypt concerning side-channel attack resistance:

https://www.cryptolux.org/index.php/Argon2
https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#page-13

Otherwise customizable, read increased iterations should be sufficient for now.