Hacker News Reader

Comment by AshamedCaptain | Hacker News Reader

The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.

One example I remember is Pidgin storing its passwords in plain text in $HOME. They could have encrypted them with some hardcoded string, and made a lot of people happy that they would no longer grep their $HOME and find their passwords right there. However this had the side effect that now people were dropping the ball and sharing their config files with others. Or forgetting to setup proper permissions for their $HOME, etc.

In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.

View on HN

Why a hardcoded string and not a user specific password the user used for pidgin? Then you’ve got real security and even using a password stored in the user’s keychain means that the passwords are not trivially accessible.

The whole point of security in depth is that you use non colinear layers of protection to raise the cost of an attack and reduce the blast radius of a successful attack.

Pidgin predates keychains, but if I remember correctly you had the option to set up a master password or to simply disable storing passwords, which were the only options that were truly incrementing security. But most users would not do that (they want autologin for a reason), so the example still applies.

(Note also most keychain implementations are not truly improving security in any way, but this is a separate topic)

For the full reasoning see this page https://developer.pidgin.im/wiki/PlainTextPasswords which is now back online. It was accidentally broken in a recent server migration.

That said, purple3/pidgin3 (still in development) only supports for keyrings and doesn't try to do any password management on its own even though password managers fall into the "Store a password(s) behind a password" as detailed on the above page.

> The problem with this argument is that you can justify an infinite amount of crap with it

Does that make it wrong?

Not per se. But it does make it potentially dangerous thinking depending on how it is applied.

Yes

If the model you're using tries to claim something that is false is actually true. Yes, your model is wrong.

> The problem with this argument is that you can justify an infinite amount of crap with it, the security equivalent of cockroach papers; which inevitably people ends up treating as real security.

I almost missed the twist at the end because I had no idea what the hell cockroach papers were. I still don't understand the reference, but at least it sounds mildly interesting. So, well done.

Now, as for this strawman argument of yours about justifying an infinite amount of crap, that's true of all manner of disingenuous arguments. Who cares about that in this case?

> Or forgetting to setup proper permissions for their $HOME, etc.

This is Pidgin's fault how?

Now, if you wanted to argue that Pidgin should have put the passwords into a separate file and chmod400'ed it that would make much more sense.

> In addition, these layers of obscurity are also not overhead free: they may complicate debugging, hey may introduce dangerous dependencies, they may tie you to a vendor, they may reduce computing freedom (e.g. Secure Boot), etc.

Not many good things have zero cost, do they... The point of TFA is that a little bit of well thought out obscurity pays huge dividends when applied in the real world. His example about the WP exploit ought to be all you need to read to get on board with that.

Reply on news.ycombinator.com