Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×

Comment Re:links to NIST (Score 1) 134

That's not a problem. You would never do any of this on the client end. It's far too easy for someone to strip out the hashing the password stage and replace it with a false "yeah, it worked" signal. Sony did a howler where they implemented a client side CAPTCHA where they sent out the right answer and asked if you'd typed it in. http://cryptogasm.com/2011/07/sony-captcha-fail/

It's might be 1000x slower but, so what? You can afford to take half a second longer. Users generally won't even notice.

Comment Re:links to NIST (Score 1) 134

Dr_Barnowl puts it very well too. I'm taking his example of a 6 digit password here. IIRC someone (maybe at Google?) did research that most users will sit for around a second on a login before they start wondering if it's broken, so that gives you a whole second -- billions of processor cycles -- to run anything you want on the single password. An attacker doesn't have the luxury of spending that much time on a single password. For example, a million seconds (000000-999999 @ 1s each) is about a week and a half. Parallelism helps attackers, really quite a bit -- a single Nvidia GeForce GTX690 has 3072 cores which means that with all cores running you can cut that down to 5 minutes with one graphics card which is why you don't want your hash to be easily run on hugely parallel hardware. The important thing is that trying billions of possibilities in parallel is only something an attacker ever would do. That means you want to make the hash function too big to fit into a GPU core's cache, use instructions that a GPU can't process, lock in some way etc etc.

Comment Re:links to NIST (Score 0) 134

No, making it easier to run multiple instances of a hash, especially on a CPU, doesn't benefit a legitimate user very much but it hugely benefits an attacker. The problem is the different workload that someone storing and verifying passwords has compared to someone who is trying to crack a long list of them. All but the biggest web services will be dealing with roughly one login at a time (ie. you're usually finished with the previous login before the next user tries to login) whereas people attacking will be trying to run as many hashes as possible as quickly as possible to find any matches.

For password storage, you want a really unwieldy hashing algorithm that runs slowly and expensively (in terms of I/O, memory and processing) because you want to punish an attacker for running it so many times. An algorithm that's too memory hungry or esoteric to run on something like a GPU core is all to the good right now.

Comment Re:In summary (Score 2) 241

I'm not sure about a stream of minor complaints from each new starter. I think this can so easily become "we did it differently at my last place" and you need some experience of how it works at the new place too before you can start fixing it. There will be low hanging fruit that's immediately obvious on their first day but given you've managed to avoid burning the place down so far, it's not as if you're sitting around waiting for your new hires to tell how it's done.

I think the key words are "in a constructive way". For example, it seems like this guy's instinct after he (at least thinks he has) tanked a phone interview is to make an anonymous blogspot account and complain how he had too much warning to know if he was free, not enough warning to prepare for the interview and how he can't type and use a phone at the same time. I don't know anything else about him but so far it just doesn't scream "asset" to me.

Slashdot Top Deals

Today is a good day for information-gathering. Read someone else's mail file.

Working...