4

I'm now using password stretching for all user account passwords throughout all my websites. In the db I store an iteration count and randomly assigned salt along with the final hash. I'm using SHA512 as the hash algorithm. I'm using C# in .Net 3.5 and 4.0 (dual framework library) for this.

For accounts that only ever get randomly assigned passwords (things like web service API users etc) I keep the iteration count down to a range such that a password check takes no more than 1 second or so. Over the years, according to whether or not these websites stick(!), I will look at increasing these ranges in alignment with CPU power.

For accounts where the user might be choosing the password themselves, I have cranked up the iteration count so a login can take around 5 seconds while the iterations are carried out.

So I'm happy with the security of my passwords; but now I have another problem - I can flood an 8 core cpu with 100% usage for 5 seconds if I get 8 different people to login at once!

My current solution to this is to have an iteration threshold: If a stretch operation exceeds this, I push it on to a queue that is handled by a single thread. I could extend this further so that it uses at most half the processors in the machine.

Is there anything better I can do? Have you implemented this pattern for password storage and logon - what did you do?

Andras Zoltan
  • 41,961
  • 13
  • 104
  • 160
  • 8
    I think you have overdone it... :) – Jon Jun 09 '11 at 08:34
  • @Jon - possibly - looking at my copy of Practical Cryptography a 200-1000ms range is suggested. But even then if you have a website that, say, is as popular as Twitter for example, then you have potentially a lot of people logging in at one time? – Andras Zoltan Jun 09 '11 at 08:39
  • 1
    I was curious, so I read the the wikipedia article about key stretching. I get the impression that the stretching algorithm runs client side, and the stretched key is then submitted for authorization. Why does it slow down your server when the iterations are done on the users machine? Please, correct me if am misunderstanding password stretching. – TheFogger Jun 09 '11 at 08:43
  • Sounds like Jon is right, so while you wait for hardware to catch up maybe you need to implement some sort of log in queue. One thought though, have you opened yourself up for a Denial Of Service attack? – Jodrell Jun 09 '11 at 08:44
  • You should work at Sony. – Guillaume Jun 09 '11 at 08:45
  • @TheFogger - Well, client side is certainly a key situation; but in a web environment that could mean any type of device today. Trying to choose an iteration level that is suitable for all web-enabled devices is impossible - what's reasonable in one could be ridiculously slow in another. You can't get around having to do it server side sometimes. – Andras Zoltan Jun 09 '11 at 08:47
  • 1
    @Guillaume - ouch that's unfair! At least I'm thinking about security! @Jodrell - I can simply reduce the iterations system-wide here to reduce the time and CPU load. If that's the best way to go then I will just do that :) – Andras Zoltan Jun 09 '11 at 08:49
  • @Andras - Guillaume's comment can be interpreted as a criticism in the context of the comments preceding it, but I actually think it was intended as an indication that if Sony were doing what you're doing, they'd be a little better off than they are. – Eight-Bit Guru Jun 09 '11 at 09:07
  • Just kidding, take it easy ;) – Guillaume Jun 09 '11 at 09:10
  • @Guillaume, @Jonners - SO comments are like SMS; so easy to misunderstand - cheers :) – Andras Zoltan Jun 09 '11 at 09:14

4 Answers4

3

Isn't the big benefit of password stretching, that the calculations are done on the client side and therefore they should not affect your server while still providing a good protection?
Frankly, if you implemented it on your server, you are doing it wrong and missed the point :-)

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443
  • 2
    you are absolutely right; think I'm going to follow @dtb's suggestion and implement SCRAM. Oh, and decrease my iteration counts :) – Andras Zoltan Jun 09 '11 at 09:48
3

The idea of password stretching is to have the attacker do the heavy work:

When a client wants to log in, the server presents a challenge. The client performs the resource-intensive calculations and sends a response to the server. The server should be able to determine whether the response is valid or not with very few resources.

Because it's the client that's doing the heavy work and the client requires a new challenge for each attempt to log in, brute-forcing all possible password combinations becomes (hopefully) too expensive for an attacker.

Have a look at the Salted Challenge Response Authentication Mechanism (SCRAM).

Community
  • 1
  • 1
dtb
  • 213,145
  • 36
  • 401
  • 431
  • okay, if I wanted to use this kind of thing for website login, I have to restrict to browsers that support Javascript. – Andras Zoltan Jun 09 '11 at 09:25
  • @Andras Zoltan: Right, to perform the computations in a browser you need Javascript. I've got a SCRAM implementation in about 100 lines of Javascript using the SHA-1 implementation from [here](http://pajhome.org.uk/crypt/md5/). – dtb Jun 09 '11 at 09:31
2

Are you sure that its not easier for a hacker to intercept the password in clean text then cracking the database information. I'd simplify the algoritm to create and check the passwords and would focus more on important security.

Like Jon said:

I think you have overdone it... :)

CodingBarfield
  • 3,392
  • 2
  • 27
  • 54
  • Https is being used if not for all pages, certainly authentication pages - not perfect - but it should protect the passwords in transit. Ultimately database-theft is the biggest concern; and ultimately I think it's irresponsible to assume that nobody can ever get hold of the database. We have support teams that have unfettered access to our database servers for example; not that I think any of them are crooks - but then nobody ever does right!? – Andras Zoltan Jun 09 '11 at 08:41
  • Maybe you should make sure the support teams do not have unfettered access to the REAL LIFE databases instead of securing passwords. How much damage do you think they can do with just the database content without the passwords. Email adresses and home addresses is enough to start a identity takeover. Focus on security where it matters not where you wan't to add code :D – CodingBarfield Jun 09 '11 at 08:44
  • you actually have to secure passwords and access to database. But salt + over 9000 iteration of SHA512 is too much. – Guillaume Jun 09 '11 at 08:47
  • @Guillaume you have to secure database access and all other weak points too, but he's not doing it. – CodingBarfield Jun 09 '11 at 09:29
1

I think that applying SHA512 any more than once doesn't have any additional value.

Do you have the following authentication workflow:

  1. User enters username and password on the web form and sends it to the server either plain-text or over SSL;
  2. Server calculates the proper hash/salted hash/whatever to compare with the one stored in the database;
  3. Server compares the hash computed with the one stored in the database.

If so, then the hashing doesn't have much sense because potential attacker won't be able to send the straight hash anyway. In this case not hashing makes your system more secure but rather delay before server responds to the request -- which can be accomplished with the much cheaper Thread.Sleep(1000) technique...

Regent
  • 5,502
  • 3
  • 33
  • 59
  • Your argument is accurate regarding brute force hacking from the client side - but what he is preventing is an attack in which an intruder gains direct access to the database. In this case, making it as hard as possible to brute force passwords stored DOES actually make sense. – John Gibb Nov 14 '11 at 15:49
  • @John, you are absolutely right. But still, single SHA512 would be enough for this purpose. – Regent Nov 16 '11 at 11:11