What exactly does “Security through obscurity” means in the context of stroing unencrypted passwords?
I’m using a small program (I won’t name it, to not enlarge enough large shame on its author) that uses my Google account for some tasks. I’ve noticed, that it stores my password in plain-text unencrypted file. Just a string, clearly seen to everyone, that can drag&drop it to Notepad or use F3 in Total Commander.
I have risen a ticket asking program author to fix this ASAP. I haven’t got any reply yet, but my issue got one comment, that includes only above mentioned link to Wikipedia’s “Security through obscurity” page.
How should I understand this comment? Is it pro or con my issue? At first I thought, that it supports my statement of fixing this ASAP. But then I found a Eric Raymond’s Fetchmail example (in “The Cathedral and the Bazaar“), who refused to implement config file encryption (passwords are stored in config file for Fetchmail), claiming that it is up to the user to assure security by not letting anyone “from the outside” access that configuration file.
This statement (or refusal) is often brought as example of Security through obscurity. And looking from this point of view, I’m completely wrong and that program author is right. He do not have to implement encryption of file with my password, it can remain there, stored unencrypted and it is I, who is responsible for assuring security by not giving anyone access to this file or by deleting it each time I stop using that soft.
(another question is, how can I achieve this on system as unsecure as Windows itself?)
These seems to be in a complete opposition, to what I’ve been told and learnt for years, so I would like to ask more experienced developers, who is right here and how exactly I should understand “StO”?
3
The problem is that data encryption is unnecessary, when data and key are kept on the same system.
When the application would encrypt your password, it would have to include the decryption algorithm and the decryption key. Anyone with access to your data could just extract algorithm and key from the program itself and use it to decrypt the password file.
That’s why encrypting your password would just be security through obscurity. When I get 10 minutes alone with your computer, I just need to look at the file with the encryption key in addition to the file which stores your password to obtain your login information.
The only way where it makes sense to encrypt local data is when you use a passphrase as decryption key which is not stored and must be entered by the user manually everytime the encrypted data is accessed. But when the only data which is protected by that scheme is another password, you could just have the user enter that password instead.
6
From Eric Raymond’s design notes on Fetchmail:
Password encryption in .fetchmailrc
The reason there’s no facility to store passwords encrypted in the .fetchmailrc file is because this doesn’t actually add protection.
Anyone who’s acquired the 0600 permissions needed to read your .fetchmailrc file will be able to run fetchmail as you anyway — and if it’s your password they’re after, they’d be able to rip the necessary decoder out of the fetchmail code itself to get it.
All .fetchmailrc encryption would do is give a false sense of security to people who don’t think very hard.
The problem here is that if someone has access to the encrypted configuration file, they already have everything they need to impersonate you, as the only other thing they need is fetchmail itself. Therefore implementing password encryption on fetchmail is in fact “security through obscurity”, and completely useless.
I suspect that’s what the commenter meant. Regardless, you shouldn’t really lose any sleep on the comment and wait for the developers to reply officially. If they refuse to encrypt the password, you could post a followup feature request asking for a way to use the tool without storing the password (on disk).
9
“Security through obscurity” refers to the mistaken attempt to provide security by keeping the details of a mechanism secret (algorithms, cipher schemes, protocols, etc.). This is generally considered bad practice. Security practitioners should always assume that the enemy knows all details of their mechanisms, and build systems that remain secure even then.
But passwords, tokens, etc. should obviously be kept secret, in fact they are the only parts of secure systems that should be considered secret.
The principle therefore supports your point of view. But this is the Internet! It is entirely possible, that someone misunderstands this term badly enough, to think, that it refutes your ticket.
2
As everyone here, I fully agree that obscurity is not a solution to store password. However, I would like to point out that there is another solution, not based on obscurity, that can, more or less, achieve the wanted goal.
The idea is easy: encrypt the password using a tool like PGP. This kind of tool asks for a master passphrase the first time you need to run PGP, and then it keeps in memory the secret, and can decrypt all the wanted files as long as the computer is on.
Drawbacks:
- you need to type a password the first time you need to call the PGP tool
- the user needs to configure the PGP tool at some point
Advantages :
- it is secure as long as the attacker has no access to the (volatile) RAM memory (which is obviously the case when you do a backup)
- even if you need to type the PGP passphrase at the beginning, you can use the same PGP key for all the applications that would need it, so it’s not really a big deal to type once the password
So for me, the best way to design tools that need to store password is:
- provide a way for users that do not care about security and prefer simplicity, by storing by default the password as a cleartext
- provide a way for users that care about security to provide a command line that would get the password. That way, the user can provide a command that would call PGP with the good key on the good file
If only fetchmail was designed that way…