[SC-L] Best practices for encrypting client-side data

SC-L Subscriber Dave Aronson secureCoding2dave at davearonson.com
Tue May 8 11:00:12 EDT 2007


Robin Sheat [mailto:robin at kallisti.net.nz] wonders:

 > What I did was take the user's password to create a key

What happens when the user changes his password?  I didn't quite follow it all, but it looks to me like that means that all of a user's data has to be decrypted and re-encrypted.  You didn't tell us how much data that is, so I'm going to ass-u-me that it *could* be a lot.

Perhaps you could base the encryption on more stable data, such as the user name combined with when the user joined.  This could be used to encrypt the data directly, or, as you proposed, to encrypt the actual key.  How difficult would it be for the attacker to figure out whose data something is, and when they joined, or whatever else you base your encryption on, AND the fact that that's how you encrypt?  If finding that out would be pretty much trivial, there goes all your protection, under the above scheme.

Also, just how secure do you need it to be?  Don't waste a thousand-dollar lock on a fifty-dollar bicycle.  Is this data actually a tempting target for attackers who are clueful and resourceful (in both the senses of "clever" and "able to spend a lot")?

-Dave

-- 
Dave Aronson
"Specialization is for insects."  -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/





More information about the SC-L mailing list