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.

I know, I know, cleartext passwords are terrible and you should always store a hash!

However, I'm interested in all of the issues with storing cleartext passwords so I can make a reasonably secure choice. Are there any issues other than the obvious two??

  1. Many people reuse their passwords and you're putting them at risk
  2. An attacker can now login as the user to your site (although couldn't they just change the hash in the database to be a new password at that point / they already have access to all the information anyways?)

Motivation: If the password in question is randomly generated and only used by the server to authenticate on behalf of the user to a service (an attempt at "single sign-on"), the primary reuse risk is negated. If an attacker compromised the database, they'd be able to login directly to the 3rd-party service. But if having your database compromised at all is orders of magnitude worse than having an attacker gain access to the 3rd-party service, is it still an issue?

DETAILS ADDED FROM COMMENT:
I'm trying to authenticate from a server with health information on it to a 3rd-party Jabber server, so the client never has to know login credentials to the Jabber server. Then authenticated tokens can be passed from the server to the client so the client can communicate directly with the Jabber server. Obviously, access to the health data in the database is orders of magnitude more disastrous than gaining access to the Jabber service.

I'm trying to be careful here because I'm very wary of cleartext, but it seems like the best approach in this particular situation.

share|improve this question
    
Some detail on "this particular situation" would be helpful here rather than talking in generalizations. –  Joe Mar 13 '12 at 1:56
    
Haha okay, thanks. I'm trying to authenticate from a server with health information on it to a 3rd-party Jabber server, so the client never has to know login credentials to the Jabber server. Then authenticated tokens can be passed from the server to the client so the client can communicate directly with the Jabber server. –  Charles Offenbacher Mar 13 '12 at 2:00
4  
the health part == total disaster if the db is compromised in the first place. –  Charles Offenbacher Mar 13 '12 at 2:03
add comment

migrated from stackoverflow.com Mar 13 '12 at 12:36

This question came from our site for professional and enthusiast programmers.

5 Answers

I know this does not directly answer your question, but another approach would be to have the application authenticate itself to the service to set up a trusted channel between the two. The app could then just pass identity assertions on behalf of the user, and no per-user passwords would be needed.

The assumption here is that the service is happy to trust the application.

share|improve this answer
    
So have the client authenticate directly with the service? That is what we currently have... you type a username / password on the client and it authenticates with the Jabber server. We were hoping that the client would never need to know their username / password and could just automatically be logged in by our site. We don't control the Jabber server. Am I understanding your approach correctly? –  Charles Offenbacher Mar 13 '12 at 2:10
1  
@CharlesOffenbacher - I posted my answer before I saw your clarification about Jabber. The answer does assume that you have control of the service you're accessing. Another possibility to look at might be OAuth, but I'm not sure off the top of my head if that would work in this scenario. –  Andrew Cooper Mar 13 '12 at 3:19
    
Cool, thanks for the help! On the off chance we decide to implement our own Jabber server, I think I'm still a little confused about your method but it sounds interesting. After the application has authenticated itself, what is to prevent someone from sending a false identity assertion and logging in as someone else on the system? –  Charles Offenbacher Mar 13 '12 at 15:53
    
Depends on how the system is implemented, but if the health application authenticates to the Jabber server and has a secure connection then it's up to the health application to control how that connectino is used. –  Andrew Cooper Mar 13 '12 at 23:10
add comment

I'm addressing this:

If the password in question is randomly generated and only used by the server to authenticate on behalf of the user to a service (an attempt at "single sign-on"), [the risk of disclosing a password that the user might be using for other accounts] is negated

This is only partially true. If you are just storing a RANDOMLY generated password that is used only by your system, then you only reduce the risk. The reason it is not negated is because if you ever disclose this randomly generated password to your user, they MIGHT end up using this for their real accounts (this happens more often than you may think)

As for the following:

An attacker can now login as the user to your site (although couldn't they just change the hash in the database to be a new password at that point?)

Use a salt. You can even store the salt in the DB, and manipulate it programatically within your code when you compute the hash (You can store salt X, but actually use a manipulation of X when you compute the hash). This way, even if someone can modify values stored within your database, they would not be able to log in unless they knew how you used the salt you stored + password to compute your hash. Since this is single sign on, think about how bad it would be if someone could log in with a privileged account to your service? What doors could that open?

share|improve this answer
    
Great, thanks. If we use this method, we'll be sure to keep the randomized passwords away from the user to avoid that issue. –  Charles Offenbacher Mar 13 '12 at 15:54
    
Also, I totally agree about the salt. That way an attacker would need to gain access to the code, salt, and db in order to obtain a plaintext password (which, being random in the first place, is not highly valuable anyways in comparison to the rest of the db). –  Charles Offenbacher Mar 13 '12 at 15:56
add comment

There is also a case where the attacker is only able to read your database. If you have a vulnerability in a select query, i think the only thing the attacker can do is to read data from your database, and then it is obviously a lot better if the passwords are hashed.

share|improve this answer
    
This is a good point, thanks for bringing that up. –  Charles Offenbacher Mar 13 '12 at 15:50
add comment

There are two primary risks with cleartext password storage.

  1. Many people reuse their passwords and you're putting them at risk, if there is a security breach of your site.

  2. System administrators, backup operators, and others may now have access to users' passwords. This is poor practice.

Yes, you are right that if an attacker compromises your system and gains full access to your database, then they could modify the hashed password even if you hash passwords. Hashing doesn't prevent modification. In principle, if an attacker manages to gain read-only access to your database (say, a backup gets stolen from the trunk of your car), then hashing is more secure: if you store cleartext passwords, the thief has all your passwords, whereas with hashing, the thief doesn't immediately obtain all of your passwords.

I also suggest reading the other questions in the passwords tag.

share|improve this answer
add comment

I was going to make this a comment, but when I went to go write it, I figured it was more of an answer. Clearly this Jabber service feature should be 100% seperate from the health imformation. You need to follow ALL laws about storing health information.

Which leads me to the following thought: Doesn't Jabber support OAuth? The user in question has to at some point know their username and password to authenticate with the third-party Jabber server.

So there are two ways to handle accessing "the jabber" account. If you don't want the user to provide the authentication details then you really only have one option, create the account for the user, and handle the authentication yourself.

You can do this by creating the username and password for the user. You could either use authenication system like OAuth where the client and server exchange information. OAuth allows the user to request the token, then the server grants the token and this allows the client to access the contents.. This approval can be taken away seamlessly at anytime.

This requires you to be the "user" and provide the information to the server so the client can approve the client's access to the content. So the other solution would involve the user to provide the information once and using a similar mechanic, getting approval until the approval is revoked.

I honestly don't understand the concern. Access to the Jabber service if seperate from the health information would not lead to a leak of PII and Medical information.

share|improve this answer
add comment

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.