Better protection for credentials

[IzzySoft]

Currently, Raccoon stores credentials plain-text in plain-view, which poses a security risk (at least on systems with multiple users). Would you consider …

• adjusting file permissions (on *nix systems) to keep "others" out? Instead of 664 for the credentials file, I'd suggest 600 (full access for owner, no access for anyone else). This should be easy to achieve.
• ask the user whether to store the password (and offer means to revert a decision on this). What's not stored cannot be copied ;) Again, relatively easy to do.
• use some encryption on stored passwords might be an option as well – though that rises the question of how to make that transparent, bi-directional and safe at the same time (you'd need to decrypt the password for the login). So this would be more difficult to achieve.

I'd recommend a combination of the first two items: number one definitely increases security without "impact" on the user, and number two is up to the user then.

[IzzySoft]

PS: Manually tested the first approach

chmod 0600 ~/Raccoon/archives/default/credentials.cfg

No side-effects so far :)

[onyxbits]

I won't do any more work on v3.x as this is legacy code now. All efforts
go towards v4.x. As for the issue at hand:

• Users can manually adjust the permissions if needed (the use case is
  rare these days anyways).
• v4.x will no longer store a password, but an auth token. Still not
  something you want to let fall in the wrong hands, but I object to
  including a "store password" checkbox. Thats just wasting resources on
  something no one will uncheck.
• I get pissed off when people tell me that storing a plain-text
  password in a config file is a security risk and then seriously suggest
  that encryption would be a solution.

Am Donnerstag, den 19.11.2015, 15:28 -0800 schrieb Izzy:

Currently, Raccoon stores credentials plain-text in plain-view, which
poses a security risk (at least on systems with multiple users). Would
you consider …

  * adjusting file permissions (on *nix systems) to keep "others"
    out? Instead of 664 for the credentials file, I'd suggest 600
    (full access for owner, no access for anyone else). This
    should be easy to achieve.
  * ask the user whether to store the password (and offer means to
    revert a decision on this). What's not stored cannot be
    copied ;) Again, relatively easy to do.
  * use some encryption on stored passwords might be an option as
    well – though that rises the question of how to make that
    transparent, bi-directional and safe at the same time (you'd
    need to decrypt the password for the login). So this would be
    more difficult to achieve.

I'd recommend a combination of the first two items: number one
definitely increases security without "impact" on the user, and number
two is up to the user then.

—
Reply to this email directly or view it on GitHub.

[IzzySoft]

I get pissed off when people tell me that storing a plain-text password in a config file is a security risk and then seriously suggest that encryption would be a solution.

If you read between the lines, you see that I doubt that as well ("might be an option", "raises the question", "difficult to achieve"). I was just brainstorming with options – so please don't feel offended 😇 Consider the auth token solving this part.

I'm fine with applying the chmod command manually. Still I feel the application should do this. It's not just the "multi-user setup" – but consider some malware running as a different (system) user … OK, call me paranoid 😜

[onyxbits]

I'm sorry for lashing out. But as I said: I get pissed on that topic.
It's a non-solution for what should be a non-issue and I have to waste
time on explaining this over and over again.

Malware on the system is not an argument for encrypting your files. It
is an argument for reinstalling and changing passwords.

Am Samstag, den 21.11.2015, 05:23 -0800 schrieb Izzy:

    I get pissed off when people tell me that storing a plain-text
    password in a config file is a security risk and then
    seriously suggest that encryption would be a solution.

If you read between the lines, you see that I doubt that as well
("might be an option", "raises the question", "difficult to achieve").
I was just brainstorming with options – so please don't feel
offended 😇 Consider the auth token solving this part.

I'm fine with applying the chmod command manually. Still I feel the
application should do this. It's not just the "multi-user setup" – but
consider some malware running as a different (system) user … OK, call
me paranoid 😜

—
Reply to this email directly or view it on GitHub.

[IzzySoft]

No offense taken. Let's just pretend nothing happened :)

Malware on the system is not an argument for encrypting your files. It is an argument for reinstalling and changing passwords.

Agreed. But that's for when it's already there. There's no such thing as "100% safety" – and the system being clean today doesn't mean something can happen tomorrow.

There're good reasons for file permissions. And whenever "sensible information" such as passwords come into play, you get the advice to care for them. Just try to have your ~/.ssh folder with any permission other than 0700 (i.e. no access for group and other) – SSH will yield an error and not use it until you've fixed it back. For good reasons, as said.

But well, I'm fine adjusting that myself (as pointed out above) – so feel free to close this issue ;)