Slashdot Mirror
New 25-GPU Monster Devours Strong Passwords In Minutes
chicksdaddy writes "A presentation at the Passwords^12 Conference in Oslo, Norway (slides), has moved the goalposts on password cracking yet again. Speaking on Monday, researcher Jeremi Gosney (a.k.a epixoip) demonstrated a rig that leveraged the Open Computing Language (OpenCL) framework and a technology known as Virtual Open Cluster (VCL) to run the HashCat password cracking program across a cluster of five, 4U servers equipped with 25 AMD Radeon GPUs communicating at 10 Gbps and 20 Gbps over Infiniband switched fabric. Gosney's system elevates password cracking to the next level, and effectively renders even the strongest passwords protected with weaker encryption algorithms, like Microsoft's LM and NTLM, obsolete. In a test, the researcher's system was able to generate 348 billion NTLM password hash checks per second. That renders even the most secure password vulnerable to compute-intensive brute force and wordlist (or dictionary) attacks. A 14 character Windows XP password hashed using LM for example, would fall in just six minutes, said Per Thorsheim, organizer of the Passwords^12 Conference. For some context: In June, Poul-Henning Kamp, creator of the md5crypt() function used by FreeBSD and other, Linux-based operating systems, was forced to acknowledge that the hashing function is no longer suitable for production use — a victim of GPU-powered systems that could perform 'close to 1 million checks per second on COTS (commercial off the shelf) GPU hardware,' he wrote. Gosney's cluster cranks out more than 77 million brute force attempts per second against MD5crypt."
So it doesn't matter anymore I'm using 000000 as password ....
Who gives a rat's ass about such golden oldies? It's been possible for the longest time to fairly quickly crack windoze passwords (if you have the file) and MD5 has been known to be insecure for quite some time already...
So newer hardware is faster than older hardware. Who would've thunk?
My conclusion is to use different passwords for different things. They don't have to be that strong.
As long as the passwords are strong enough to prevent brute forcing over the _NETWORK_ they are strong enough. If you don't pick an overly stupid password then either you or the site is going to be pwned before the hackers brute-force/guess your password over the network.
If someone has hacked into the site to obtain the hashes, it's likely they can do other stuff anyway (make transactions, get your info, maybe even get the plaintext of your password), so don't waste your time making and using super long passwords.
So now that passwords as a system is officially broken, can we please move on to something better? Something that wasn't invented to allow soldiers standing watch in the middle of the night to tell their mates from their enemies, but is actually designed for computers?
And no, of course I don't have any better ideas... this is /. and I'm here to pointlessly criticise!
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
If he's able to attain numbers like this with four machines, how will it perform as a cluster of eight? Or sixteen?
It doesn't devour "strong" passwords in seconds. It devours weak passwords, in seconds. A fourteen character password is, by definition, pretty weak.
For comparison, the password to an account I use fairly often is 128 characters. At 348-billion password attempts per second, it would practically take eternity. Even if it made attempts 40 times faster (one hundred billion times per second), it would take (according to SGC's haystacks calculator) "76.10 billion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion trillion centuries".
I might use a fourteen character password on a trivial site that I don't care about, but probably not even then.
that's not the context this sort of thing works in.
passwords are stored as hashes. for example of you log into a terminal you don't want the terminal sending your pass over the network.
So it pulls down a list of hashes and compares it to the hash of your password. or it hashes your password and sends it over the network.
The idea is that someone picks up these hashes and then brute forces them at home.
not that they keep trying to log into your account one attempt at a time.
This is well known and no sane people uses NTLM auth anymore, even Microsoft recommend to deactivate this authentication method. The idiots at Microsoft used a DES ECB implementation instead of CBC that anyone with two ounce of crypto knowledge would choose. The practical impact of this very bad design choice is that a 14 character password has as much complexity as two independant 7 characters passwords ! So when the authors brag about cracking a 14 character password in 6 minutes, what they're really doing is cracking two 7 character passwords in 6 minutes, this is entirely different and not impressive at all.
http://www.transparency.org
Single hash passwords have been a bad idea for a while now. If you're a dev, PBKDF2 would be a better choice.
That doesn't work for systems with password files. Once a system's password file (which includes the hashed passwords) is compromised, then the password programs just compare their generated hashes against the file.
We had an old ATM testing machine that ran a dinosaur version of x86 SunOS and didn't have the root password. We were able to use a FreeBSD CD to mount and recover the shadow password file and used John the ripper to crack the passwords. Ran it for a month on a dual processor 8GB rackmount.
.,$s/autistic/savant/
-- open source? sounds like the real book --
Yeah, that's called a DOS attack. You can' t use your computer either right ?
Just put a delay between password attempts (say a few seconds) and a one day lockout on three failed attempts.
Try throwing billions of possible passwords at that asshole ....
A customer asked us recently if we could recover some of their passwords stored (hashed) on our system.
"Sure we can, if you used really poor passwords."
If you were blocking sigs, you wouldn't have to read this.
I was under the impression that a 14 character NTLM password was basically two 7 character passwords, and the fact you can crack them easily is not news. Rainbow tables will crack them in a matter of seconds on a standard PC setup.
What solution would you propose?
The password crackers are just trying hash checks, so messing around with retry attempts wouldn't help. They're not sitting there trying to log into your computer, they grabbed the hash via some existing method to do so and are cracking it offline at their leisure on their own machines. Encryption would help prevent them from extracting the hash in the first place, but once they have it no amount of login security would do anything.
This isn't about live attacks on a system. This is about "offline" attacks and even things like hash collisions (where someone can make a certificate or a download that has the same hash as the "official" one but is fake or contains malware, etc.).
If you can take a login system and run millions of queries against it, it's a stupid system. But if you can steal a hashed file of password, or old hashed tokens from the network, then you can theoretically break them now in the time it takes to reboot the computer (if you could log into this other system remotely).
Things like the Sony break-in would reveal everyone's password, not just the other stolen details. And on a local network, you could sniff tokens sent for NTLM services etc. and start impersonating other users before it could even be detected. Of course you have to have a certain level of compromise / access already to get to that stage, but it doesn't make it any less dangerous to be able to forge hashes or find out their plain-text.
Please note, also, that things like these hashes have been used historically to verify software is genuine, as part of encryption algorithms, random number generators and all sorts of other things. At the time, they were reasonably unbreakable, but now they aren't. And that breaks lots of things if they are still relying on them.
Impact to security-conscious users: Zip.
Impact to security-unconscious users: Huge.
Lets see how that works with 256bit or even 512bit hashes.....
The Grey Goo disaster happened 3 billion years ago. This rock is covered in self replicating machines!
Let N be the number of bits of real entropy in an item of human memory. N is somewhere between 50 and 70. (Proof: you can remember RWOLZEKBYT or "correct horse battery staple" if you have to, but you've got no prayer of remembering RWOLZEKBYTDUQLZPEJNB or Rw3L$E5Kÿ(t. )
Let 2^R be the instruction rate of the largest computer affordable by a large nation or corporation. R is about 56 at the moment.
2^(N - R) is the number of seconds before we're all completely fucked.
what about those?
I'm really low on porn at the moment and hit my monthly internet quota!
Umm ...
/etc/shadow of a known password, sync the file systems to disk and reboot.
mount the SunOS disk, write a new password hash into
Does not take anywhere near a month!
I have an old trucrypt container that I forgot the password to. Does this mean I can now recover it? (it was fairly short, perhaps 8 characters)
Having been, up until just a few months ago, one of those unwise people who used the same, only moderately complex password everywhere, for everything, I understand the convenience issue. There are dozens of sites that want you to login, and you can't remember dozens of passwords. Best practice is to maintain separate passwords, so the loss of one won't affect the others... but that doesn't feel like something that could happen to YOU.
Then, something DID happen to me; I got a warning from the Guild Wars 2 people that someone was trying to access my account, with my password, from China, and would I confirm the access? (no!) This woke me up, because it immediately occurred to me that I was using the same password for my gmail which secured that access method, which implied that, since the email had only just come in, that I might literally only have minutes to do something about it. And so I quickly changed all my compromised, important passwords... and then, the same day, downloaded a password manager.
Nowadays, I don't even use words for passwords; they're all long groupings of random characters, which I couldn't remember if I tried. Fortunately, I don't need to try; I've got machines to handle this stuff for me, and I don't even need to bother typing the monsters myself.
Generally speaking, you don't make a gazillion tries through the actual authentication gates; that sort of brute force is an obvious threat that people know how to look for, like an army of barbarians storming the gates of the city.
The kind of action described here is more an army of monkeys on typewriters trying to guess passwords off a stolen list of passwords; eventually, they'll get it. They won't know they've gotten it unless they already had (the hash of) your password to begin with, but that's doable now; we finally have enough monkeys to get the correct answers in a reasonable amount of time. Essentially, what this finding means is that the way passwords are currently stored in hashes is no longer cryptographically strong enough to be computationally safe, and a higher standard of security is needed.
Not seeing anything about WPA.
You can pull those truly out of thin air and since they are rehashed 4000 times brute forcing those is slow even on most modern hardware. Generally in the range of a 1000 to 5000 keys per second.
More than a thousand years for a 8 character password. And you can't even use a shorter password on WPA.
GPUs do change the picture a bit.
I'm not the GP but there are a few measures that can be considered such as
1: deliberately slow hash functions. You can make the crackers job a few orders of magnitude harder this way.
2: dedicated password checking servers (ideally a seperate machine but privilage seperation on the same box is better than nothing) so that cracking your webapp doesn't hand the attackers the password hashes on a silver platter.
3: physical hardware the user is given that provides one-time use security codes
Of course none of these measures are free and that means most forums etc won't bother with them :/
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
imagine a beowulf cluster of these...
If anyone with motivations beyond that of a script kiddie is doing this, then you are already totally screwed - they can already steal all your transaction information or make their own transactions or transfer funds or do whatever they want to do as ANY UID in that system - WHY would they ruin that and post them on the web?
And if it *IS* a script kiddie, only interested in "cred" and he leaks the password hash DB on the net, then AGAIN so what, because like the GP said you are using different passwords for different sites.
If passwords are getting cracked so quickly these days, what then is the answer? Authenticators are all well and good, but I don't have room on my keychain for one for Blizzard (I know about and have the one for my iPhone), one for Amazon, one for PayPal and eBay, one for Gmail, etc and so forth.
What would be a viable solution then?
-- Wiccan Army, 13th Airborne Division "We will not fly silently into the night"
wouldn't crazy brute for attacks like this be eliminated with simple attempt limitation? It maybe be able to do the bruteforce attacks at a megazillion per second, but if the connection is actively refused after 10 tries, what does it even matter. You could theoretically set the limit to any amount way under the total amount of possibilities and it still wouldn't matter. as for building passwords that are stronger, we need to move away from 8 - 12 char limits with case and special characters and force people to use complex strings that have 25 - 50 chars in them but are simple to remember for example something like "mydogsnameisfluffy" or "whydoineedacrazyasspassword" both of these are much harder to crack than "8&#sref"
So it seems all server side code should be storing:
algo_name, hash(salt + password) ...that way, if your algorithm of choice proves to be a bit feeble, you can gradually upgrade to a better one by getting your users to change their passwords. If anyone's account has a really old algo still on it, then the account gets disabled. Whilst this doesn't "solve" the problem, it means you don't have to throw everything away because someone found a quick way to compute hashes using your chosen algorithm.
Either way, it seems we're about on target for kittenauth now ;-)
Time to move on to fingerprint scanners for security, but with a twist: they *only* recognize 'dead fingers'.
Don't know about you, but I'm already set.
Or just clear the password to nothing using ed (done it with Solaris8 sparc boot media), or some easier to use editor if they've put that on later install media.
That isn't exactly how rainbow tables work. In fact colliding chains is undesireable for rainbow tables. While it is true that you might end up on another "chain" the odds of that are exceedingly low with even 128bits of hash space and any decent salt.
The reason for itterating a password hash it to slow it down, to try and thwart brute force, however it doesn't work that well against GPUs since they have so many cores to work with and VERY efficient implementations of the algorithms. Some password hashing algorithms (I believe bcrypt is of this sort) can be tuned to take more memory and, this, keep GPUs from working much if any faster than a normal CPU. This, really, needs more research but the principals are simple: make memory access patterns impossible to predict so you can't stream in cache lines and make the space required "large" (lare isn't HUGE, I think a few megs is large enough. You won't find this in a normal cryptographic hash as they are *designed* to be fast, and that is a good thing for every use aside from this)
Rainbow tables work in chains, as you said, but what they do is they generate a hash from a "seed" for each chain THEN they "map" that hash back into the password space, and then hash that, map, hash, map, hash, da da da. Once you do this for a good long ways you store the final hash and the seed for this chain. You have MANY chains.
To find a password from the hash you pick up right in the middle of that. Lets go step by step:
You have a hash to reverse
1) check the hash against your "end of chain" hashes
2) If the hash has no match you do the same "mapping" that you did while creating the rainbow table into the password space
3) repeat until you find an "end hash" and therefore the chain, or you find that this password isn't in your table by mapping-hashing more times than you used for the chains
4) assuming you found the end hash you then take the "seed" for that chain and start hashing and mapping it over and over until you find your original hash
5) the password that you hashed to get there will be the correct one
So, yeah. Lots going on and many subtle problems that can creep in, but the chances of a collision due to itterated hashing aren't large. Smaller than anything you'll ever need to worry about. Like I said, too, itterated hashing doesn't help much against GPUs
md5sum
d41d8cd98f00b204e9800998ecf8427e
Crack the code to open President Skroob's luggage?
"A 14 character Windows XP password hashed using LM for example, would fall in just six minutes"
Which is nothing impressive. NTLM has a 14 char password max and pads sub-14char passwords with null. It then breaks the password into two 7 byte pieces, hashes both pieces, then concatenates the two hashes together. Using NTLM, a 14 char password at worst 2*96^7 instead of 96^14, which is a factor of 37,572,373,905,408 difference. If NTLM was properly designed, that same 14 char password would have taken 37,572,373,905,408*6min to break or 428,908,378 years.
14 char passwords are still safe assuming there isn't a huge flaw in the password storage.
So, can this also bust DRM schemes like the system in bd+?
Passwords^12?
Passwords carrot twelve? WTF kind of a name is that?
Here's how to crack the password for the Win98 login: press [Esc].
Get free satoshi (Bitcoin) and Dogecoins
I just helped a client of mine move email providers, since they all have iphones and use Outlook to manage their accounts, when I set up the new accounts I used strong passwords (32 randomly generated characters).
When I printed off the spreadsheet so they could file it away, they freaked out and demanded I changed them back. Their old passwords were simple ones like you mentioned.
I don't even understand it, I explaines they don't have to put in their password when they want to check their email, outlook takes care of it. If for any off chance.reason, Outlook or their phones lose the password, they have the list. So long as they have reasonable passwords on their computers and phones its a non issue and protects then from external attacks.
I'm just the web developer and I can't tell them what to do but I was blown away... it doesn't even boil down to laziness in this case.
For example, I have a really hard time remembering phone numbers, so I use mathematical rules to aid in memory recall. Like, take my cousin's phone number for instance (not a real number).
The Area code is (516) so I remember that as "Prime" 4^2 or "Prime" 16^1/2. Because I know 5 is a prime and 16 can be squared perfectly. Then the next three numbers are 231, which all happen to be Fibonacci sequence numbers. So I remember that as "FIB."
Finally, the last four digits are 4447, so that translates as 4^3 and a Prime or 7. The point is, part of the insecurity problem is the use of a small number of rules to create the passwords makes them more vulnerable. An additional set of "intermediary rules" could be implemented to make security more personalized and harder to defeat.
What would Richard Feynman do, if he were here right now? He'd do some math and he'd follow through!
Sending the hash over the network doesn't work. Anyone who knows your *hashed* password could log into the machine by sending the hash, effectively making your hash *into* the plaintext.
not the quality of the password, but the quality of a service that allows 348 billion failed password attempts per second.
I haven't thought of anything clever to put here, but then again most of you haven't either.
4. Weeding out 'bad' passwords when the user tries to set them with a good password policy.
A good portion of any large account database can be hacked almost instantly because of common passwords and simple plain dictionary attacks. This is the low hanging fruit that can be easily farmed by any 2-bit cracker with a GPU in short order these days.
Yes, it's easier for a hacker to attack your accounts if he knows there will be at least 9 symbols, some letters, some numbers, and maybe a symbol or two, but that is a much higher baseline then 'Password1'.
There have got to be some really impressive-looking passwords that have a hash collision with common dictionary words.
The thought of this amuses me to no end.
Competition Good, Monopoly Bad.
Anyways, what's its $2a$08$ rate? How about scrypt?
http://en.wikipedia.org/wiki/Crypt_(Unix)#Blowfish-based_scheme
I just did a google search and couldn't find VCL. Can anybody link me to the project/documentation?
Computers are far more efficient at cracking password then people are at remembering them. Simply put, it's a math problem. Computers are much better at math then we are.
The server sends a random string of digits to the client and says "encrypt this using your hash as the key". The client does so and responds with the encrypted data. The server, since it knows what the user's hash should look like, can then duplicate the encryption function and compare the results. The server will never see the plaintext of the password, and the hash will never leave the application space on either end, and replay attacks are impossible since the random string will be different every time (and therefor the expected response will be different every time).
Not that many places are doing this currently. And not that such a system is magically foolproof, but it does eliminate the kind of attacks you are describing.
Serious question; do you use Adsense? A lot of accounts were compromised with some pretty impressive (well, compared to others) phishing accounts.
Yeah, I've had a close call that made me change my approach as well.
Wearing pants should always be optional.
So 348 billion ntlm/sec, vs 77 million md5crypt/sec...
ntlm as used in the latest versions of windows (vista was the first version to not use lm by default), and md5crypt which is already being deprecated by most linux distros...
Not that it matters, if you get the hashes for a windows box you can pass the hash (ie use it without cracking), you can't do that against typical unix boxes.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
... is so hard to do. With this machine, we don't have to, anymore.
now we need to go OSS in diesel cars
I think NTLM only keeps a 128bit hash, so if it were possible to brute force the entire key space, the attacker would likely find a hash collision that works as your password before finding your actual password.
...Which is an interesting tangent to think about, as this hardware could be used to do some interesting research in the name of improving security. It would be really interesting to search an entire hash space to see how many collisions occur, and where.
HA! I just wasted some of your bandwidth with a frivolous sig!
The argument is that people should protect their password hashes better, to prevent someone from getting them and shipping them off to Curiosity to be cracked with a pile of Tesla boards or Martian quantum computers or whatever.
I blame goddam NASA for not properly locking down Curiosity's Tesla boards and letting any old script kiddie use them to hack into banks. They are the real criminals here....
HA! I just wasted some of your bandwidth with a frivolous sig!
Hashing needs scalability; bcrypt has had it built in! as computers get faster you just amp up the complexity of the bcrypt hash function. old low complexity hashes are backwards compatible so hashes stored over long periods would need to be rehashed maybe every decade...
Democracy Now! - uncensored, anti-establishment news
I'm pretty sure once you have the password hashes no amount of policy is going to slow down your cracking efforts.
I'm pretty sure once you have the hashes you don't have to brute force it, you just send the hash to the system and you're in.
If you are not allowed to question your government then the government has answered your question.
They're not sitting there trying to log into your computer, they grabbed the hash via some existing method to do so and are cracking it offline at their leisure on their own machines.
How do they know they have cracked it without logging in? The program would also have to be sophisticated enough to check if the possible password was actually likely to be a password or otherwise just try it and see.
If you are not allowed to question your government then the government has answered your question.
Pardon me while I place my tinfoil hat on... done... If the researcher is able to do this publicly how long have our friends at the 3LO's been doing this with their acres of computers of servers?
Look at the wiseguy ticket scam. They downloaded the img file for every captcha then generated the correct responses.
This box was built with off the shelf components and runs on an open source plaform. Your passwords are not effective. I don't care how much thought and obfusction you think you've injected into them, how long they are or how often you change them. It no longer matters. What we need to do now is change the game. We need to remove the human element. We need to automate. And by that I mean much more than scripting changes. We need to automate compliance. Devices have stipulated software and configuration based on the service they provide, and a system exists which enforces that stance. Just because you know the administrator or root password, doesn't mean you can load software onto the server. Just because you know the enable password doesn't mean you can change the router configuration. You may be able to cause a change to occur, but the system will roll it back or unload that software if it violates the policies that govern that device. If your PC sundennly starts blasting out traffic to all sorts of Internet addresses, your switch port gets turned off, or your wireless session gets dropped.
The idea is that humans, engineers and administrators tell the supervisory system how the services, and devices should behave; what components and configuration details they should exhibit and on what schedule changes can be performed. But a human NEVER makes a change. If they do, it's undone, removed, uninstalled or otherwise mitigated to return the device to its prescribed state. A very simple clustering/voting kind of setup could keep the supervisory system itself in its prescribed state.
This has the added benefit that the new slave labor situation present in nearly every IT department comes to an end. No longer are junior engineers relegated to performing endless mindnumbingly simplistic operations that are of litle actual value to the organization, add nothing to the engineers resume and are mostly done poorly. Humans are allowed to do what they do best. Think. Plan. Design. And computer systems take on the job that THEY do best. Execute.
Can anyone find what type of server/motherboard combo they used to get what appears to be a 9-slot PCI-e motherboard with 3x PSUs? They have 8 cards in one box and a infiniband card.. I can't seem to find what this is (or how I can buy it)
I don't; but if I did, that'd be one of the first passwords I changed. Anything related to your money is up there, as should be anything that can get someone into your other accounts (like the emails you use for 'lost passwords' and such).
Thank you; I was just curious, except for the typical keystroke logger and the Adsense phishing e-mail, I hadn't seen or heard of actively heard of any "Chinese" into Gmail.
Even though you may have not actively been on top of your password, it didn't strike me that were the kind of person that would also been oblivious if something funny was happening.
Thanks again, just thought that the successful Adsense phishing happened to someone else.
Wearing pants should always be optional.
and a one day lockout on three failed attempts.
And now you can DOS any user whose username you know by sending "bullshit", "bull crap", and "bullpoop" as the password.
Why not use graphics patterns, like Windows 8, to generate very long passwords that do not have to be remembered or typed into a keyboard? It would not be hard to circle all the colors in a picture in spectrum order. The reduction of these finger strokes would yield a lot of data and that, together with a decent binary hash code, becomes the working password.
You can have a Windows password with extended characters if you know the character code with something like ALT+KP0, then the three digit ANSII code on the keypad (at least as of Windows 2000), allowing things like Pâssw0rÐ (one capital, two extended, four lowercase, one number: eight characters albeit ~17 key presses) ... it's unclear from my (very hasty) reading of the paper if that was considered, but I imagine that even if it was, that password would be signficantly more resource-intensive to crack. I had a friend whose password was a fully punctuated English sentence with a single extended character somewhere in the middle of it, probably 20+ characters including that one hard-to-locate hard-to-crack guy.
I still have a .zip file that I encrypted with a password using such a character. Gave up trying to brute force it after a week or so. At least my data's safe...
Use my userscript to add story images to Slashdot. There's no going back.
Use my userscript to add story images to Slashdot. There's no going back.
You can have a Windows password with extended characters if you know the character code with something like ALT+KP0, then the three digit ANSII code on the keypad (at least as of Windows 2000), allowing things like Pâssw0rÐ (one capital, two extended, four lowercase, one number: eight characters albeit ~17 key presses) ... it's unclear from my (very hasty) reading of the paper if that was considered, but I imagine that even if it was, that password would be signficantly more resource-intensive to crack.
I did the math, not sure why others haven't pointed this out yet. There are 189 nonspace printable characters in the 256-char ANSII code map. Adding one for space, that's 190:
190^14 combinations / (348 * 10^9 pw/sec) / 86400 sec/day / 365.2425 day/yr == 7275722393956 years
A long time. BUT even base64 is too complex for this purported rate:
64^14 combinations / (348 * 10^9 pw/sec) / 86400 sec/day / 365.2425 day/yr == 2188329 years
What am I doing wrong?
Use my userscript to add story images to Slashdot. There's no going back.
Repeated hashing is done to slow down the speed at which an attempt maybe tried. Take PBKDF2 the point of this is to reduce the ability even by specialized hardware (such as discussed in the article) to brute force the keyspace. If you are not talking about PBKDF2 but some other attempt to repeatably hash then don't bother replace your technique with PBKDF2 or something better still.
Fast hashes are BAD for password security. Slow hashes are GOOD for password security. Repeated hashing is an attempt to make a fast hash algorithm slower but maybe it doesn't salt and maybe it doesn't do it as well as PBKDF2.
Furthermore to this (with PBKDF2) I can simply increase the number of rounds of iteration I make for all new password set after a point in time. So this means I can always stay ahead if the game without significantly redesigning the system. It also means I can store in my password database the number of rounds/iterations as well as the result as well as the date the password as last set/changed. Now I can enforce a policy where by inactive users of the system as locked out (if they have not used their password in 12 months) and when I need to increase the number of iterations to stay ahead in the arms race I give all existing users 12 months to login where by they get notice to reset/change their password. They login with old password maybe doing 10000 rounds and before they can use the system they are forces to change their password. During this reset I re-encode their new password with 20000 rounds and store it in the database.