Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
9  
other people ≠ all people –  Ebenezar Jul 21 at 9:56
    
I just wonder how this channel password is going to be distributed among participants at the first place? Will you transfer it in the channel? if so, then it is not a secret? and if your channel already protected so you can transfer the secret on it, then why bother and make a secret? –  user2192774 Jul 21 at 13:00
    
In this case I wouldn't even transmit the password in any form. Derive the channel encryption from the password. –  Aron Jul 22 at 3:24
    
As a general rule, there's never any reason not to hash passwords in this sort of situation. The only possible reason you wouldn't is sheer laziness. –  Istvan Chung Jul 22 at 3:27
    
@Aron Deriving the channel encryption from the password is very bad. It means that anyone who obtains the password can decrypt all past archvies. It also means that the password can't be changed without major hassle. –  Gilles Jul 22 at 16:14

4 Answers 4

up vote 26 down vote accepted

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).

share|improve this answer
    
In this situation I would call it negligence to allow users to set the shared password. I would even call it negligence to have a shared password in the first place unless there was a very good architectural reason. –  Gilles Jul 22 at 16:11
    
Well, there's negligence and then there's convenience, or rather even just reality. In an ideal world the authentication factor is unique per individual, practically impossible to forge and never reused somewhere else, some nice cheap mechanism allows granting and revocating access to users, and everybody is happy. In practice people can't be bothered setting up certificates or PKIs just to connect to a damn chat root. They don't want something complicated because if they need to go to others' office / email to get the password then it kinda defeats the purpose of a password. –  Steve DL Jul 22 at 17:16
    
In other words: if you as a group need private security-sensitive conversations and you happen to have resources to throw by the window to set that up, you don't use chat room services on the Internet, you build a VPN and rely on your own servers. –  Steve DL Jul 22 at 17:17

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.

share|improve this answer

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.

share|improve this answer
    
You're right, a shared password is not the best solution. But it is a solution, which is very common (think about game server passwords, etc.). And to be honest, our current approach is a little bit different than I explained: We do have user registration. And if a user wants to join a channel, he only uses the password to request a membership. The server will then set a membership for this user and the user will never send the channel password again. So basically it's more like a (changeable) non-expiring invite code. –  bb-generation Jul 22 at 16:35
    
@bb-generation Good, then make it a per-instance invite code: allow every user to generate one (logging this action on the server), usable only once. If possible, tie the invite code to a particular recipient (existing account or email address). –  Gilles Jul 22 at 16:47
    
@Gilles, I think what was not told by the OP is that, probably, the threat model is very basic: prevent spammers and idiots from invading your social space. Of course if there's an actual security need then your answer's the way to go! –  Steve DL Jul 22 at 17:23
1  
In fact we're in a situation where giving better advice requires knowing the exact use context :) –  Steve DL Jul 22 at 21:12
1  
@SteveDL you pretty much described the use context. Just two small differences: Every channel has to have a password (set by the creator at the creation of a channel). And it's not really a chat (but I took the example of a chat system as an analogy, because it makes it much easier to explain) –  bb-generation Jul 23 at 23:25

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."

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.