3

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

Improve this question
3
  • 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, 2013 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, 2013 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, 2014 at 20:42

4 Answers 4

Reset to default
5

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.

Improve this answer
6
  • 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, 2014 at 10:26
  • 5
    @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, 2014 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, 2014 at 10:39
  • 2
    @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, 2014 at 11:58
  • 2
    @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, 2014 at 12:33
14

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

Improve this answer
9
  • 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, 2014 at 9:15
  • 2
    @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, 2014 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, 2014 at 10:01
  • 2
    @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, 2014 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, 2014 at 10:29
6

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

Improve this answer
2
  • 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
    May 13, 2013 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, 2014 at 9:20
1

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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