you're reading...
IT, Security

Password Management

Need a password store? You do you know.
The dilemma
The problem with securing anything these days is the same as it ever was:
Complexity Vs Easy of Use
Basically, no password should be in use in more than one location and no password should be simple or guessable, even with intimate knowledge of you.
The best option we have come up with so far is a Password Safe.
The idea is that you place all your passwords in a single repository and use a single, complex password to control access to that store. This allows you to use very complex passwords for all services.
Firstly, a few notes on Password Safes. The most important is to ensure that the security is up to scratch. For example this is one case where you must create a semi random password as the master password for the store. A simple password exposes the whole database of entries to abuse. One complex password should not be a big problem to remember.
Second, you must ensure the physical security of the Password Safe. By this I mean you must place it somewhere you trust and have complete control over. Be careful.
Many products are available and there are several approaches used, for example the LastPass system uses online storage making the data available on multiple platforms continuously. LastPass also includes an offline mode on some platforms.
You need to research each solution yourself. Now this is a complex set of products so here is what you want to see.

  • Seeded multiple encryption.
  • Randomised seeds.
  • 256 bit keys.
  • Complete file encryption.
  • Clipboard protection.
  • Keylogger protection.
  • Memory space protection.
  • Historic usage or log or change log.
  • Backup mechanism.
  • Export mechanism.

There are more but these are complicated enough.
I’ll go through each of these and the issues surrounding them.
Seeded multiple encryption
More choice here: what encryption to use. Most packages allow you to choose an encryption algorithm; AES, Twofish, SHA, etc. Technically SHA is what is called a hashing algorithm, a method of one way encrypting data such that only the original data compares successfully. This differs from encryption in that hashing normally generates an answer that is the same length every time, is one way and is only useful for data up to a certain length. So hashing an individual password, as done by Windows, Linux and all other OS’s, is valid but not a full database – which is too large. Plus you’d need to know the entire DBs contents to decrypt the DB, which obviously doesn’t work.
So what do you look for?
Most security experts are recommending that the key (password) used in the encryption needs to be suitably large, at lease 14 characters. Better still, use a one way password hash as the key? This means that anyone trying to decrypt the DB must first generate all the passwords via the appropriate hashing algorithm. Better still, seed the password with some other value and then hash and then encrypt!
Now you are talking! This means that the algorithm has effectively been customised. The seed of course can be guessed and depending on how it is added to the password the resulting table could still be prone to brute force attack.
The problem is generating and storing the seed effectively and securely.
Hacker Tricks

Use of Rainbow Tables against non-seeded password algorithms.
Local storage of password safe means it is likely to be portable and thus copied for decryption offline.
Passwords are most commonly comprised of real words or what are called “munged” words. An example is “App1e” where the “l” is replaced by the digit “1“.
Seeds are predictable if you know the algorithm and/or system that generates them well.
Physical access to the programming layer exposes the methodology of the encryption and seed generation.
Storage of seeds may be exposed.

Randomised seeds
Some applications are able to generate random seeds. This is especially useful if records are individually encrypted as each can be given a separate seed.
As with a global seed though, how do you store the seed value? This requires that the seeds themselves must be stored in an accessible format, for the program that is. It is often the case that the seed is repeatable programmatically. Thus now security of the code is essential and this now shows how complex security is. If all the data and program code is available then nothing stops the process being reverse engineered and the passwords decrypted.
The trick is making this as difficult as possible; trying to make the task computationally so difficult that it is effectively pointless.
The problem is generating and storing the seed effectively and securely.
Hacker Tricks

