Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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"?

share|improve this question
    
I'd uninstall it, and leave a comment on the relevant store page for the app to the effect that it doesn't encrypt the password. That might chivvy the author along to fix the issue. –  Alan B May 13 '13 at 8:00
1  
A workaround could be to have that program's config file in a truecrypt container. You'd have to unmount the container everytime you leave the computer. As Yannis said below, urge the author to make it the default not to store the password on disk. –  ott-- May 13 '13 at 8:19
2  
I'd just like to add that Google provides a mechanism for generating application-specific passwords that you may wish to use in this case: accounts.google.com/b/0/IssuedAuthSubTokens?hide_authsub=1 This way, if something bad happens you can just revoke access to your account through the generated password. –  Ajedi32 Jan 31 at 20:42
add comment

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
Look at my comment-based discussion to above answers. I'm a semi-pro computer geek with 20+ years of experience, but I would most certainly fail to do, what you wrote, not only within 10 minutes, but also within 10 hours. But I wouldn't fail to read password out of unencrypted, plain-text configuration file. Plus: we're talking about storing passwords for external service (Google Account), not internal, this-program only passwords, which changes the case a little bit in my opinion. Plus, read about non-atack scenario above, where my friends are getting access to my GA password, by accident. –  trejder Feb 3 at 10:26
1  
@trejder But that's the definition of StO. You would only take 10 hours because you don't know where to look. When a security scheme breaks in front of an attacker which knows where to look and what to do with what he finds, it's security through obscurity. –  Philipp Feb 3 at 10:28
    
I still don't get you (need coffee!). Only because this example falls under StO definition, it is OK, that anyone can have access to my Google Account password, stored in some creepy program in a plain-text without any encryption. Only, because it would took you 10 minutes to break that encryption, there is no need to implement it? How then I can protect my Google Account password, on system as insecure as Windows? Stop using this program at all or face the fact, that it stores my password (not to program itself, but to well known service) insecure? I must be missing something very obvious. –  trejder Feb 3 at 10:39
1  
@trejder To obtain the password, the attacker needs either physical or remote file system access to your machine. As long as your take basic IT security precautions, that should hardly be "anyone". –  Philipp Feb 3 at 11:58
1  
@trejder One person who knows how to do decrypt the file writes a program to automate it. After that anybody can do it simply by using that program. –  CodesInChaos Feb 3 at 12:33
show 1 more comment

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).

share|improve this answer
1  
It seems, that your point of view is centralized on attack scenario ("If someone has access..."). In this point of view, I agree with you. But, try to look my way. This is a Windows program. I occasionally archive (backup) software, that I use, on my home server. I granted access to this server to about 3-5 my close friends. This program hasn't got any installer, it is just zipped. So, my password is stored there, unencrypted. Though I like my friends really much and trust them (that's why they do have access) I don't want them to unzip this program and see my password. Period. –  trejder Feb 3 at 9:15
1  
@trejder: Okay, but if somebody can unzip the program and see your password then they can run the application and access your google account anyway. Your problem in that scenario is unprotected backups, which is something you can actually fix. –  Phoshi Feb 3 at 9:47
1  
@Phoshi No way! If password would be encrypted and someone would gain access and run that program, all he or she could do, would be to download some *.apk files (Android's applications installation files), because that is all this program is able to do. With storing unencrypted, plain-text password, anyone who has access to my ZIP file / program can do anything with my Google Account. Do you now see my point? –  trejder Feb 3 at 10:01
1  
@trejder: The decryption routines still exist within the application. Even if it's closed source, you could pull the decrypted password out of memory or out of the login request. Yes, encrypting the password would stop non-techy friends from accessing it, but so would encrypting your backups properly, and encrypting your backups doesn't give a false sense of security while only protecting from the most trivial attacks. –  Phoshi Feb 3 at 10:17
    
@Phoshi That's your point of view and I respect it. However, you haven't convinced me to change my mind. I think your ship is going quite a wrong wave. Since I'm giving any program my Google Access password, it is that author's responsibility to keep it secure. It has nothing to do with securing (or not) my backups. I repeat once more. If that would be password used only to that program, I would agree with yours and Yannis argumentation. But since this is a external, 3rd party service (Google Account) password kept insecure, I again say, that this is very, very wrong to put it to plain text. –  trejder Feb 3 at 10:29
show 4 more comments

"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.

share|improve this answer
2  
The problem here is that an encrypted configuration file is not secret. If you have access to it and its decoder (the tool), then it's as secure as plaintext. –  Yannis Rizos May 13 '13 at 8:05
1  
@YannisRizos Again, in general, you're right. In details, I think you're wrong. Read first sentence of my question. We're talking about program that helps me manage my Google Account. And it kepts my Google Account's password unencrypted. So, in this particular case, attacker only need access to configuration file, to gain access to my Google Account. It does not need access to the tool itself! If I'm getting you right, your logic would be complete and correct, if that tool would store its own password unencrypted. But it stores external, 3rd party service's password completely insceure way. –  trejder Feb 3 at 9:20
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.