On 30 May 2012, at 22:17, Marsh Ray wrote: > On 05/30/2012 02:59 PM, Nico Williams wrote: >> >> This is why salting is important. They should not be able to build >> a single rainbow table that works for all cases. > > In order to be useful, the salt has to be large enough to not have large > numbers of collisions across large user populations. Ideally it should be out > of brute force range, or else the attacker can just fix a password and > construct his rainbow table over the salt possibilities. > > This implies that a maximally-effective salt will be larger than a user is > able to remember, but the explicit goal of this scheme was to avoid > persistent state on the device. If we're willing to give up this design goal, > we'd probably be better off building a proper encrypted password manager app > instead. > > There may still be value in hashing in the username, but only in the > aggregate. I don't see that it helps the targeted user case much.
I'm currently considering asking the user for their full name and using that as a salt in the scrypt operation. Full names are often lengthy and there's a good deal of them. Do you recon this might introduce enough entropy or should I also be asking for the user's birth date? I'm just thinking that this is good information that will make for a wide enough range of different salts that it will hopefully make rainbow tables too expensive while still avoiding the problem that a user cannot remember any random salt of such entropy.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
