I work for a company which has ~16,000 employees. Periodically, our VP of IT sends out a newsletter with "tech-tips" and misc IT stuff. The topic of this week's newsletter was "password security". The introductory paragraph caught my attention:

We just decrypted all user passwords in use to see if employees are using strong passwords. We used a combination of brute force,rcracki, hashcat/oclHhashcat and john-the-ripper tools to decrypt the passwords.

This was followed by a typical newsletter discussing good password practices: Don't use dictionary words; be sure to use mixed case/symbols; don't write your password on a yellow-sticky by your monitor; etc...

Now, I'm no cryptography whiz, but I was skeptical that he claimed that they had "decrypted all user passwords". I can believe that they maybe ran all the hashes through their tools and "decrypted" a large portion of them, but is it really reasonable that they would have the computing resources to claim to have cracked them all? (BTW, is "decrypted" even correct in this context?)

I emailed him asking if he meant to say that they had run all passwords THROUGH the cracking tools, and merely found a large number of weaker ones. However he replied that, no, they had indeed decrypted ALL of the user passwords.

I can appreciate the security lesson he's trying to teach here, but my password is 8 random characters, generated by KeePass. I thought it was pretty good, it's something similar to Q6&dt>w} (obviously that's not really it, but it's similar to that).

Are modern cracking tools really that powerful? Or is this guy probably just pulling my leg in the name of a good security lesson?

P.S. I replied to his email asking if he could tell me what the last two characters of my password were. No reply yet, but I will update if he manages to produce it!

EDIT: Some answers are discussing my particular password length. Note that not only is he claiming that they cracked MY password (which is believable if they singled me out), but that he's claiming that they did this for ALL users - and we have well over 10,000 employees!! I'm not so naive as to think that that means 10,000 good, secure passwords, but if even 1% of the users have a good password, that's still 100 good secure passwords they claim to have cracked!

  • 67
    If your company is hashing passwords with weak algorithms like MD5 without salts instead of good ones like bcrypt, it might be possible. In that case however, the guy is in no position to give out advice about password management. – Ayrx Nov 28 '12 at 14:33
  • 52
    If they decrypted all the passwords, then the problem is not the passwords, it's how they were encrypted and stored (i.e he's got problems, not you). – Andrew Lewis Nov 28 '12 at 16:33
  • 16
    Yeah. This is a startling claim, and the most reasonable explanation is that he is not actually a technical person at all, and didn't do this work himself, and is misreporting the results that his more-technical underling sent to him. Tech: Yes we ran these against all your passwords, and we were able to retrieve some passwords. PHB: Great Scott! I must post this on Twitter! – Warren P Nov 28 '12 at 17:09
  • 16
    I think you're getting a bit overly worked up over this claim. Who cares if the true answer is 90% vs 100%? How is it going to change your actions in any way? How is it going to change the take-away lessons or message? It's not. It sounds like you're just hassling your VP because, well, "Someone is wrong on the Internet". That may not be a career-enhancing move. I think it's a common mistake of technical people to interpret statements in an overly-precise way. It's important to learn how to communicate effectively with others who are not like you. – D.W. Nov 28 '12 at 18:15
  • 10
    If he truly cracked 100% of the passwords then I would not tell anyone, because that would mean that his password is also weak and also all passwords of the IT department. So I don't believe that, or if it is correct, the company has really a problem. – Sunzi Nov 28 '12 at 20:04

13 Answers 13


There's a few possibilities here, some of which have already been called out. Any of these would make it fairly trivial for your VP (IT) to have "decrypted all user passwords" regardless of the definition he's using for "decrypted".

  1. The passwords in question are, in fact, being stored with reversible encryption.
    • Your VP may be referring to passwords for an in-house web application, where they chose to use encryption rather than hashing.
    • Your VP may actually be referring to Windows passwords, and your company's group policy enables storage with reversible encryption.
  2. The passwords your VP is referring to are stored using weak hashing algorithms, and/or are being hashed without per-user salts.
    • The LM hash is one example of a weak algorithm, which is common to Windows implementations that are optimized for backwards-compatibility.
    • Failure to use a per-user salt makes dictionary & rainbow table attacks much easier.
  3. The passwords your VP is referring to may actually be stored in plaintext, and he's just saying they were "decrypted" to hide the fact that they were never encrypted/hashed in the first place.
  4. Your company's employees actually do all use very weak passwords.
    • Regardless of how random your password is, 8 characters has not been considered "strong" for quite some time.

