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 -- Dave Aronson "Specialization is for insects." -Heinlein Work: http://www.davearonson.com/ Play: http://www.davearonson.net/ _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
