I use KeePass from SourceForge to store passwords for numerous websites.  Generally, this is held on a USB stick that I can add to a computer when I need a password, then remove – back to the safety of my pocket.  If I lose the USB stick, the password database is encrypted and all is safe.  I ASSUME that I’ll lose lots of the USB sticks, but history says I’m pretty good at keeping track of them.

After having my Am Express card number stolen last week, I have become MORE paranoid about where the secrets are stored.  Just because a program is running as “joe”, does not mean that said program should be permitted access to the password database.

Notice that I am assuming that evil program has the ability to find and copy the password database and that it also has the ability to log key strokes to gather the unlock password (paranoid).  A check of file locking tells me that KeePass does not hold a read lock on the password database while it is loaded and that’s too bad; this would block evil doers from reading the file while the password program is running.  The counter is that it allows the password database to be backed up while the program is running, classic trade offs of security and usability.  I can add the missing locks using XenVault.

More walls of defense

If I can keep the evil program from being able to even see the password database, then I can prevent it from copying the database.

Running programs in separate user contexts is one solution, but with XenVault, we have another very usable solution available.  Recall that XenVault regulates access to the vault (encrypted space) based upon the corporate/not corporate nature of the application.  Here’s a blog that describes how this works.  Being labeled a corporate app opens the gate for access to the vault.  If not a corporate app, then you can’t get into the vault.  This is configurable by the admin who deploys XenVault, but let’s assume that the vault is running in this locked mode, mine is.

KeePass needs to become a “corporate” app

Corporate apps are:

  • XenApp hosted sessions (client drive mapping)
  • XenApp Streamed applications running on the workstation
  • Microsoft App-V applications running on the workstation

I profiled up KeePass using App Streaming and published it to myself.  It is now a corporate app.  Since I don’t like to carry much infrastructure, I skipped all the delivery services console stuff and published it to myself using a .BAT file and a direct call to RadeRun.  This is quick and means that I don’t have to maintain the Web Interface or XenApp farm – and that I don’t have to stop using the main corporate set which is published to everyone.

Administrators CAN configure the streaming client to refuse to run things not published by the admin, but since I’m my own admin, this is turned off.

Here’s the BAT file to run KeePass.  My AppHub where the profile is stored is “C:\Pack”, so absolutely everything is “local”.

setlocal
set PROGFILES=%ProgramFiles%
<span class="code-keyword">if</span> <span class="code-quote">"%PROCESSOR_ARCHITECTURE%"</span>==<span class="code-quote">"AMD64"</span> set PROGFILES=%ProgramFiles(x86)%
set RADERUN=<span class="code-quote">"%PROGFILES%\Citrix\Streaming Client\RadeRun.exe"</span>

set APPHUB=C:\pack
set PROF=keepass
set APP=KeePass
set SWITCHES=

start <span class="code-quote">"" %RADERUN% %SWITCHES% /<span class="code-keyword">package</span>:"</span>%APPHUB%\%PROF%\%PROF%.profile<span class="code-quote">" /app:"</span>%APP%<span class="code-quote">" /extracmdline:"</span>%*"
endlocal

Then create a shortcut to that bat file, place on the desktop and all is “published”.

Back to XenVault

Now that KeePass is a corporate application, it will be allowed to read and write to the vault, and it will be prevented from writing to anywhere else.  This is fine, the ONLY thing the password program will be writing at runtime is the password database, simple.

Final step is to import the data, which can be done by reading from the USB stick and then file save-as to write it to the encrypted space, done.

Observe that the encryption aspects of XenVault here are completely redundant.  The password vault is already encrypted and now it is being stored onto an encrypted disk volume.  The important part in this use of XenVault is having the XenVault system control the ACCESS to the files.  That these files happen to reside in an encrypted space is “bonus”.  In my case, the vault is already password unlocked, so it exists as a volume and I’m assuming that the bad guy has the ability to run programs in my context, so the only protection is preventing access based on WHICH application I am running.

Once done with this exercise, the vast majority of potentially evil programs (e.g. web browser) are blocked from seeing the secret stuff.  I’d like to lock this down even further.

Conclusions

  1. Publishing my pw storage method to the WWW seems like a stupid idea.
  2. All applications on my machine that are not “corporate” cannot see the vault which means that they cannot see the password database, good.
  3. I no longer have to insert USB stick to get to passwords
  4. I can control which applications are “corporate”, so limits the exposure.
  5. I could combine this with separate user contexts (DACL protection) to further reduce the exposure.

Does this make me more secure?  Probably.

Several people have suggested that I revert to pen and paper.

Joe Nord

Product Architect – Citrix Systems

App Streaming, Profile Manager, XenVault