Thelounge: Enforce permissions on user files so that other users on machine can't see user config files (was: Hashing network passwords in user file, so admin can't see the password accidentally when for instance looking at the user files.)

[Raqbit]

What the title says.

Ofcourse not for security, but just so you can't accidentally see the users' passwords.
A simple hash should do.

[xPaw]

The best we could do is encrypt it using users' password (hashed password). It wont be secure, but it will certainly hide it from the naked eye.

[Raqbit]

That's exactly what I was thinking of

[xPaw]

We discussed this in IRC, and basically we can't protect the passwords anyhow. Adding encryption based on users' password won't solve anything. Better leave it plain text for simplicity.

[richrd]

Hi, sorry to jump into this after two years. What about just a simple base64 encoding? Thats really easy and deals with the problem of seeing users passwords by accident.

[astorije]

I think we should do that at the very least, yeah.

[McInkay]

The problem with pretending to have security is that when it's something like base64, it gives people a false sense of security and that can cause them to be less careful.

For example, seeing something that looks like a hashed or encrypted version of their password might make them more likely to store it in a dotfiles git repo, or back it up and not encrypt it.

If we insist on doing something, maybe a better way is to enforce permissions so that only the user the lounge is running as can read it. That gives you the same "users can't accidentally read it" other than the admin, but also doesn't give a false sense of security regarding the file.

[richrd]

@McInkay I don't see this to be about pretending, as the OP already said it's not about security. It's just a means to make the password less readable by accident. IMHO a user (admin) would need to be quite foolish to backup user files publicly in any case even if they never contained any passwords. Same goes for log files and core config.
Since in addition to passwords the user files can also contain:

• Session IDs
• IP addresses
• Notification keys
• Some form of user agent
• Channels

Enforcing permissions would make sense especially to prevent accidental backup. But maybe that and base64 would be the best of both worlds? Would the thelounge edit and other user config commands work just the same if the permissions were changed?

All in all this isn't the most important thing for me as my users only connect to my network (for which I know the password).

[McInkay]

Would the thelounge edit and other user config commands work just the same if the permissions were changed?

As long as you run them as the same user as you run the lounge as, then yes. And the error when run as a different user should be obvious enough.

Enforcing permissions would make sense especially to prevent accidental backup. But maybe that and base64 would be the best of both worlds?

What would be the purpose of using base64 if we restrict permissions?

It's just a means to make the password less readable by accident.

Yeah, I get that, but you have to think how it comes across to people. If the intention isn't to create security, but it can seem like it is more secure (a user looks at the file and sees it isn't there password, but doesn't know what base64 generally looks like, and assumes it's secure) then that can be really bad for what people do with it.

If you haven't read/heard Bruce Schneier talking about security theatre, then you really should. If you have, I don't mean to patronise. And although the idea behind this is not to make them think it's secure, people could easily be drawn into that thought if they aren't as aware about how things work as we are. And someone accidentally thinking something is secure when we don't mean to do that is just as bad as intentionally trying to pretend it's secure.

IMHO a user (admin) would need to be quite foolish to backup user files publicly

I agree, but I think that base64ing them would give them the false sense of security to make them feel like it's something they can do.

But changing permissions doesn't give unnecessary extra false sense of security, but giving us the advantage of other random users on the machine being able to read it unless they have root.

I think the permissions on it's own is the best plan for this, personally. Does that make sense?

[xPaw]

I agree, using a different encoding like base64 just gives a false sense of security.

[McInkay]

Would you be happy with the permissions suggestion, @xPaw ?

[xPaw]

Don't we already try to set folder permission when creating .thelounge?

[McInkay]

We do, but we don't enforce it on startup, so that if someone changes it, it can still start up.

I'm suggesting like how SSH works with ssh keys. If you have the wrong permissions, it doesn't use it.

So on startup we check that the permissions are correct (like how we do with checking the user) and refuse to run if it's wrong.

[xPaw]

Yeah I don't think that's a good idea. If you change the permissions - so be it.

I did just merge a PR that prints a CLI warning if config permissions don't match the user you're running on.

[McInkay]

Yeah I referred to that in my comment.

What would be the reasoning for allowing people to make the config globally readable? I don't think it's unreasonable to enforce permissions on it (not just a warning) when it has plain text passwords. We need to be more careful with these things, and what's wrong with enforcing that on users? There's no legitimate reason for it.

[xPaw]