I consider item 4 on that list to be rather unlikely, so unless any of the other three are true it is quite possible your VP is exaggerating just a bit. However, unless you have the ear of someone at the C-level of your company, I doubt there's much you can do to change anything except the actual strength of your own password. To that end:

  • Some people say "12 is the new 8". I say go for 15. This will not only make the password naturally stronger, but it will also prevent Windows from storing it in the weak LM hash format. The LM hash can only handle passwords up to 14 characters long. Windows may throw a warning message when you change your password to be 15 characters or more in length, but this can (in most cases) be safely ignored.
  • Don't use the same password across multiple applications. At the very least, I suggest keeping your work password different from passwords used for personal accounts. Ideally, no two applications should use the same password.
  • Keep up the rest of the good stuff you're doing. Randomly generating your passwords from a full ASCII character set is great. Just make sure that the end product includes all four character types, and no real words.
  • I'd actually consider #4 to be the most likely culprit. We in IT have in the past told users over and over and over again to use a string of 8-ish random characters instead of words/names, back when it was a fairly decent password. Even though security of those passwords has changed, the habit still exists, even among IT users. – Izkata Nov 29 '12 at 19:03
  • 5
    @Izkata True, but it's very unlikely that 16,000 users from one organization have passwords so weak as to be easily breakable when a proper hash & salt method is used. – Iszi Nov 29 '12 at 19:22

The only realistic way that 100% of passwords got cracked is if you're storing LM hashes on windows. LM hashes split into 2 seven character chunks making brute force/rainbow table attacks practicable (they're also case insensitive for added ease). Rainbow tables exist for this and it's easily do-able.

Outwith that, anyone with 10+ character passwords that aren't in a dictionary (or findable by mutating dictionary words) aren't going to get cracked on any reasonable system, even with weak algorithms (e.g. md5) and no salt. AFAIK rainbow tables aren't practical on passwords that long (for reference free rainbow tables have a 2.8 TB pack of MD5 hashes which tops out at some nine character passwords (not full char set).

One point I would make is that if I was the VP of IT I'd be concentrating on getting rid of LM hashes rather than just telling people about good password practices for the very reason that he was able to retrieve 100% of passwords :)

  • 10
    I think that it didn't occur to him as strange that he blew through all 16,000 employee passwords and chose to assume not one employee in the company cared enough to come up with a strong password makes him a very typical/lousy IT manager. – Erik Reppen Nov 29 '12 at 3:41
  • Note that if passwords are 15 characters or longer, LM compatibility is disabled. So even if LM is the default, there is no 100% guarantee. – Royce Williams Jan 20 '18 at 22:21

"Decrypted" is not the right term. That is, the passwords might be encrypted instead of being hashed, but then decryption would be straightforward by whoever knows the encryption key (which is also the decryption key); it would make no sense to apply cracking tools like John the Ripper.

Therefore, your VP is using approximate terminology. It is thus plausible that he might have used approximate syntax and grammar as well. Most probably, they submitted the 10k+ passwords to the cracking tools, and broke some of them (a substantial enough proportion to mandate a VP intervention, but not all of them). His use of "all" is just, let's say, overly emphatic enthusiasm.

Now I am ready to believe that he could broke half of the passwords. It has been documented that the Morris worm, back in 1988, could break about 10% of existing passwords with a dictionary of less than a thousand words...

  • 5
    I still find it a dubious claim. Challenging him to reveal the last two characters of your password is the right way to test it, though. Did he comply ? – Thomas Pornin Nov 28 '12 at 15:42
  • 2
    actually with a public key encryption the encryption key is not he decryption key (a good long salt and this can be secure) – ratchet freak Nov 28 '12 at 15:47
  • 11
    @ThomasPornin: No, he didn't reply to my second email. I see 3 possibilities: (1) He has the answer, but since he's a VP, I was lucky to have received the FIRST reply, let alone expect a second, (2) I called his bluff and he doesn't want to let on by replying without the answer, or (3) he went and rented several Amazon EC2 instances and is furiously running ONLY MY password hash through his tools so he doesn't have to admit he lied. :-) – loneboat Nov 28 '12 at 16:23
  • 2
    Once we assume he's using "approximate terminology", it is likely that by "cracked", or "decrypted", he means - "ran it through JtR". Or perhaps "all" means "way too many". – AviD Nov 28 '12 at 21:18
  • 3
    @AviD - No technical person should use "all" to mean "way too many" or even "most". Actually, nobody should: it's called "lying". – Nathan Long Nov 29 '12 at 14:11

