Best practices for encrypting client-side data

[secureCoding2dave at davearonson.com (SC-L Subscriber Dave Aronson)]

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/