Dealing with passwords
Sun, 11 Jan 2015 19:03:09 -0000
Every once in a while I struggle on how to deal with various login passwords. Here is an overview about the current status of my knowledge and attitude towards it...
Update: Corrected some mistakes.
Update: Some further corrections.
Update: Corrected Spelling error
Update: Corrected minor flaw


The classic way to restrict access to physical places, lets say to a building, is to use keys. In general, everybody that has the key is able to enter the room, or, in more fancy words, anybody who can prove he is in possession of a special security token is authorized to access. Now this scheme has been working neatly for the past at least two thousand years, the lock mechanics have been improved quite a bit in the course of times, but the principle remained the same. Controlling access to virtual places and goods, be it the admin part of this web page or an online banking account has become at least comparably important as to physical places. Thereby, the proof to possess a certain physical has been replaced by proof of knowledge, usually a password. Just as with a room being able to be unlocked by anybody who got the key, anybody who has the appropriate knowledge (password) is able to access a certain mail account. Keys can be lost, and passwords forgotten, bearing the same consequences. Despite their similar functionality, there exist some remarkable differences between both concepts. At first, passwords and keys can be stolen, but keys are unique physical items. If somebody steals the keys from his owner, his owner does not have the key anymore and thus is in principle able to notice the theft. Since passwords are knowledge and knowledge cannot, in a strict sense, be stolen but rather only be shared the owner wont be able to detect easily if somebody else was able to seize this knowledge as well. You cannot easily determine whether your mail password has been stolen because unlike a key you still will possess it even if somebody else got hold of it . Moreover, since crafting a password is done easily one can try to simply guess a correct password even if he does not know it. For keys, this would be rather unfeasible, since crafting a key is very resource consuming. Still locks can be picked thus enabling one to surpass them without actually possessing the key, but again picking a lock requires much more training and knowledge than just guessing on passwords. On the other hand, once contamination of a password has been detected, it is easily changed, changing the key for a room is harder since it requires to manufacture not only a new physical key but also manufacturing a new lock and replacing the old one by this new one. Since both security concepts bear advantages and disadvantages and since stacking several different security concepts within a system will only make it safer and never more unsafe, for critical systems it is becoming more and more common to protect access by physical keys ("security tokens", smart cards) and passwords as well (that is one possibility to implement two factor authentication ). However, for usual applications like mail account protection using passwords only is state of the art (unless if you look at Google, which provides two factor authentication for its services).
Now what can be done for either authentication method to work around its limitations? Countering the disadvantages of keys is done quite easily:
  1. Chose a lock that is well designed and state of the art
  2. Ensure that the key wont be lost or stolen (for example by simply chaining it to your beld)
Countering the disadvantages of passwords can be addressed by using strong passwords, i.e. using real random character sequences of sufficient length in order to prevent guessing. Moreover, it is wise to assume that once in a while, a password will be stolen nevertheless and try to minimize the consequences ot a theft by:
  1. Change your passwords regularly
  2. Dont use one password for several times or several different accounts, but use different passwords for different applications.
However, a password must be remembered by its owner, otherwise he will be locked out or tempted to somehow 'store it outside of his memory', e.g. by writing it down. Writing down passwords is a really bad idea, because all the disadvantages enumerated for physical tokens apply for written down passwords, in addition to the disadvantages of passwords. This clashes with the demand for strong passwords.
security always competes with usability and if security measures cut down usability too harshly, users wont make use of them.

The advantages of Password managers

