Is my password hashing mechanism good enough?

[TechBoyJK]

Hi Guys,

I'm building a website and have many mechanisms in place for security. Such as firewalls, network security analyzers, etc.

Programmatically, I have other measures in place too.

In regards to passwords, I think I have done enough but just wanted to get a feel for what you all think.

1. User registers, creates account and password
2. UUID is created for each registration, UUID used as user specific salt
3. password, UUID, and application wide salt and combined as one string
ex password123!+625A869A-5482-47BE-B2139BF324B8C265+SITESALT
4. new string is hashed using SHA-512, which creates a 128 digit string
5. hash and user salt are kept in db
6. When user logs in, account is queried to get password hash and the user specific salt
7. submitted password, user salt (from query) and sitewide salt and hashed using sha-12
8. If queried password hash is equal to hash produced by step 7, password is authenticated

I think this is pretty solid because

1. We don't actually keep any passwords
2. There is essentially no way to extract the password from data we keep on file
3. Would have to create enormous amount of rainbow tables to crack 512bit SHA based encryption AND know the sitewide salt (which isn't even in the database).
4. Would simply take to long to extract possible passwords from even one account.

What says you?

 

[Shilohen]

It looks good enough. I don't know if I like the sitewide salt however, as it prevent your schema from being reused by a different application. A seeded hash is more than enough for password storage imho and, most of the time, it simply uses a secure random instead of a full GUID and store it directly in the same column using {SSHA}hash.seed. That being said, two columns and a GUID is also fine, just make sure you don't go pass the point of diminishing return where security becomes an hindrance more than a protection and I think the site wide salt does just that.

 

[Crusty]

It looks good enough. I don't know if I like the sitewide salt however, as it prevent your schema from being reused by a different application. A seeded hash is more than enough for password storage imho and, most of the time, it simply uses a secure random instead of a full GUID and store it directly in the same column using {SSHA}hash.seed. That being said, two columns and a GUID is also fine, just make sure you don't go pass the point of diminishing return where security becomes an hindrance more than a protection and I think the site wide salt does just that.

Well if your database is separate from your app servers then if one or the other were to be compromised but not both then you can still assume a reasonable amount of safety of the hashed passwords.

http://stackoverflow.com/questions/287517/encrypting-hashing-plain-text-passwords-in-database

Some of the answers have some good points such as iterating your hash function so that you slow down offline dictionary attacks as well using HMAC to apply the site wide salt instead of just appending the string and running SHA over it. That's only useful however if you can keep your site-wide hash a secret though.

 

[Shilohen]

Well if your database is separate from your app servers then if one or the other were to be compromised but not both then you can still assume a reasonable amount of safety of the hashed passwords.

http://stackoverflow.com/questions/287517/encrypting-hashing-plain-text-passwords-in-database

Some of the answers have some good points such as iterating your hash function so that you slow down offline dictionary attacks as well using HMAC to apply the site wide salt instead of just appending the string and running SHA over it. That's only useful however if you can keep your site-wide hash a secret though.

Even if the database was compromised, a seeded hash remains quite hard to break and you would probably have bigger issues than stolen hashed passwords, i.e. most of your confidential or sensible data.

As for iterating the hash function.. meh, I don't know. That's not even used in enterprise grade systems like OID or AD (not sure about AD, but pretty much about OID). I think it's simpler to simply lock the account after a certain amount of failures.

 

[Cogman]

How are you handling logins? Is it an HTTP post? That would be the main place I would worry about security (your backend looks fine). If you are sending passwords plain-text it is vulnerable to packet sniffers all along the route from client to server.

 

[TechBoyJK]

right now, (site is not live), it is just http posting. I plan on using https:// once it goes live (so that pw's are not sent in plain text)

 

[Modelworks]

The one weakness almost all login/password security type systems have is the keyboard. As long as people are typing their info anyone with 10 seconds alone can compromise your systems. It takes that long to unplug the keyboard, attach the capture device and plug the keyboard back into the capture device. The devices are as small as a flash drive and can record up to 16 million key strokes. Leave it for a week and retrieve. They now have everything regardless of any ssl, https or hashes you used.

Mainly important for business systems but something to remember when working with security. It wasn't a big problem before but now the devices are down to $15 and easy to get for those that want to use them.

When using login info for a site don't forget to put limitations on how many times a user can try the wrong password before the account has to be reset. That reduces the odds that someone will brute force the site by a lot.

 

[Markbnj]

The one weakness almost all login/password security type systems have is the keyboard. As long as people are typing their info anyone with 10 seconds alone can compromise your systems. It takes that long to unplug the keyboard, attach the capture device and plug the keyboard back into the capture device. The devices are as small as a flash drive and can record up to 16 million key strokes. Leave it for a week and retrieve. They now have everything regardless of any ssl, https or hashes you used.

If you don't have physical site security, then obviously you don't have security at all.

 

[TechBoyJK]

If you don't have physical site security, then obviously you don't have security at all.

All of my systems are hosted in a secure datacenter.

I think the keylogging problem more-so lies with the end users.

However, this really isn't my problem, because as with an secure token (password, debit card, etc), this is the responsibility of the token holder to protect, not the issuer.

So I'm not really concerned with that. If an end user is stupid and gives up their password, it's not my fault.

 

[degibson]

Your security sounds just great to me.

All of my systems are hosted in a secure datacenter.

I think the keylogging problem more-so lies with the end users.

However, this really isn't my problem, because as with an secure token (password, debit card, etc), this is the responsibility of the token holder to protect, not the issuer.

So I'm not really concerned with that. If an end user is stupid and gives up their password, it's not my fault.

Its not your fault personally, but your organization might be liable anyway. Justice isn't just blind, you know, it is also powerfully ignorant, highly empathetic, and mostly irrational. Of course, there isn't a damn thing you can do about stupid users.

 

[TechBoyJK]

Your security sounds just great to me.

Its not your fault personally, but your organization might be liable anyway. Justice isn't just blind, you know, it is also powerfully ignorant, highly empathetic, and mostly irrational. Of course, there isn't a damn thing you can do about stupid users.

is the "just great to me" sarcasm or serious?

I know it wouldn't be our fault per se, but there could be consequences if a user gives up their password to the wrong person. Identity theft, abuse without fear of consequence since the abuser isn't tied to the account, etc.

But with that, for a free site, and for what I'm trying to do, it isn't businessly viable to hold everybody's hands all the time to keep it from happening. Short of a casual reminder here and there, I don't know what I could do to get users to protect their passwords. Is businessly a word? 😉

 

[Markbnj]

All of my systems are hosted in a secure datacenter.

I think the keylogging problem more-so lies with the end users.

However, this really isn't my problem, because as with an secure token (password, debit card, etc), this is the responsibility of the token holder to protect, not the issuer.

So I'm not really concerned with that. If an end user is stupid and gives up their password, it's not my fault.

Yes, physical site security is necessary on both ends of the connection.

 

[degibson]

is the "just great to me" sarcasm or serious?

NOT sarcastic. Your password security seems about as good as anyone could reasonably expect.

I know it wouldn't be our fault per se, but there could be consequences if a user gives up their password to the wrong person. Identity theft, abuse without fear of consequence since the abuser isn't tied to the account, etc.

Precisely my point. I understand you're doing what you can to secure the site on your end -- but the rest of my point was that you can't assume you'll NEVER have a security problem, so long as you are in some manner responsible for your clients.