Decrypted isn't the right word, but he was probably going for readability rather than technical accuracy. I also agree that he probably didn't get all of them, but rather a high portion.

Now, your password has a problem: 8 characters isn't very long if your company uses a fast hash like MD5 or LM. A decent GPU-based cracker can achieve around 50M MD5 hashes/sec. If you assume 100 printable characters on a QWERTY keyboard, that's a key space of 10,000,000,000,000,000 for an eight character password, which is an expected cracking time of ~3.15 years. Unlikely that he caught yours, but it's not particularly safe.

Alternatively, he could have a giant 8-character rainbow table for a full character set, which would catch your password immediately.

  • 2
    Note that using a rainbow table is not exactly immediate. If the table covers N passwords but has storage size N/t (thus a t-fold storage optimization), then applying it implies t lookups (a mechanical hard disk can do about 100 lookups per second) and computational effort. A space-efficient rainbow table (e.g. t = 100000) can be somewhat expensive to use. Especially to use 16000 times... – Thomas Pornin Nov 28 '12 at 15:37
  • @ThomasPornin Sure, but it's practically immediate when you compare it to a brute-force. – Polynomial Nov 28 '12 at 16:33
  • 4
    A decent GPU-based cracker can achieve around 50M MD5 hashes/sec. 500M is easily attainable on a $100 GPU, and 5 billion hash/sec on higher end hardware. 28 billion hash/sec for $2700 – Frank Farmer Nov 29 '12 at 0:51
  • @FrankFarmer impressive numbers. Interesting. – Phillip Schmidt Dec 20 '12 at 15:50

There is something I can think of on how they cracked them so fast:

  • They are using LM Hashes at your company for Windows (very dangerous and then you have a larger problem than just mere weak passwords)
  • They used a rainbow-table attack and have a very large rainbow-table (8 characters is possible)
  • They have your passwords stored encrypted rather than hashed and they decrypted them with their key

Anyway 8 characters is by current standards considered strong enough for most normal users, but I always advice to use at least 12. If we are talking about system administrators or people with access to some critical systems, I always advice 16. Some people consider this "overkill" but I rather make them "too" strong than too weak. If you are using KeePass to guard your passwords you don't really have to care about what they are because you don't need to remember anyway.


I did a similar exercise at a client (Windows LM hashes) and I got over 75% of user passwords with similar tools mentioned by the original poster. This type of attack usually gets over 90% 8 char human (western & english language) derived passwords. The longer the password, the wider the charset - the harder this becomes and the lower the pass rate. At my client, a lot of the passwords were 8 chars or less that made life quite easy for me. 25% were long or contained chars not in the rainbow tables.