Of course, in an ideal world, everybody would be able and willing to memorize 20 character random strings by looking at them once and thus use different strings for every single of his accounts and keep changing them every day. Reality does not comply to these demands, however. As mentioned above, an unrecommended way of solving this memorizing issue is to write the passwords down. The drawback is, that again, that the notepad the passwords have been noted down on would become the master key for all accounts, with all drawbacks of physical keys noted above. Storing the passwords digitally and encrypt them using another master password would circumvent this problem, at least partially. You only need to remember one password instead of dozens for all your accounts. There are programs to perform exactly this task. Now, in order to access any of the accounts of which the password has been stored in the password manager, a thief would have to get into the possession of the password database as well as the master password. This solution is definitely better than using one password for all accounts, since now you will have to know the one-and-only master password, and additionally, be able to access the password database. Last but not least, changing the passwords for the accounts is rather uncomplicated since you do not have to memorize it but just enter it into the password store.
Of course, dealing with passwords this way is not the optimum, but can only be a compromise. But compared with the way usual users deal with passwords it is a great advance.

The optimal password manager

There are a couple of password managers around, and of course I did not even hat a short glimpse on every single one of them, and I doubt that the one I am going to talk about now is the best choice. But before even looking at implementations, it is always good to think about what requirements an ideal implementation should fullfill. These requirements need not be the same for every single person. An optimal password manager for me should meet the following:
  1. It should be Free Software
  2. The cryptograpy used should be as reliable as possible
  3. It should be easy to use, which means it should have a clean and lean user interface
  4. If possible, it should be possible to synchronize the database easily onto other devices - safely
As for the last point, of course it does the overall security of the password database no good to provide synchronization and spread it onto several devices. It is important to realize that this lowers security and it is crucial to think about the consequences and the likelyhood of leaking the password database. I reached the conclusion, that I am willing to bear the increased risk that accompanies the sync feature.
However, looking at a real implementation will be - if nothing else - teaching.

A 'case study'

The manager I will talk about is UPM. I did not choose taking about it because it was the best manager around, but because simply I know it.
UPM is free software.
Digging through some documentation it looks as if it used AES with an 128 bit key for encryption, which I consider unnecessarily weak. AES itself is fast and often already implemented in hardware, but decrypting a password database should not pose great performance requirements. AES itself is also not the best of all choices when it comes down to security. As far as I am aware of it has not been broken in the sense of there was a general attack that would enable an attacker to decrypt encrypted data or reconstruct the key, but at least theorecical attacks have been found , like this one. Morever, when using AES, why further weaken the cypto by using short 128 bit keys and not the available full 256 bit for the key?
I personally want to use a password manager on my mobile, which got an encrypted SD - card and on my laptop with the hard disk and swap partition being encrypted. Therefore, for my usage scenario the weak database encryption is not that nasty since the encrypted database will be encrypted again when stored persistently. In the RAM of either my laptop or my mobile the database will end up unencrypted anyhow (for my mobile, I dont know the encryption algorithm and keylength, though. That should be barely acceptable, but I dont know how to deal with if I found out it used a weak or broken encryption anyhow).
As aforementioned, UPM provides for synchronization of the database. This can be done by using a dropbox account (what I refuse to do due to the weak encryption of the database) or set up a webserver capable of running PHP code and synching the database to / from this server via HTTP. In the second case, UPM supports HTTP over SSL/TLS which should prevent eavesdropping by some man-in-the-middle. It also supports Web login which prevents an attacker to just download the database from the server. I highly recommend to protect the database with the web login mechanism , all the more since the database itself is encrypted very weakly. And anyhow, synchronization is done automatically, so why dropping security? Regarding SSL/TLS UPM seems to not support TLS v1.2, which is a real pitty since older SSL/TLS versions have to be considered broken. For my situation, this poses some serious problems since apart from the inherent security decrease for the password database I use the web server for delivering other stuff via HTTPS as well. Downgrading the HTTPS security by enabling SSL v3 would also affect the security of these other services. For me, this is still an open issue.

Putting it into a nutshell

To put it into a nutshell, password managers are a reasonable compromise in between security and usability concerns. Looking at UPM, one possible implementation reveals several weak drawbacks in the security design of at least this manager as well. It should be assumed that other implementation will suffer from similar disadvantages. So password managers cannot be recommended in general, but every user should at least be aware of the fact that the security of the manager is dependent on the quality of the implementation. Every user should be aware of the risks and consider whether the advantages outweight the disadvantages for his personal purpose.