20

If I create a login for an app that has middle to low security risk (in other words, its not a banking app or anything), is it acceptable for me to verify a password entered by the user by just saying something like:

if(enteredPassword == verifiedPassword)
     SendToRestrictedArea();
else
     DisplayPasswordUnknownMessage();

It seems to easy to be effective, but I certainly would not mind if that was all that was required. Is a simple check on username/password combo enough?

Update: The particular project happens to be a web service, the verification is entirely server side, and it is not open-source. Does the domain change how you would deal with this?

9 Answers9

52

That would suggest, that you're keeping passwords in open text, which is a no-no, even in low security scenarios.

You should rather have:

if(hash(enteredPassword) == storedHash)

You can use simple hash as for example MD5

vartec
  • 20,846
26

Not without SSL

This is not secure if the password is sent over the network in plain text. Hashing the password on the server side is also not secure if the password is sent over the network in plain text.

Since the HTML <input type="password"/> tag sends its contents in plain text, this will be a problem no matter how you store the password on the server, unless your website uses SSL to transmit the password.

(HTTP authentication, which pops up a dialog box in the browser asking for a password, may or may not be clear text, depending on what authentication mechanisms the server and browser have in common. So that could be a way to avoid this without using SSL.)

Not if the site administrators are suspect

Now, supposing you're using HTTPS to do the web site, this could be secure if you trust your site administrators (who can read plain text passwords), and other people who have access to the machine to behave properly. Now, it may be obvious that they can do anything they want with your website (since they administer it), but if they can read the password, the may also be able to use the stolen login/password pairs on other people's sites.

A way that keeps passwords safe from the administrator

One secure way to store and check passwords is as follows:

def change_password user, new_password
  salt = random(65536).to_s(16) #will be 4 characters long
  password_hash = salt + hash(salt + new_password)
  store(user,password_hash)
end

def does_password_match? user, entered_password
  correct_password_hash = retrieve(user)
  salt = correct_password_hash[0...4]
  entered_password_hash = salt + hash(salt + entered_password)
  return correct_password_hash == entered_password_hash
end

For the hash function, try to use something strong, and something that doesn't have good rainbow tables in the wild yet. You can change the length of the salt if necessary work around rainbow tables.

Depending on the environment you're in, the variability in your network latency, and whether user names are meant to be publically known, you may want to have another code path compute hash('0000'+entered_password) if the user doesn't exist, in order to prevent attackers from determining which usernames are valid based on the time it takes determine that the password is incorrect.

Community
  • 1
Ken Bloom
  • 2,404
14

I concur with those who suggest hashing, but there is also a wheel you are reinventing here. Depending on the platform you can probably find a role/user management tool that covers all of the user management stuff safely and securely without needing too much intervention on your part.

glenatron
  • 8,689
8

Security is a very touchy subject, particularly because there needs to be a balance between inconveniencing your users and making sure their information is safe. Typically, the formula for how much security you need is a function of the importance of the data. In short:

isSecuritySufficient = effortToBreak > rewardForBreaking

A common misunderstanding about people who do bad things is what they are after. Most of them are out to destroy trust. You should always do everything you can to protect your users' trust. Part of that is doing your due diligence to make sure their identity is safe. They may care less about the data they store, but they do care about their identity--even at the lowest threshold of security.

There's a number of low cost (to implement and impact to the user) options available. One of those is hashing the password at a bare minimum. Any service that stores something as sensitive as a password in plain text deserves the embarrassment of being hacked.

General Principles for Password Protection

  • Never store passwords in plain text
  • Hash using a secure hash function like SHA-1 or even SHA-512 (even MD5 is too easy to find a matching hash)
  • Use an application salt value. The salt is random bytes either added to a password to make it more difficult to guess. The salt should be generated at run time and using information about the machine as a seed value rather than stored and referenced in any way.
  • Use a user specific salt value. Use this in conjunction with your application salt.
  • Encrypt all authentication requests that go over a network. That means use SSL for web applications.

Since you would be using SSL for the authentication, at a minimum you want to encrypt all the pages that deal with the user's account as well. This allows as much of a user's identity to be protected as possible.

A note about password management: Users will forget their password from time to time. The absolute worst thing you can do is to send them their password in an email. If you implement the principles outlined above, you won't be able to do that anyway. It is much better to provide a way to reset their password using a link sent to their registered email address. That reset link will have a one-time use code to ensure the person accessing the page is them.

Berin Loritsch
  • 46,426
3

That's fine unless the password is used for anything else. There's still a risk that the user decides that he can re-use the password, so it would be even better with:

if(hash(enteredPassword) == hashOfValidPassword)

If it's for yourself or someone who is aware that the password is stored in plain-text, then it's fine.

3

Is the source code available? Even if not, I'm quite sure the password could be found in the machine instructions in case the binary is available. I would recommend doing a checksum and comparing that instead.

Never overlook security even if it isn't very important in your opinion.

Anto
  • 11,197
1

Absolutely not. Have a read of this, it describes how hackers hacked a security web site. You plan would have you as the weakest link in the chain.

dave
  • 2,466
0

It has been noted in a couple of answers that you should not store the password itself, but a hash - and you should use SSL.

You may say, what is the big deal? If my application gets hacked, that is of little concern. Well it is a quite common pattern for users to reuse the same password on all sites. Was a hacker to hack your site and gain access to user's passwords, the hacker would be able to impersonate a lot of those users on other sites of greater importance to those users. So hacking your site could be the first step for a hacker to gain access to banking information for the users.

And just hashing the password is not enough. You need to hash it with a salt. Hackers have reverse hash lookup tables, so for a given hash, they can find a matching password.

If you choose not to implement these feature, you should inform the users of of this lack of security, encouraging them not to use the same password that they use elsewhere.

Pete
  • 9,016
-2

As long as this is server side.. Then yes.

If you want a bit more security go for https and encrypt\hash the password in the DB.

Morons
  • 14,706