this topic is no more active, left for interested developers

Skill Plan Roaming

Design

  • Settings.Xml will be stored in IsolatedStorage? for 'normal', non-roaming operation
  • Options buttons for Import/Export will help users find/manage the file since it is hard to locate via Explorer
  • If Settings.Xml is found next to EVEMon.exe and it is writable, this location will be used instead. This enables users to set up "USB Stick Roaming Mode".
  • Server based roaming will enable loading/sasving of settings file via a 'web service'.

Design issue

If a user is running on a machine that is enforcing FIPS compliant cryptography, then IsolatedStorage? won't work. See http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=682308&SiteID=1

If we use IsolatedStorage? then we need an alternative for users on machines that are enforcing FIPS

(See http://blogs.msdn.com/shawnfa/archive/2005/05/16/417975.aspx for a discussion on FIPS compliant cryptography)

Secure Server Design

k, here's how you can store an Xml profile securely on a server. You need to use two security algorithms -- a one way hash and a symmetric encryption encoder.

A one way hash function takes an input (like a password or sentence) and produces a fixed length number that looks like random data. For instance the SHA256 hash algorithm can take in a sentence like "I am a n00b carebear" and it produces a 32 byte number called a Hash. The properties of a one way hash are that every time you start with the same exact input you get back the same exact number, but if you have the Hash it's realistically impossible to figure out the data that produced it or to come up with another set of input that will produce this number. Because of these useful properties, hashes are used to verify that a set of data hasn't been modified (e.g. this file still contains the same data it did when it was published) or they are stored in a password database instead of the password itself (e.g. if you have the password, you can generate the hash but if you have the hash you can't get the password).

A symmetric encryption encoder is a function that takes a set of data and a key and encrypts the data so it can only be unencrypted with the same key. A modern encryption method like AES256 is so strong that if the Germans had known about it during World War II, we'd all be singing songs of praise to the Fatherland.

So, how does this work for EveMon? and storing your profiles on a server? Well, what you do is:

  • Log onto EveMon? and supply it with a password or passphrase (passphrase is really just a term for "really long password" like my "I am a n00b carebear" example above).
  • Generate a unique "RecordID" by hashing the passphrase + a constant (like "RecordID: I am a n00b carebear")
  • Generate a unique "EncryptionKey?" by hashing the passphrase + a constant (like "EncryptionKey?: I am a n00b carebear"). Note that these two hashes will be completely different numbers that don't even look related due to how hashing works
  • Call up to a server somewhere with a simple API like Server.Set(RecordID, RecordData?)

OK, now your Xml Profile is stored on a server. The kicker here is that the server admin cannot read the RecordData? and she cannot figure out the EncryptionKey? needed to decrypt RecordData? from RecordID. EncryptionKey? is never generated by or stored on the server so only the person who knows the passphrase can regenerate it.

Now you go to another computer and run EveMon?. Again you log onto it with your passphrase. It doesn't have any character info yet, but it generates RecordID from passphrase and calls a server API like Server.Get(RecordID). It gets back the encrypted RecordData?, generates EncryptionKey? and then uses the unencrypted Xml Profile.

You can use an existing password (like the Eve Account password) to generate the Hash, but there is a drawback there. Tables of Hashes are subject to a type of attack called a "Dictionary Attack". What is done here is you take a dictionary full of words, you generate Hash values for all of them, and then you compare every entry in the Hash table to the hash values of every word in your dictionary. This is a common hacking technique that's been used for years (see http://en.wikipedia.org/wiki/Dictionary_attack for details). Since EveMon? is open source, it would be trivial for a hacker to figure out the hash constant (e.g. "RecordID:" above) and then encrypt a dictionary with that constant. Then if they ever got access to the server data, they would be able to figure out a bunch of Eve Account passwords and by decrypting the Xml Profiles they might even be able to get the matching account names. This would be bad. Past experience shows that about 70% of the passwords people choose can be easily cracked using this attack which is why there's all the fuss about "use a strong password" (except CCP doesn't require this or even suggest this for Eve...) Since we wouldn't want EveMon? to be the source of a vast compromise of Eve Online accounts, we would probably want to require (and verify) that a different pass phrase was used for profile storage than what is used for the Eve Online account.