I just don't see how it's our job to enforce the permissions every time lounge starts (what if you change them after you start it?)

[richrd]

IMHO we could go with just the permissions, would be fine for me. I must admit though, that I run thelounge on my own user, not on a dedicated user account which would be even safer (yeah, meh.. here I am talking about security :facepalm: ) I like the warning a lot, but at this point in the discussion I'm not 100% sure about enforcement. I wouldn't mind it though. And sorry again for pulling this issue out of its grave :coffin:

[McInkay]

It's not about being "our job", it's about us trying to help our users.

It's clear that having plain text passwords is not great. However, we know that there's no realistic way we can not have them if we want the lounge to be able to reconnect on it's own (although we could if we wanted allow users to set it to be encrypted with their user password and they have to log on to decrypt it every time the lounge starts up).

With both of those things being true, I think that it would be nice of us to try and help our users when we store plain text passwords.

I could be convinced that it shouldn't be "enforced" and can just be a warning, but ... as we've seen no one reads warnings and so it may as well not exist, so you'll have to convince me otherwise of that :-P

[richrd]

I can't think of any reason to convince you otherwise. It does make sense that the configs should be owned by the same user that thelounge is run by. I don't see why not.

[astorije]

For context, original issue title was: "Hashing network passwords in user file, so admin can't see the password accidentally when for instance looking at the user files."
With the new title, the thread makes little sense, we should not have renamed it.

