How and where to store passwords?

[Pako]

On this issue I have encountered at work to plugin E-mail. It is true, that about this plugin has nobody interest, but it's a general problem. It is not reasonable to have passwords stored the same way as storing a whole configuration of EventGhost (xml file). For example, in the event that someone would be sent the xml file to support forum, saved passwords to get to the public. For me it is clear, that there is no problem to store passwords in a separate file (for example, to the directory "APPDATA"), but there is one big problem:
How to ensure that this file be save always (and only) when storing the rest of the configuration (ie configuration file xml)?
I hope that, despite my lousy English, it was clear what I mean.
Pako

[jinxdone]

Usually they encrypt these sort of things with unique information based on the machine, such as windows serial number, MAC address of a network card, CPU information, serial number of first partition.. Combine all these (and possibly hash the result with sd5 or sha1 for example) to make the key used to crypt the stored password. Then it should be only possible to decrypt it on the same machine it was encrypted on. If you encrypt the password with such methods it doesn't really matter where you store it; in EG config, file in EG directory, file in user directory, possibly even windows registry..

Just choose good sources of machine-based info that does not change such as serial numbers.

(Yes, if you know all these things about the machine it is possible to decrypt it anywhere, however that's not really a big threat In my opinion as if the attacker can poke around your system to retrieve such information one email password stored in EG config is not a big concern anymore)

Take a look at this interesting python WMI module, you can use it to retrieve all sorts of interesting information:
http://tgolden.sc.sabren.com/python/wmi.html

There is probably a lot of talk on this issue around the internet already, try looking around a bit.

Also you could look for information on how to make registration/activation keypairs - (the registration key is usually a machine based generated key that you send to the program maker and they give you the activation code for that key). They do that to control the user so that he only has one installation per key at any one time, if you want to move the software to another machine you have to request a new activation code. A good example of this is the Microsoft Windows's activation. Basically it's the same thing as this just different application of it.

-jinxdone

[Pako]

Thank you for a comprehensive response. SHA1 and md5 I looked, but (if I understood correctly) is not the way for me. I need symmetric (Rijndael) cipher. I found nice solutions: pyDES from Todd Whiteman (http://twhiteman.netfirms.com/des.html), pyRijndael.py from Jeffrey Clement (http://jclement.ca/software/pyrijndael/) or rijndael.py ( http://bitconjurer.org/rijndael.py).
The key for the cipher meanwhile may be the MAC address. Its not reading it difficult. When passwords are encrypted, meanwhile it is not necessary to store separately from the configuration of EG. Nevertheless, if someone to send its configuration XML file (such as to EG support forum), should prefer the part, where they are stored passwords, delete. As far as I know, Bitmonster is thinking of introducing a new eg.Password class. And as I get to know Bitmonster, it will be done thoroughly. Probably will be introduced separate storage of passwords too. Make this option only in a single plugin is difficult. I can't capture the moment of storage configurations.
Pako

[jinxdone]

Yep you got it. Just make sure you hash and/or otherwise obscure the information you use for the key. Using only a MAC address for a key is about as secure as using your phone number for a password..

What I described above is in a few simple steps:

- Gather machine based information
- Combine the information and run them through a hashing algorithm like sha1
- Use this generated string as the key for encrypting and decrypting the actual stored information using a two-way (symmetric) cipher like AES, Blowfish, Twofish or something similiar

It would be very unlikely anybody will ever be able to open the crypted information unless he has access to the machine. Also the user himself wont be able to read the crypted data if he moves the config to another machine or so..

I agree it would be a good to have a EG wide function that does this sort of thing, it'd be easier to write plugins if you didn't have to worry about these things but just use a built-in function. I assume the actual implementation will be something similiar to what I described above even if Bitmonster makes it.

-jinxdone

[CollinR]

A bonus to the MAC cipher is you can at your option generate the cipher against a USB NIC, this would allow you to switch machines or do updates without concerns of loosing the files contents.

[Pako]

What I described above is in a few simple steps:
- Gather machine based information
- Combine the information and run them through a hashing algorithm like sha1
- Use this generated string as the key for encrypting and decrypting the actual stored information using a two-way (symmetric) cipher like AES, Blowfish, Twofish or something similiar

Yes, I understand and agree. There is no problem to implement this way and I will. Read any more some information in addition to the MAC is not so difficult.

It is also the problem, that you can not transfer the configuration to another machine (or install the backup after the accident). Yes, it is a duty for security. In order to facilitate the lives of at least a little user, I can give the possibility to export passwords to the backup file, which will be encrypted and password protected (not based on hardware).
Pako

[jinxdone]

Right. But then again it's a password to the user's own an email account, no point in protecting a password with another password IMO..

Just add a little notice that says something like: "The email plugin will remember the password only on this computer". Perhaps a button that will display the stored password in cleartext on screen?

It would also be easy to add a little check to it so that when the password is stored some validation info goes in there with it. Like say, hash of the password or maybe checksum, then you can use that to verify that the passwd was decrypted correctly or not when you try to read it. If not then display an error message to the user.



Btw. You might want also to read up on cryptsetup-LUKS, especially how the key-slots are used in it, it's a pretty interesting read. Makes changing passwords used to access the encryption-keys possible also you can have multiple passwords to access the same piece of information with that sort of keyslot system..


-jinxdone

[Pako]

Right. But then again it's a password to the user's own an email account, no point in protecting a password with another password IMO..

This can not completely agree, although meanwhile there I not will give this option (but I can there give warning to ...). When the accident disk, so you will not be able to read the password. But if you have a backup file with the passwords (and, of course, XML configuration file), the problem will not restore the previous state on the new disk. Also, the upgrade of the machine will be easier to transfer all passwords at once, than the copy by hand.

I think, that is already beginning to go too deep. Stop to discuss and go to work. It's not perfect, but in oposition to the current situation to be far better. There is always a possibility to improve and then I wait for the introduction of eg.Password.

Pako

[Bitmonster]

Making all passwords dependant of the hardware is no good idea I think. The only solution I can think of is some master password the user would have to give as soon as some passwords are stored in the configuration and this master password gets crypted by something unique like the volume serial number, together with some cookie, so it is possible to validate the master password. So the passwords in the XML cannot be used by anybody else. Even if some "cracker" would get the config.py in APPDATA it wouldn't help to get the passwords as long as he can't see the volume serial number. And if the installation is moved to another machine EG can detect this and the user has to retype his master password once to get access to all actions that are using passwords or any crypted data.

[Pako]

Yes, I agree with that. Even I am also thinking about a similar solution. There is but one issue: the master password assign to the plugin, or to the entire application? If you use more plugins with the passwords, it would certainly be more comfortable if the master password has been only one.
Pako

[jinxdone]

Yes there are many ways to go with this.

Basically the master password and the machine-generated password have to open a crypto-key(random 2048 or 4096bit or longer, same key is stored in both slots and is never given to the user directly). That key is then used to crypt/decrypt the data. Read how LUKS uses keyslots, it's pretty neat.

If the config is moved the keyslot 1 that the machine-generated string opens cannot be decrypted correctly, then it has to ask for the master password for keyslot 2. Simple.


Earlier in this thread we were just talking about how to store a password safely with minimal effort for the time being. I don't think it's worth it to make all the bells and whistles just for one plugin. I was under the impression that you (Bitmonster) already have plans to make the EG.Password or similiar feature at some point and all this will be implemented in that to the full extent, then we can move to use that when it's done.

Ofcourse If you want to start making it right now, great!

-jinxdone