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:
- How will the password be communicated to new participants?
- 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:
- They gain access to the service.
- 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.