i meant regarding actual local db transformations rather than server login throttling(which is also great to have).

I believe the technique suggested in the OP was originally invented for FreeBSD password hashes. A similar technique is also used for WPA Personal passphrases.

The issue with mobile devices and JavaScript is not a small one. I tried to implement a doodad that would convert a WPA passphrase to a hex key in JavaScript and it took longer than the browser's timeout to perform the computation (4096 iterations of SHA1 using a SHA1 hash implemented in JS). And using a less-transformed version for weaker platforms won't work because attackers will just go after the weakestly-transformed version.

Another technique that might be nearly as good or better would be to make it difficult for an attacker to determine if they have the correct key. Use a bijective compressor such as BICOM on the file before encrypting it, whitening the first part of the file since that will have the least entropy. BICOM actually does this natively. You can find a description at http://www3.sympatico.ca/mt0000/bicom/ . I have no idea how well this would work in practice, but at the very least forcing the attacker to decompress the data (and to decrypt the entire file, say via a package transform) in order to determine if he or she has the correct passphrase could help a lot.

Of course, if you use a long passphrase instead of a password, you can get even better protection, since every additional character probably about quadruples the attack time (assuming two bits of entropy per character in common passphrases).

By the way, loving the product so far. If the Android version doesn't suck too badly I'll be going premium.

Yeah we made quite a number of tests and decided it's not possible if we want to support mobile devices via the website. The native applications can do it; but once it's in JavaScript it becomes untenable; even with the native mobile devices it's such a waste of battery life we're having a hard time with it; for now I'd suggest you add an extra letter to your master password... it has similar levels of increased security.



Glad to hear it; we're still improving it so if you see something that's not working well let us know!

i'd like to bring up this issue once again in light of http://lifehacker.com/5350375/how-to-recover-your-firefox-master-password
In the link above, software can try ~160000 passwords per second.
i'm not saying lastpass' password is equally fast to crack, but with increasing cpu power and popularity of rainbowtables, this could be a real problem.
Crippling everybody for the lowest common denominator(mobile phones) is rather disappointing.
Even if mobile devices are not that powerful, i think waiting 5seconds while it does enough transformations is insignificant drawback in grand scheme of things.

Rainbowtables definitely aren't an issue (we include your username in your hash client side, and on the server we go further and take that hash and hash it again including another 32-bit random number salt too).

160000 sounds like a lot but in the realm of 2^256 possible keys is really next to nothing even a million times faster for years will not put any dent into how large this is. On top of this they'd have to get a copy of your encrypted data first (they get 5 attempts before lockouts start occurring), and even if they did it's still the end of the universe before they can get in assuming you picked a good master password.

I think the right solution for most people going forward will be our multi-factor offerings as we improve them to allow you to specify that it's unnecessary on certain computers, and only used say when you're traveling.

Joe

Thanks for great ideas keep it up...........