🔒 Locked

Serializing sensitive data 'securely'

Started by antareus Jan 25, 2004 at 10:49 PM 1 replies 300+ views

Original Post

Jan 25, 2004 at 10:49 PM

I have an Account class that which holds authentication information for a specific account. The class is meant to be a base class, and defines two methods, Serialize() and Deserialize(). Derived classes override DoSerialize() and DoSerialize() (as the base class has some housekeeping to do). Right now, Serialize() and Deserialize() take in a TiXmlElement pointer (Tiny XML) that points to the root XML node that [de]serialization begins at. The problem is the derived class has to store its password sometime (connection could be severed and reconnection needed - shouldn''t prompt the user again!), and some evil code could simply serialize the account out to another file, read that file in, grab the password, and send it out to the master of darkness or whatever. Now, I''m aware of the fact that no matter what I do someone can pretty easily figure out object layout and do enough pointer arithmetic to get to the actual data. However this particular case strikes me as glaringly easy to exploit. And if you''re wondering why I worry about evil code, its because the application is meant to be extended by users, it is completely component based. I want people mixing plugins until they find the right set of UI''s and features for their uses.

ironfroggy

Jan 26, 2004 at 1:04 AM

you could encrypt it with some key kept outside the XML tree.

ChaoticCanuck

Jan 26, 2004 at 2:00 AM

If you design both the client and the server, then design the server such that the the entire connection is encrypted using SSL or TLS.

Once that is done require that incoming connections provide either a username and password, or an encrypted exceedingly complex session key generated by all kinds of information available to the host about the client. These session keys should expire after a certain period of time.

These session keys will allow your application to gracefully resume a session later without requiring you to store a username and password. Just make sure that each time a session key is provided you issue a new key, and if someone attempts to use an expired key and sessions based on that key are terminated.

For those who would argue that the session method is vulnerable to a MIM attack even though it is encrypted, I remind you that if the attacker is sophisticated enough to successfully launch a MIM attack on a "secure" connection then the username and password authentication method is equally vulnerable.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.