Should the password of a password protected channel be hashed?

Question

Let's take a chat system, where any user can create a channel with a password protection. Thus, other users may only join using the channel password.

This password is therefore known to every person inside the channel.

Should this password be hashed in the database? This would mean that the application is not able to show the password (e.g., if one user forgot it).

Personally, I don't see a reason why the password should be hashed, because when setting the password, it's absolutely clear that other people will need to know it.

Answer 1

Personally, I don't see a reason why the password should be hashed, because when setting the password, it's absolutely clear that other people will need to know it.

Then why bother storing the password at all, just let anyone in! ;)

If you are storing a secret, it's because this secret identifies a subset of your total users. Not all your potential users know it. Now, you've probably been told that passwords must be stored hashed and salted. This is a password you're dealing with. I'll let you draw the logical conclusion.

Maybe the same group uses it to access a SharePoint which occasionally contains sensitive information. Maybe they use it for their group calendar which reveals when their office is empty or when they travel away from home. Maybe the person who created an account was so out of clue she used a password otherwise valuable to her personal assets. Maybe they just can't deal with the amount of credentials they have to handle and that alone explains the reuse.

Don't be the person who's responsible for causing harm to others out of sheer negligence. Hash them (with a slow password hashing algorithm). Salt them (with a unique salt per password).

Answer 2

It depends on your situation it's good practise to hash your passwords encase your database get compromised or your client's network thus allowing the attacker to gain access to any password he/she managed to gain.

Advantages of hashing your password:

• Attacker will have much more to perform to gain access to private chat groups as he/she will require to crack the password. (Brute force, rainbow tables) or set hash which he/she knows.
• If it's also hashed via client then an attacker using MITM technique will only get your hash of your password. So, if you use same password on other sites you should be safer than the attacker catching your plain text password.

Disadvantages of hashing your password:

• You won't able to show original password without having the password already.

So, let's imagine you found my hashed password via MITM attack: $2a$10$VcSYK/yD0T.vXencRFWv6O.8PZtsTMG7ZxZXNRSMXKu9.JTD5RNCS Try find the password? Who knows that may be the password to my StackOverflow account. ;)

My point is it's much more secure to use hashing since the attacker has much more to do. You'll have to brute force or use rainbow table to get original value before it was hashed.

Answer 3

A shared password is a poor design for managing access to a private communication channel. For example, you can't kick a user out without closing the channel: you can't cause them to forget the password. You can't prevent a user from sharing the password with other users (voluntarily or involuntarily) — if a user's password is exposed, you can invalidate it, but if the shared password is exposed, it inconveniences everyone who was using that password.

A better design would separate authentication from authorization. First authenticate the user, for example by prompting them for a password (“You claim that you're Bob? Prove it!”). Once a user has been authenticated, determine which channels that user has access to by looking that up in a database (“Let's see if Bob should have access to the crazy straw left-handed loop channel.”).

This separation of concerns has a lot of advantages, but it does have a consequence that you may or may not care: the easy way to do it relies on a central authority to determine who has access to the channel. The shared password approach eliminates this central authority, but at the cost of having a pretty inflexible access control policy (any user can allow any other user to join, and only full consensus can keep a user out).

If the channel really has to be password-protected, because that odd access control policy is what you really want, then you need to answer two questions:

1. How will the password be communicated to new participants?
2. Do you expect users to retype the password each time they join?

If the answer to (1) is that someone has to know the password in order to give it out, then that someone has to store the password in a recoverable form, so hashing is out for the password-giver. If the answer to (2) is that the users store the password in some password manager, then hashing the passwords on the authentication server only provides a minor amount of protection, but it's still a good idea.

Next question: how big a problem is it if the password is recoverable on the server? Password hashing addresses only one specific threat: if the adversary gains read-only access to the database. If this allows the adversary to recover passwords, then:

1. They gain access to the service.
2. They gain access to other services where the same user has used the same password.

For a shared password, (2) doesn't apply, only (1). So it's less of a big deal than with passwords for user accounts. There is an advantage to storing the password in a hashed form, but not a decisive one.

To cut a long story short, a shared password is not a good model. If you're stuck with it, there's a good chance that you have to store the password in a recoverable form anyway, and it's not your biggest problem. Hash the password if you can, but if you can't, then don't lose sleep about it.

Note that if users can create their own protected channel, then they should not be allowed to select the password. In my experience, these shared passwords are invariably hard-to-type, but easy-to-brute-force passwords, like CraZyStraWs!!!1. Automatically generate a sensible random password (like 10 lowercase letters selected uniformly randomly) and force users to use that.

But, really, don't use a shared password. Use a user/channel access database.

Answer 4

Your logic isn't sound.

"The password doesn't need to be hashed because many people will need the password."

The second part of your statement is true and you've decided that that dictates that the first statement should be true. They're actually unrelated. Should the people that need the password get it from your server? Feels like they should get it from other users.

Here's how I would approach it:

"The password should be hashed because there will never be a requirement for the server to vend the password to users."

or

"The password shouldn't be hashed because there will be a requirement for the server to vend the password to users and there are controls that prevent unauthorized access to the passwords in the database."