Robin Sheat [mailto:[EMAIL PROTECTED] 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 Aronson
"Specialization is for insects."  -Heinlein

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Reply via email to