I should probably mention this, even though it’s not actually worth mentioning: Raccoon v4.1.6 reverts to the Raccoon v3.x policy for storing credentials. That is, your password will be stored on disk again.
Back in the Raccoon v3 days, username and password were kept in plain text in the config file. It was either that or prompting the user for credentials whenever the application was started. Nobody wanted the later, but some people weren’t happy with plain text passwords in config files either and kept pestering me to encrypt it. Needless to say that this would have been as pointless as locking your front door and then placing the key on top of the mat (see below for an explanation). Having the same discussion over and over again was/is a waste of my time, so, starting with Raccoon v4, I used a little trick: I switched from storing the password to persisting the session cookie (luckily, with Google, everything is modelled around HTTP, even if it doesn’t run in a browser). Of course, the session cookie is almost as sensitive as the password, but without people realizing what they are looking at, there have been no pointless debates since.
Unfortunately, Google recently changed a couple of things and the session cookie is no longer as stable as it used to be. So we are back to square one: your password get’s stored in the database again, allowing Raccoon to automatically log back in, once a session becomes invalid.
That brings me back to the point of this blog post: why your password is not encrypted (and won’t be).
Raccoon/Play is a client server application. The client has to identify (username) and authenticate (password) itself to the server in order to get service. Sending the server an encrypted version of the password is the same as sending a wrong password (you won’t get service). For this reason, the client must know the plain text version. The only way around this would be to let the server encrypt the password and only persist that on the client, but in that case, as far as authentication is concerned, the cypher text becomes equivalent to the plain text and you’d gain nothing except extra complexity.
Since the client must know the plain text password in order to authenticate, storing an encrypted version really does nothing in terms of adding security. The first rule of cryptography is to never keep key and the cypher text in the same environment. Obviously, you’d do exactly that when the Raccoon binary reads the encrypted password from the database, then decrypts it in order to authenticate with Play.
Let’s put the last paragraph into less technical terms: the whole point of cryptography is to keep your data undecipherable in a hostile/untrusted environment. Your PC is not enemy territory and encrypting your files is not a reasonable safeguard against whatever malware you are looking forward to running on your box! If, at any time, you suspect your computer to not being under your control any more, the correct course of action is to reinstall the whole system and change all of your passwords, not to assume that the attacker is unable to decrypt your files.
