Webbased Password Managers
In this post I’ll describe problems that arise when you try to develop a webbased password safe.
Imagine an arbitrary company with lots of employees, each using many passwords for many different authentication purposes. Imagine different employees using different operating systems. To avoid them having bad cleartext passwords on their disk, you would like to have a central and universal password manager running on a server keeping the passwords of different users, each having a strong master password to access all his passwords via his browser. You want the password manager to be as secure as possible, beause you have to keep passwords for company related systems and you want it to be as secure as any existing client-wise password manager, of course.
A naive approach, at first. Any attempt to access passwords has to be encrypted, of course, especially when we send passwords over an (insecure) network. Therefore we have to use SSL and the password manager has to enforce HTTPS. If we are trusting the server (that means: we have to ensure that the server won’t get compromised), we won’t have to encrypt the passwords on the server and we can store them in simple text files. But if the server ever gets compromised, all passwords are lost. To avoid cleartext passwords saved permanently on disk we have to encrypt them like every password safe does. We decrypt them when a user is authorized and wants us to and we store them within the server’s memory, but if someone can access the RAM the passwords are lost, too.
A password safe typically only stores passwords of a single user. In contrast, our webbased password safe stores passwords for the whole enterprise. Therefore, a server-compromise is more critical and imagine employees interested into reading other employee’s private mails, social network accounts and so on (aka insider attacks). We can solve this problem by never keeping a password in cleartext on the server, neither RAM, nor HDD. The encryption has to happen on the client. Therefore, we have to encrypt them on the client (within a browser). The guy compromising the server will get the encrypted files, but he won’t get the clear text passwords easily. Of course, he can bruteforce the master password, use cryptanalytical methods or just stay behind another employee’s neck while he is typing the master password, but every password manager has to deal with that possibility (but we have a central login now) and we can enforce strong master passwords and encryption centerally. This paradigm is related to Host-Proof-Hosting (”Host sensitive data in encrypted form, so that clients can only access and manipulate it by providing a pass-phrase which is never transmitted to the server“).
The encryption and decryption on the client could be done with javascript (ecma-262 and clipperz), but how secure could, for example, an AES javascript-implementation be (not from a cryptanalytical point)? Is it guaranteed that passwords won’t be stored for long time within the client’s RAM, because we have to wait for javascript’s garbage collector? Usual password safes are written in C and they can manipulate memory directly. A javascript implementation is not able to do that. To show that, lets take a look into our memory while executing this with firefox 3.0.6 in a virtual machine running Debian Lenny and using the KVM - virtual machine monitor:
var key = ""; for(var i = 0; i < 3; i++) key += "M"; for(var i = 0; i < 3; i++) key += "1"; for(var i = 0; i < 3; i++) key += "K"; for(var i = 0; i < 3; i++) key += "Y"; for(var i = 0; i < 3; i++) key += "9"; key = "";
Suppose, ‘key’ is a cryptographic key. We concat the key to be sure that we don’t have it as a complete string before we’re using it within the javascript code. We execute it and dump the memory using the kvm monitor mode:
pmemsave 0 134217728 memory.dmp
If we search for the key MMM111KKKYYY999 within memory.dmp we’ll find it. No surprise, javascript uses reference semantics, but the garbage collector doesn’t free the (now) unreferenced string. There is no way we can overwrite the portion of memory ‘key’ was using. There are good reasons to let us not do that, because direct memory manipulation with javascript would be a very bad idea.
After we’ve left the website we dump memory again and this time we won’t find the key. Firefox 3.0.6, Chrome 2.0.172.43, Internet Explorer 6 and Opera 10 all show this behaviour. Therefore, a webbased password manager should force users to leave the page after a certain amount of time and - maybe - the password manager should only work with approved browser versions (versions that show this behaviour), because it is possible other browser (versions) store it even longer. But that will result in less flexibility.
Some huge problems remain, though. The largest: injecting malicious javascript code into the client. The javascript code is responsible for encryption and decryption on the client, but the code is loaded from the server dynamically. A server compromise is therefore still the biggest issue, because an attacker could inject malicious code into all clients and steal all passwords. Therefore, the code itself has to approved in some way. Clipperz, for example, is of course aware of this problem and agrees: “there are no perfect solutions to avoid this problem“.
In a nutshell, a webbased password manager could have different levels of security.
- Security only lies within secure transportation (HTTPS) of passwords to the client to avoid sniffing passwords. Cleartext passwords exist on clients and on the server hosting the passwords, both for an (nearly) arbitrary amount of time.
- Cleartext passwords only exist on clients, but for an (nearly) arbitrarty amount of time.
- Cleartext passwords only exist on clients for a predefined period of time.
Option 3 is the most inflexilible one, because we have to use approved components only (Browser, Javascript implementation, Operating System’s clipboard implementation, Javascript-Code and so on) and whether we decrypt passwords only on the client or not, we have to trust into the server, because we have to trust into the application and if the server is compromised, an attacker could inject malicious code.