Enter a reference value into the system to see the output generated.
Offloading tiny bits of the computation to “zombie” clients that have no idea what they are doing (hacked PCs.
Humanise brute force attacks (we tend to use certain patterns, real words, items from our lifestyle etc.).
Physical access to the programming layer exposes the methodology of the encryption and seed generation.
Storage of seeds may be exposed.

256 bit keys
An alternative to passwords. You create a 256 bit random key and store that securely – usually in some physical device like a USB key. The advantage I you don’t need to remember a password but you must ensure that you always have the key available and ensure that it is secure. The worst thing you can do with a key is store it with the DB.
A variant of this is the asymmetric key pair. Here you create two keys (with one mechanism) called the Public Key and the Private Key. In our model the Public Key can be used to encrypt the data and the Private Key is the only thing that can provide access to decrypt it. Thus, as long as the algorithm used to generate the key pair is strong enough, public key can be distributed freely. The worst scenario is that the private key can be generated from the public key. Use of such keys is more prone to brute force, however and some specialised attacks are available to reduce the available options to a more manageable list on some public key encryption systems.
Complete file encryption
The entire DB should be encrypted and preferably with a hash of the key/password. If individual records are encrypted separately then the DB is far more prone to brute force attack. Two reasons, the individual records give far more options to apply guesses and some form of data must be exposed in the records (to index them) if the encryption is at that level. Of course you can encrypt the individual passwords further (in addition to encrypting the whole file.)
Consider here that the PSN, LastPass etc. exposures allowed unencrypted access to the names, email addresses etc but the passwords were encrypted/hashed.
Hacker Tricks

Gain physical access to the password store and then work on it offline.

Clipboard protection
Simple enough in theory, very hard in practice. Don’t let unauthorised access to data being copied. A tricky one this as The Operating System must expose the clipboard to wherever you wish. It doesn’t know in advance where the password is needed.
It is possible to prevent applications from knowing when the clipboard has changed (to a degree) and it is possible to use an alternative clipboard manager, although they tend to make applications, even the OS, unstable.
Hacker Tricks

Monitoring the Clipboard for changes.

Keylogger protection
Malware that squats on your PC and simply records all your key presses, sending them on to the hacker. Simple idea that is extremely effective. One option that works well is an on screen keyboard. The mouse is massively more complex to trace.
Additionally Windows and other OSs have secured login mechanisms that protect the called system – effectively locking any input given to that environment. These are likely to be worked around though as fast as they are improved.
Memory space protection
Simple: whilst you view the DB it is in a readable format. That would normally be the case for the data and program alike, though reading a program in memory is complex and usually fairly pointless. But the data should be encrypted when ever it is not directly processed to allow you to use/edit/view it. Here we want to view most of the data automatically but hide the passwords until asked for. So an application for password storage should encrypt the passwords again for storage in memory, until required. That can of course be randomised.
Historic usage or log or change log
As long as this is encrypted as strongly as the current password data then a must have is your history. This is where and when you have used what passwords where. This allows several things:

  • It allows you to recover an old password, if required – say for an archived or retrieved old version of a protected system.
  • It can prevent you from simply reusing the same passwords on a sort of loop. Bad idea that.
  • It allows you to see any trends in your passwords that might weaken them all. You might use a lot with your favourite comic characters – that would make it more guessable or easier to brute force.

Backup mechanism
A secured offline backup of any data is essential. No different with a password DB. The mechanism varies from product to product but all should include this ability.
One of my favourites, though it uses public transport, is an encrypted email.
Of course you can simply take a copy of your DB and store it elsewhere. But now you have two copies to keep secure.
Export mechanism
Of course all software eventually gets updated or obsoleted or newer, better products come onto the Market. Therefore an essential feature is the ability to export the entire DB – or individual records – into a format. That can be imported into another Password Manager. CSV is popular but many applications include export/import features for other password managers.
Common Sense Stuff
You do of course have some responsibilities yourself.

  • Never reuse a password. That last item shows you one thing, if a rival password manager can mimic the decryption algorithm then so can a hacker. No algorithm is safe if the hacker can trick you into giving up your password.
  • Never reveal a password to an external party. And this includes any untrusted applications. Technical support do not – in almost all cases – need to know your password.
  • Look for application reviews. Don’t install software until you read a few reviews from trusted sources. It is common for applications to include malware and one indication is a large number of adverts but no reviews from magazines or security sites. Err, um, also look out for fake reviews (sorry but they do exist).
  • Check the location you are downloading from. A common trick is to mimic a trusted piece of software (and what better than a password manager) and redirect potential users to that malicious download. Check the authors own site and where they say to download it from.
  • Physically secure your password manager. One of the main problems is ensuring that only you can access the DB. I recommend that you keep it on a USB key attached to something you treasure, like your car keys. USB keys can themselves be encrypted. Of course, lose the keys and you lose the DB. So make a backup!!!
  • Never ever write down your master password.
  • Ok, I have an exception here. You need a “break glass” mechanism so work or family can access your files/systems if the worst should happen, perhaps. However that is only required if it is not possible to alter a password that is stored in the DB. For example, you might encrypt your financial records, storing the password in the password safe. In this case the only way of accessing those records is to have access to the password, as stored in the DB.
  • Trust. You must have absolute trust in the mechanism you use as a password manager. Easy of use is important but the solution must be secure. Also, if the passwords are for a system owned by another person you should check if they have any policy or advice. A good example is that most corporations will be very upset if you were storing system passwords on an external service that they have not authorised, regardless of how secure they are.
  • Lastly, be prepared to change ALL your passwords regularly or if you lose a copy (including any backup) of your password DB. Similarly if there are any security alerts for the password management software/system. If you are ever infected by malicious software then use one of your offline backups and change ALL your passwords.
    A real pain but better safe than sorry.

For the record…
My favourite is KeePass.
– Posted using BlogPress

About harlekwinblog

"Thoughts of an idle mind." Information Security professional.


No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


RSS This Blog…

  • An error has occurred; the feed is probably down. Try again later.

Share me…

Bookmark and Share

Twitter Updates

May 2011
%d bloggers like this: