Question

I’m doing some basic security work for an application. When a user logs in, their credentials are validated via Active Directory. Sometimes, a user requests changes that cause the program to restart. Since this application is not a single instance program, I simply launch another instance and close the current one. Everything within the application is fine.

However, users aren’t happy that they have to re-login every time it restarts. So I pieced together some basic security using SecureString to store the password in the application. If the application restarts, the password gets decrypted then re-encrypted using a basic implementation of Rijndael’s algorithm from CodeProject. The application passes the username and encrypted password as command line parameters to the new instance. The application needs to encrypt the password, because any further calls of wmic process would show the password. The new instance decrypts the password, validates it against Active Directory silently, and stores it as a SecureString as usual.

I’m not too familiar with general security practices. I’m a little nervous about returning the password from the decryption method. It’s not being stored in any variable per se, because the call is made right in the Active Directory validation request. I’m still not sure if the returned password is accessible somewhere in memory or if it’s stored in a register.

This process doesn’t need to be the greatest security ever. It just needs to discourage people from getting a password in cleartext if they can easily access the memory contents.

Many thanks!

Answer 1

Function return values are, in .NET apps, pushed onto an “evaluation stack”, which resides in protected memory within the process. However, you’re talking about a string, and that’s a reference type, so what’s on the evaluation stack is a pointer to that string’s location on the heap. Heap memory is relatively insecure because it can be shared, and because it lives as long as the GC doesn’t think it needs to be collected, unlike the evaluation or call stacks which are highly volatile. But, to access heap memory, that memory must be shared, and your attacker must have an app with permission from the OS and CLR to access that memory, and that knows where to look.

There are much easier ways to get a plaintext password from a computer, if an attacker has that kind of access. A keylogger can watch the password being typed in, or another snooper could watch the actual handle on the unmanaged side of the GDI UI and see the textbox that’s actually displayed in the Windows GUI get the plaintext value (it’s only obfuscated on the display). All that without even trying to crack .NET’s code access security or protected memory.

If your attacker has this kind of control, you have lost. Therefore, that should be the first line of defense; make sure there is no such malware on the client computer, and that the instance of your client app that the user is attempting to log into has not been replaced with a cracked lookalike.

As far as obfuscated password storage between instances, if you’re worried about mem-snooping, a symmetric algorithm like Rijndael is no defense. If your attacker can see the client computer’s memory, he knows the key that was used to encrypt it because your application will need to know it in order to decrypt it; it will thus either be hard-coded into the client app or it will be stored near the secure string. Again, if your attacker has this kind of control, you have lost if you do your authentication client-side.

I would, instead, use a service layer on a physically and electronically secured machine to provide any functionality of your app that would be harmful to you if misused by an attacker (primarily data retrieval/modification). That service layer could be used both to authenticate and to authorize the user to perform whatever the client app would allow.

Consider the following:

• The user enters their credentials into your client app. These credentials can be the same as the AD credentials but they will not be used as such. The only way to prevent a keylogger or other malware seeing this is to ensure that no such malware exists on the computer, through enforcement of a good AV software.
• The client app connects to your service endpoint through WCF. The endpoint can be signed with an X.509 certificate; not NSA-level security, but at least you can be confident you’re talking to the server under your control.
• The client app then hashes your user’s password with something that produces a large digest, like SHA-512. This in itself is not secure; it’s too fast and the entropy of your user’s password is too low, to prevent an attacker cracking the hash. However, again, they have to have control of the computer to see the hash, and we’re going to further obfuscate it.
• The client app transmits the username, password and the Hardware ID of the client computer over the WCF channel.
• The server gets these credentials. Notice that the server doesn’t get a plaintext password; this is for a reason.
• The server cuts the hashed password into 256-bit halves. The first half is then BCrypted (using an implementation configured to be suitably slow; 10 or 11 “rounds” will usually do it), and compared with a hashed value in a user database. If they match, the DB returns the user’s AD credentials, which have been symmetrically encrypted with the other half of the password hash. This is why a plaintext password is never sent; the server doesn’t have to know it, but an attacker would in order to get anything meaningful out of a stolen copy of the user database.
• The server decrypts the AD credentials, submits them to AD, and receives the IPrincipal representing that user’s identity and security context. The IPrincipal implementation will contain zero information that could be used to crack the user’s account.
• The server generates a cryptographically-random 128-bit value, concatenates the 128-bit Hardware GUID, and hashes it with SHA512. It used half of that hash to symmetrically encrypt the key value that was used to decrypt the AD credentials. It then BCrypts the other half, and stores that hash beside the encrypted key.
• The server then transmits back three pieces of information over the secure WCF channel; the IPrincipal that AD produced, the unhashed 128-bit random value (the “transfer token”), and another cryptographically-random value of arbitrary length (the “session token”).
• The client app is now authenticated on the client side, meaning you can control user access to code by interrogating the IPrincipal for AD role membership, and the server is now also confident that the user who has the session token is a real user. When making any further calls to the service (data retrieval/persistence), the client should use the WCF channel that was negotiated, AND pass its session token. The combination of WCF channel and session token is one-time and unique; using an old token on a new channel, or passing the wrong token on the same channel, indicates the session has been compromised. Above all, none of the persistent data stored anywhere at anytime in either client or server can be used to get the AD credentials and authenticate.

Now, when your client application closes, all “session state” is lost between client and server; the session token is not valid for any other negotiated channel. So, you’ve lost authentication; the next client who connects could be anyone regardless of who they say they are. This is where the “transfer token” comes in:

• The “transfer token” is a free pass back into the system. It is one-time, and expires if unused 18 hours after it was issued.
• The client application, when closing, passes two pieces of information to the new instance (however it chooses to do so); the user name of the person who logged in, and the “transfer token”.
• The new instance of the client application takes these two pieces of information, and also gets the Hardware ID of the client machine. It negotiates a secure connection with the WCF service, and passes these three pieces of information.
• If the user last logged in more than 18 hours ago (not 24 hours, so they can’t show up a minute before they did yesterday and restart the app), or if you want to be really paranoid, more than 8 hours ago, the app immediately returns an error that the transfer token for that account is out of date.
• The service takes the transfer token, concatenates the Hardware ID, SHA-512s it, BCrypts half, and compares the result to the stored second verification value. Only the proper combination of the transfer token and the machine that last logged in will produce the correct hash. If it matches, the other half of the hash is used to decrypt the key that will then decrypt the AD info.
• The service then proceeds as if the user had provided the application password hash, decrypting the AD info, retrieving the IPrincipal, generating a new transfer token, session token, and re-encrypting the key for the AD data.
• If any part of this process fails (trying to use an incorrect token including using the same token twice, or using the token from a different machine or for a different user), the service reports back that the credentials are invalid. The client app will then fall back to the standard user-password verification.

Here’s the rub; this system, by relying on a secret password that is not persisted anywhere except the user’s mind, has no back doors; administrators cannot retrieve a lost password to the client app. Also, the AD credentials, when they have to change, can only be changed from within the client app; the user can’t be forced to change their password by AD itself on a Windows login, because doing so will destroy the authentication scheme they need to get into the client app (the encrypted credentials will no longer work, and the client app credentials are needed to re-encrypt the new ones). If you were somehow able to intercept this validation inside AD, and the client’s app credentials were the AD credentials, you could change the credentials in the user app automatically, but now you’re using one set of credentials to obfuscate the same set of credentials, and if that secret were known you’re hosed.

Lastly, this variant of this security system functions solely on one principle; that the server is not currently being compromised by an attacker. Someone can get in, download offline data, and they’re stuck; but if they can install something to monitor memory or traffic, you’re hosed, because when the credentials (either username/password hash or transfer token/hardware ID) come in and are verified, the attacker now has the key to decrypt the user’s AD credentials. Usually, what happens is that the client never sends the decryption key, only the verification half of the hashed password, and then the server sends back the encrypted credentials; but, you are considering the client to be a bigger security risk than the server, so as long as that is true, it’s best to keep as little plaintext as possible on the client for any length of time.