Password Encryption

Topics: Developer Forum
Nov 28, 2006 at 12:25 PM
I was just looking at the code that encrypt the passwords.
It is currently using the Data Proection API (DPAPI).

The only draw back of this API is that eveyr other application running under the same user credentials will be able to decrypt this data.

So technically, one could write a utility that accesses the .config file, gets the data and decrypt it. Someone can then fool someone else in running this utility and it will be able to decrypt the password and send it to somewhere.

If users don't save the passwords in the .config file that OK, but perhaps there is a need for enhanced security in which upon turning it on, the program will generate a new key protected by a password.

If this feature is used, every time a user enters Terminals it will need to enter that password so that the new encryption key can be used.

That way, other programs will not be able to retrieve this information and use it.

What do you say?
Nov 28, 2006 at 2:06 PM
This discussion has been copied to Work Item 6005. You may wish to continue further discussion there.
Nov 28, 2006 at 2:10 PM
That's correct.
Frankly, I don't think anyone would actually write a program to steal these passowrds (btw, the microsoft RDP client uses the same API and stores the passwords in the .rdp files too), but I do see another benefit to your suggestion:
The fact that it uses the DPAPI means the passwords will not be decrypted when running the utility under a different user account. We did have portability in mind when designing Terminals (so you could take the Terminals directory with you on a Disk-On-Key and connect to your favorite computers from any other location) and this fits well in that approach.
So when you implement this feature, make sure it doesn't rely on user credentials so I can decrypt the passowrds using only my "master" password.
What do you think?
Nov 30, 2006 at 12:40 PM
For this whole idea to be portable, the key must be encrypted with a password (which will, of course, make it vulnerable to brute force attack and dictionary attacks) and it will then be placed in the configuration file.

Every time you will want to use these connections (or at least once per Terminals process) you will have to enter the password to decrypt the encryption key and then continue onwards.

This is essentially using DPAPI but instead of using the default user password hash, there will be a custom one.

Dec 3, 2006 at 7:52 AM
I lost you.. Can you explain your first suggestion then? How will it work exactly?
Dec 3, 2006 at 7:58 AM
Let's agree that what we need is a key to decrypt the passwords. The key is a paaword given by the user when starting the application. The first time it will be created and later it will be entered to decrypt the passwords. This key is not saved if the user forgets it then he will loose all of his connections. I don't care which algorithm is used.

Do you agree?
May 11, 2007 at 6:23 AM
An additional feature that's needed is the ability to change the existing password, which is currently disabled in the Options dialog.
May 11, 2007 at 8:24 PM
As a quick and dirty workaround to change the password simply edit Terminals.config in your favorite text editor and the settings node:

You should a "terminalsPassword" attribute. It should look something similar to:

terminalsPassword="8acd7d547d0sdfgdsyt546afdgbadfy 5s41ec55aebc2b929cf7c09939c7b21348536bbc94f47ec01c6442a08ded6"

Just remove the content within the quotes. Be advised that that will actually invalidate ALL of your saved passwords.

I have not implemented the change password feature yet, but will hopefully be soon. It would be a matter of iterating over the collection of saved terminals and if it has a password set, decrypt with the old, encrypt with the new and save it.

Some background:
If you do NOT have a Master Password set Terminals will default to the DPAPI stuff.

The "Master Password" which is set by you is stored in hash format (SHA512 -, base64 encoded to make it XML friendly) in the terminalsPassword attribute above. That hash is then used as they key and IV for the encryption of all other passwords which you save (it will use the Rijndael method for encryption, iirc it uses simply a 24bit key and 16 bit IV - Removing that hash removes the key and thus the ability for Terminals to decrypt your saved passwords.


May 29, 2008 at 8:59 PM
"The "Master Password" which is set by you is stored in hash format"
"That hash is then used as they key and IV for the encryption of all other passwords which you save "

If you are using the HASH and not the password as the key, and you are storing the hash, then an attacker only needs to find the HASH to decrypt all of the keys.

If you are storing all of the passwords in one password file that is then encrypted by a master password you DON"T NEED TO EVER STORE OR HASH the master key. Instead you validate the users password input by attempting to decrypt the database, if you fail the user entered the wrong password and needs to try again.

I hope I am just misunderstanding the second thing you said.