If your VP of IT had been spending money on this then he might have used one of the commercial passwd lists or a SaaS solution that have truly huge repositories of all available passwords for wide character sets (most don't include £ for example) and if passwords were generally less that 10 chars then there is a good chance that he got a hit rate approaching 100%.


A lot of people have mentioned this much more elaborately as I am about to, and many of them are technically correct with their provided options (give specific attention to Iszi's response as it is technologically sound and complete). However, I just wanted to give my two cents and say that it's probably either one of two things happening.

  1. They are storing the passwords using reversible encryption (An AD Group Policy option), so then it is just using encryption and he did really "decrypt" them. This is a horrible idea, but people do it for password auditing or for compatibility with legacy applications.

  2. He is lieing and they cracked the majority, but not all, passwords.

There is also the possibility that they're storing LM hashes; the reason I don't think this is what they're doing is because they'd have a severe lack of proper security in that case.

I crack passwords all the time at my job and I have to say, I have NEVER cracked all of them. I work for a company with approximately 50,000 employees and we typically will crack about 8,000 passwords with 1 hour of effort, aka the low hanging fruit.

Once you get past the 1 hour of effort step, it becomes exponentially harder to crack the passwords (Since they are typically complex non-dictionary words of sufficient length at that point), so we typically stop there unless we're trying to prove a point or crack a specific password. There's no way most security teams could monitor and audit every single employee's passwords all the time in a large company, so we pick on the easiest to crack and re-crack the passwords on a quarterly basis.


Let me say that if your IT VP in fact did crack 100% of the passwords, you have some glaring security holes WAY above and beyond the relative weakness or strength of the plaintext password chosen by users.

Some possibilities:

  • You're not actually using a hash. Many "built-in" security libraries, such as for Group Policy or ASP.NET, make encrypted rather than hashed passwords an option. The purpose is to allow an admin to recover an account whose password has been lost without blowing the account away entirely. But, if it's designed to be reversible efficiently, then, well, it can be reversed efficiently. If anyone would have that kind of access to decrypt passwords legitimately, it's the CIO, but he may have used the cracking tools just to illustrate that he didn't need admin access.
  • You're using a compromised hash. MD5, LMHash, etc are broken and should never be used for password storage.
  • You're using a hash that is technically crypto-strength, but unsuitable for passwords, such as SHA1/2. This is usually for one of two reasons:
    • The hash is too fast to compute, making a parallel attack such as a GPU or botnet-based cracker feasible.
    • Passwords, even good ones, have relatively low entropy compared to other things a secure hash is used for, like message digests/checksums. Unless entropy is artificially increased using a random salt, it typically takes a brute-force cracker less time to find a colliding password than to find a colliding message of larger input size.

Have the VP show you what he did to obtain the plaintext passwords, and the passwords themselves. It should NOT have been that easy. If you have any control over the hashing function used (meaning it's not built-in, like for Group Policy), I would look at switching to a hash that is designed specifically for password hashing, like bcrypt or scrypt. These two work well because they're very slow, and not only are they slow now, they can be configured to always be slow, by using key derivation functions that take the salt and perform a variable exponential-complexity operation on it to "warm up" the cipher-based hash. BCrypt is a full hash, with KDF and cipher built in; scrypt is just the KDF, that can be paired with any secure encryption, such as AES.


Highly doubt they did that without a huge (unachievable) amount of processing power (for the brute force part, unless it only made up a small amount of the whole process. A quality hashing algorithm is next to impossible to crack, so if he did "decrypt" the passwords, he probably DID have to use mainly brute force.

Also, "decrypt" is not the correct term, decrypt obviously implies the passwords were once encrypted, and encryption implies a two-way function. Hashing is a one-way function only -- i.e., it can't be reverse engineered (well, kind of, but that's beyond the scope of this answer).


8 characters is not enough!(allow me to explain below)

First though I'd like to add, for all correctness that 16k passwords can be all cracked if they are hashed with a weak algorithm. First, one will crack what can sometimes even be more than half of them(depending on the average IQ and carelessness of your colleagues) with a dictionary attack, then one bruteforces the rest using rainbow tables(let's say it's MD5 unsalted). It will take time, but not years, unless of course several people had a very long strong password. This will take a lot of time to bruteforce, possibly too long, but what are the odds, "the intellectual majority" doesn't care about good passwords, and even when they do like you for example, they use 8 characters. ;)

-And back to the the password length-

Though it will depend a lot on what the admin uses to hash your password with

As for example bcrypt, or possibly even better scrypt, with high iteration count will drastically improve the security of any (acceptable) password.

But when you're talking about a company with 16k employees, there's a possibility of things like corporate espionage. People who do these things are most of the time very tech savy and will quite probably have a not very large but still decent botnet they acquired with a personally written and distributed little virus trough for example a video game they put on pirate bay.

I used this example to illustrate how they target gamers with this, meaning they'll have a lot of gpu they can leech when needed.

This way the "expected cracking time of ~3.15 years" as Polynomial suggested above quickly is divided by let's say a thousand computers with very decent gpu cards which can be leeched when idle.

Now your MD5 hashed password is cracked in only ~1.149 days

(so let's say 1% has a 8 character random generated password like you, that's 160 x 1.149 = 221.37 days so it'll take him a little more than half a year to test all the passwords.)

Though Lucas Kauffman above correctly stated that a 12 or even better 16 characters password is technically most appropriate, I myself however prefer a passphrase.

Jeff Atwood the creator of this very website has long advocated them!

So start using one! Easy to remember, improbable to crack.

  • 2
    This doesn't address the actual questions in the OP, though. :-( – loneboat Nov 28 '12 at 22:16
  • @loneboat oh you're quite right, I kinda (wrongly) though that part was obvious now with the other answers containing decent explanations, didn't think about it, but now I added my own, basically repeating them xD – Happy Nov 28 '12 at 22:33
  • @Happy please read How to Answer - answers should, well, answer the question. The OP didnt ask how to use strong passwords, in fact there are plenty of those questions here. Do you have anything to add relevant to this question, or add this information to one of those questions that asked about it? – AviD Jan 22 '13 at 22:59

Few things that bother me in this story which make me believe he is bluffing (or so I want to believe)

  • There are tools to enforce password policy on an enterprise level, it is faster and cheaper to use them than to crack all user passwords just in order to educate them on using better / safer passwords

  • He said he decrypted the passwords, which is a very bad sign, it alludes they are using a bi directional encryption and not a one way hash + random, per user salt (and a slow hashing function such as bcrypt, scrypt or PBKDF2) again, it's probably easier to fix it than go and crack all 16,000 passwords. Showing that lack of attention to security terminology, doesn't go hand in hand in the rock star hacker skills needed to crack 16,000 passwords.

  • Whatever system these password protect doesn't seem to have any delaying mechanism for failed attempt (which allows brute force attacks) so either they had access to some internal database and bypassed any locking / delay mechanisms, or they don't have any such protections on their system.

I really hope your company is not managing people's money, operating sensitive medical processes or anything that has to do with people's lives, as it's a heaven for hackers. Make sure your company's name stays anonymous as it doesn't sound good from here.

As for the VP of IT, I really hope he was joking, but it's a catch 22, if he managed to do what he did, it only means he is not doing his job right, and if he didn't, then he is just dishonest and it's just as bad.


With a set of rainbow tables it is entirely possible that they cracked every password in the company. Rainbow tables are sets of precomputed hashes created in advance of password cracking attempts that are used to crack password far faster than brute force methods. rcracki is one of the tools listed in your question that does just that. hashcat and JtR are brute-force tools although they can be used to create rainbow tables as well.

So there's no doubt what he says is entirely possible.

By the way, an 8 character password isn't enough these days, use at least 9.

  • 1
    +1 for everything but the last sentence, -1 for the last sentence. Length is a poor indicator of security for a start, and 9 printable ASCII characters isn't particularly secure. I'd go for 12 random characters as a minimum if any kind of security margin is to be expected. – Polynomial Nov 28 '12 at 15:07
  • @Polynomial, I agree that 9 characters isn't ideal, but it's an order of magnitude more complex than 8, and it's always a fight to get users to use longer passwords. 9 isn't as good as >12, but sometimes it is about what is achievable. – GdD Nov 28 '12 at 15:27

I am not a security expert, but my understanding is that the encryption of passwords when saved to the Database is one way, it cannot be undone. So the password is hashed and saved to the DB.

All you can do then is when a person wants to login, the newly entered password is hashed and compared with the hash in the DB and if it matches then password is correct.

  • 1
    You can find another value that encrypts to the same value - this is why he listed the tools - they have the effect of decrypting the passwords. – Mark C. Wallace Nov 28 '12 at 15:34
  • Hashing instead of encrypting is indeed an industry best-practice. However, despite this, many applications are still written to encrypt the passwords instead. Or worse, they may keep passwords in plaintext. Check out plaintextoffenders.com for numerous examples from across the Internet. – Iszi Nov 28 '12 at 19:02
  • You can hash all you want, but if you use MD5/SHA-1 (fast algorithms) and don't enforce password policy, any newbie hacker with a dictionary can crack most passwords using brute force on a strong EC2 instance in a few minutes / hours / days (depends on average password length and number of users) all under 100$. Or if you don't salt them then it's even easier using rainbow tables. Linked-in used one way hashes without salt, and got most password cracked when the database leaked. But the real issue is not passwords, all you need is the CEO's assistant to click on a malware link and your are in. – Eran Medan Nov 30 '12 at 3:59

protected by Rory Alsop Nov 28 '12 at 20:58

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.