I still would like the password to be ~hashed~ hidden. As @richrd mentioned, it's not about complete security, it's about accidental showing. Passwords are generally more recognizable than hashes (i.e. I'll remember "correct horse battery staple" as soon as I see it but I can never remember "9cc2ae8a1ba7a93da39b46fc1019c481" if I see it by accident in a CLI output or a log). Beyond that, I understand the false sense of security, but I think there are ways to mitigate that with warnings/documentation/etc.

@tguild, you mentioned your team will not be able to adopt The Lounge as long as we store passwords in clear and that you had some suggestions. Would you mind listing them here so we can consider pros and cons of those?

[xPaw]

"I still would like the password to be hashed."

You can't hash IRC passwords, period. Hashing is a one way function, but we need to get the plain text back to send it to the IRC server.

[astorije]

Come on, you very well know what I meant. I meant obfuscate/encrypt/whatever. Hide it from the naked eye and un-hide it when needed.

[McInkay]

With the new title, the thread makes little sense, we should not have renamed it.

With the way the converstaion was going, the title made no sense for where we had gone.

Passwords are generally more recognizable than hashes

Well, they shouldn't be. That's a bad password if it's recognisable and memorable.

But let's not get into how bad that xkcd password comic was.

@tguild, you mentioned your team will not be able to adopt The Lounge as long as we store passwords in clear and that you had some suggestions. Would you mind listing them here so we can consider pros and cons of those?

This solution would not solve it that issue. They will still be stored unsafely.

Come on, you very well know what I meant. I meant obfuscate/encrypt/whatever. Hide it from the naked eye and un-hide it when needed.

As I mentioned in the IRC, people have no reason to be editing the files directly anymore, we have a way for the user to edit everything in that file, and admins can use thelounge user to change them as well, so no one has any need to be going into the file, so the "someone might accidentally see it" isn't really a thing. The real issue is users on the machine being able to see it, and doing permissions check would solve that.

I really strongly think that making a password "look" like it's encrypted is more harmful than doing nothing.

[xPaw]

I know what you mean, but it's important to get the terminology right, otherwise people will think we can hash IRC passwords.

I don't know how the situation would improve if you encrypted the password but stored the encryption key next to the password.

[xPaw]

What we could do is rely on native OS storage, but that will come with all sorts of portability problems.

https://github.com/atom/node-keytar

[astorije]

With the way the converstaion was going, the title made no sense for where we had gone.

Agreed but the OP description says "What the title says." so I got confused by 😅

Well, they shouldn't be. That's a bad password if it's recognisable and memorable.

I don't think it's our place to tell people what their password should be. Whether this is true or not, we should be able to do something about this.

This solution would not solve it that issue. They will still be stored unsafely.

I'm not sure what you mean, this discussion has not even started yet. Give @tguild the opportunity to express himself.

so no one has any need to be going into the file, so the "someone might accidentally see it" isn't really a thing.

This is another assumption I'm not sure we are able to make. To each their own use case, but the fact of the matter is our users trust us to store their credentials, and if there is an easy way to make this a little less readable, I don't see why we should not do that.
(btw I don't believe this is what @tguild had in mind, his solutions were a bit more drastic and constraining, so I'm not sure if we would be able to do that)

I really strongly think that making a password "look" like it's encrypted is more harmful than doing nothing.

And I think the exact opposite. If that were true, <input type="password"> would not be a thing IMO. 🤷‍♂️

I know what you mean, but it's important to get the terminology right, otherwise people will think we can hash IRC passwords.

That's fair, apologies for mis-using the word "hashing". I'll correct my previous comment.

I don't know how the situation would improve if you encrypted the password but stored the encryption key next to the password.

Because I'm not trying to make it secure, simply not accidentally seen. I totally understand that this is not making your data _secure_, just a little more _private_.

I know some people would be happy if the key was user-provided (or admin-provided) and therefore reconnection would fail on IRC networks that requires auth, but it does come with a serious compromise: insecure and automated vs. secure and does not reconnect.
I understand some people prefer the benefits of security over the convenience of auto-reconnection, but we don't provide that at the moment. I don't know if we'd want to support that in the codebase, but that's the other end of the possibility spectrum, I think.

[xPaw]

I know some people would be happy if the key was user-provided (or admin-provided) and therefore reconnection would fail on IRC networks that requires auth

These people can just not store the password and manually send the /pass command upon reconnection already.

[astorije]

These people can just not store the password and manually send the /pass command upon reconnection already.

Interesting, I didn't think of that. A bit more manual that I would hope, but I guess that would do.
We don't have a way to refuse storing passwords at all at the moment, do we? As in, if a server admin simply does not want their users to store passwords in their user config (e.g. per company policy), disable the server password field or something.

[McInkay]

Agreed but the OP description says "What the title says." so I got confused by 😅

Fair point.

And I think the exact opposite. If that were true, would not be a thing IMO.

That's a very different thing. It's not the same as base64ing something in a file. It's a user interface that people are designed to use, whereas the file is what we use for saving information for the lounge to use.

Base64ing the password in our files, if someone does edit the file, makes it look like the password is encrypted, and that creates a false sense of security and I think that is dangerous.

This is another assumption I'm not sure we are able to make. To each their own use case, but the fact of the matter is our users trust us to store their credentials, and if there is an easy way to make this a little less readable, I don't see why we should not do that.

I'm not suggesting that we say that you can't edit the files, but I think it's perfectly fine not to implement something like this and saying that the supported way to edit these files is through the command line commands, and through the user interface on the lounge. If you decide to edit the files yourself, then that's not our problem if you accidentally see someone's password because you are doing something unsupported.

However, enforcing permissions

I'm not sure what you mean, this discussion has not even started yet. Give @tguild the opportunity to express himself.

I didn't mean to speak for @tguild but the fact of the matter is that even if we base64 it, although technically it won't be in plain text, they are still essentially stored in plain text, and if someone doesn't want to use it because of that, I think we should make it very clear that they will still essentially stored in plain text. I don't want anyone to get the indication that this makes it at all safer.

Enforcing permissions does make it slightly safer. Not a huge amount, they are still stored in plain text, but it stops other users on the machine from snooping, which is a good thing.

These people can just not store the password and manually send the /pass command upon reconnection already.

That's a really good point, maybe we should make this clear to people. Make a "we have to store your password in plain text if you do this, if you don't want to do this, don't save the password"

[richrd]

If you decide to edit the files yourself, then that's not our problem if you accidentally see someone's password because you are doing something unsupported.

Whether it's supported or not there will probably always be some people checking out what the files look like (not necessarily even edit them). It could be argued, that since it's not supported, it's not our business if a user thinks that the encoded password is encrypted / hashed or whatever.

But I think there's a broader aspect to this:
We should document (ideally in the config file itself as well as the official documentation) that the files contain sensitive and unsecure information and should never be shared publicly etc. The config file could for instance have a comment block at the top describing this (JSON5 could be used for comment support). That way the entire issue is clarified, and we could even go ahead with encoding the IRC server password...

Just my 2 cents.

[tguild]

Hi Jeremy et al,

As a policy we don't store usable passwords anywhere. What we have for people is encrypted and can only be used to verify a supplied password.

I understand and appreciate the functionality of having it accessible to the lounge, so if there is a network or other interruption it can re-authenticate the user and not miss any communication. The risk is if an attacker has access to lounge server, they can now easily collect stored passwords. The file in home directory of user lounge was running on had the unix permissions world read, any user on the system can access the credentials.

Not a ready solution as noted to be able to keep these available by the system yet secure. Oauth seems like the best fit but cannot handle the reauth on disconnect and could be a fair amount of work to implement.

In our case we would be running lounge instance on same subnet as our irc server, network interruptions should be infrequent. We can like with a configuration option to not store then which comes at the cost of missed conversations should there be a server disconnect.

If it stays as is we will consider a separate login per user that can only be used by the lounge to connect to irc.

[astorije]

If you decide to edit the files yourself, then that's not our problem

As soon as we store users' private information, it becomes our problem. Whatever solution we go for, users trust us with their data and we should deal with it accordingly, we can't just say it's not our problem.

I think it's perfectly fine not to implement something like this and saying that the supported way to edit these files is through the command line commands, and through the user interface on the lounge.

When we store things in files, it should be expected that these files can be edited. Saying it comes at a cost such as config doesn't get reloaded before next restart is fine, but we cannot just pretend the files won't get edited if they are just text. In fact, I'm generating those with Ansible, and maintaining/generating configuration files via tools is a very common use case.

I think we should make it very clear that they will still essentially stored in plain text. I don't want anyone to get the indication that this makes it at all safer.

Yep, totally agree with that, in fact I did mention exactly this above. Whether we encrypt or not, we should make it clear (self-reminder to add to the docs) that we have complete access and storage of that information.

These people can just not store the password and manually send the /pass command upon reconnection already.

I was thinking back about this, and I'm wondering, how would that work?
I get the reconnection part, but what about initial connection? If I cannot connect to a server because it needs a password, the only way to connect is to fill the password in, which would store it in the file automatically, is that incorrect?

If this is correct, then there are a couple solutions I can think of:

• We could add a checkbox in the connect form to save the password or not, with a help text mentioning the security vs. convenience trade-off "By checking this, your password will be saved on the server to allow for auto-reconnection. If left unchecked, we will not store your data but you will need to send /pass xyz if the connection is lost"
• In server settings, we could add a boolean to server-wide disable password storing. Users would still be able to fill in the password in the form, but we would not store it and they would need to use /pass xyz upon reconnection.

If I was incorrect, then feel free to correct me. I am sure there are other ways to address this, but I want to make sure I have it right in the first place.

[McInkay]

As soon as we store users' private information, it becomes our problem. Whatever solution we go for, users trust us with their data and we should deal with it accordingly, we can't just say it's not our problem.

My wording was not great, I didn't mean storing their password was not our problem, I'm saying that I think them "accidentally" viewing the password because they have edited the files rather than using the proper way to edit the files is not more important to deal with than the false security that base64ing them gives.

Whether we encrypt or not

Can we not use the word encrypt, because I think that just increases the false sense of security. Feel free to use the word "obscure" or something.

We could add a checkbox in the connect form to save the password or not

I'd be good with that

In server settings, we could add a boolean to server-wide disable password storing.

I'd also be good with that.

I'd also want to do the permissions thing.

But I'm still not happy with base64ing the passwords. I don't think I'd actively try and stand in the way if you and @xPaw were happy with doing it, but I definitely wouldn't be approving that myself. I really disagree with it for all the reasons I've said before. I don't think anything you've said changes my opinion on that.

[astorije]

I'd also want to do the permissions thing.

I think I'm with @xPaw on that one, especially for the argument that permissions can change after TL has started, and ideally TL runs 24/7 so that would not do much, unless it restarts and that becomes black magic.
I personally do not enjoy when software messes up with permissions I've set myself (or via configuration automation), but if it does it at seemingly random time (if your service manager restarts the process in the middle of the night for example), then that's just hard to figure things out IMO.

@xPaw, what do you think about the 2 potential solutions I mentioned in my previous comment? Any one you prefer (or would you go with both, which is also a possibility)?
I like that the user stays in control, but I also appreciate company/team-wide policies that would disable it for everyone.

Also @xPaw, if you can help me understand this, that'd be great 🙏:

These people can just not store the password and manually send the /pass command upon reconnection already.

I was thinking back about this, and I'm wondering, how would that work?
I get the reconnection part, but what about initial connection? If I cannot connect to a server because it needs a password, the only way to connect is to fill the password in, which would store it in the file automatically, is that incorrect?

[McInkay]

Fine, whatever.