7

In the wake of all these leaked/stolen/hacked government login/passwords being stolen it got me thinking.

How is the leaking of these passwords even possible? Or are they of any real use?

Aren't all these passwords hashed or encrypted somehow? Unless the passwords are stored in plaintext what's the point in even trying to steal them in the first place?

20

What's the point of stealing hashed passwords?

Let's say I steal a hashed password, I can take a random string, hash it, and see if the hashes match. If they do then I've just cracked your password.

For example, assume that under some hash function we get the following hash table:

"cat" --> AA
"dog" --> AB
"elephant" --> AC
...

If I steal a password database and see that your hashed password is AB then I know that the plaintext password is "dog". (technically, more than one string will hash to "AB", but since the server is comparing hashes, not raw passwords, any of them will let me in. So in effect your account has multiple passwords; any string which hashes to "AB" is a valid password for your account.).

Attackers can crack hashed passwords by pre-computing hashes for large numbers of potential passwords (usually obtained by combining dictionary words, or from lists of previously cracked passwords), and then using this as a lookup table to convert hashes back into plaintext passwords.

This kind of attack is generically referred to as a Rainbow Table Attack, with introductory explanations here and here.

One issue with rainbow tables is that to cover any reasonable number of candidate passwords, the size of this lookup table grows to terabytes and requires multiple hard drives just to store it. As you can imagine, attackers have developed fancy tricks for optimizing the reverse-hashing process, so while the general idea of rainbow tables is simple, actual optimized implementations get very complicated very quickly.


It's worth mentioning a few of the common counter-measures that db admins and developers use against rainbow table attacks.

  1. salting is the trick of appending a random string (the 'salt') to the raw password before hashing it. Each user has a unique salt which means that, in effect, each user uses their own unique hash function, so an attacker can't re-use rainbow tables and has to pre-compute a brand new table for each user.

  2. Take the password and run it through a large number of salt-and-hash iterations of a strong cryptographic hash function before storing it in the db (for example, 100,000 iterations of SHA-2), which makes it much more expensive to pre-compute the rainbow tables. It also makes it slower for users to log in.

  3. Use a hash function which takes in a private key (these hash functions are called HMACs). The idea is to use a private-key known only to the server in computing the hashes so that it's impossible to compute a rainbow table without knowing the key. The problem with this is that when an attacker has enough access to steal a whole database, they can usually steal the private key as well.

In your question you also mention storing encrypted passwords. This is similar to 3. in that, unless you have a good way to protect the encryption key (for example, dedicated hardware like an HSM), then the attacker will steal the key along with the database.

  • Are there introductory explanations for optimizing these rainbow tables? – gh0st Jun 25 '15 at 20:52
  • 1
    @gh0st Offhand, I don't know. I'd have to go googling, which you can probably do just as easily as I can. – Mike Ounsworth Jun 25 '15 at 20:54
  • 1
    @gh0st You could also play around with rainbow table generators. I've never used any myself, but I've seen people on this site post about Rainbow Crack (download link) – Mike Ounsworth Jun 25 '15 at 21:00
  • I bet the government also makes are hashes safer by salting them with our Social Security Numbers. – PyRulez Jun 26 '15 at 2:29
  • 1
    @pyrulez I wouldn't put it past them to do that and then store the unencrypted SSN alongside as the salt.:) – DRF Jun 26 '15 at 12:21
8

The login credentials were found in password dumps from other sites. They were credentials where the username was a .gov email address.

The concern is that people tend to reuse passwords and the passwords used on these sites are the password for their government login credentials.

Either the passwords were stored in plaintext or the hashed passwords were guessed/brute forced.

  • If the passwords are stored plaintext then that's just bad practice on the governments behalf. But if the passwords are hashed then what's the point in even stealing this information? – gh0st Jun 25 '15 at 19:53
  • ghOst this forum spends a lot of time discussing password strength which is related to breaking password hashes. If you hear a discussion about good and bad passwords and password complexity then you are hearing a discussion about how fast a hash can be resolved to plain text. Losing hashes is a bad thing especially for uses with weak passwords... – zedman9991 Jun 25 '15 at 20:13
  • 2
    @gh0st I think you did not read correctly, the password was not stolen from a government service/site, but an Employee registered on another page (sillycats.xyz) with his .gov E_Mail adress and the same password he uses in the Government Services. Now the other page (sillycats) was hacked and they potentially stored their passwords in cleartext... So the stolen password for sillycats was also the right password for the government service. – Falco Jun 26 '15 at 9:22
  • 1
    @Falco If you're talking about the report from Recorded Future that's been in the news lately they didn't even test whether the stolen password worked for a govt site, simply that it was associated with a .gov email address. All we know is that the possibility exists that they reused it. – PwdRsch Jun 26 '15 at 15:32
3

I think you are missing something -- for the OPM break in, the problem was that they stole a live credential. That is very useful.

Having said that, note that no password should be useful. In theory, every worker is issued a smartcard that hosts an e-auth level 4 authentication mechanism in their Personal Identity Verification card. (This is the FIPS 201 thing, or HSPD-12.) While at this point no system is required to get rid of all passwords (of which I am aware) all systems are required to be compatible with PIV authentication, and it is a no-brainer that if you have the thing and need to interop with it, go ahead an use it. (Hopefully with some SAML hook that allows you to have alternatives when your PIV isn't available but has the same strength. Phone callbacks are pretty normal.)

  • I forgot about that part of the story too. What about their physical access cards I've seen Army recruiters use. Aren't all gov workers (maybe only those with access to ultra-sensitive data?) required to insert their smartcard on top of using their ultra-secure password? – gh0st Jun 25 '15 at 21:03
  • 1
    The physical access card you are describing are called "PIV" cards. The technical documentation is at NIST SP800-73. Basically, there is a contactless part that is commonly used for physical access control and a contact chip that has a lot more information available, including three certificates used for different purposes. The "password" is just a PIN -- 6-12 digits -- and locks the card after 10 unsuccessful uses. They are nearly identical to the CAC's that army uses. And yes, its ALL government workers. They've been successful at distribution to just about everyone. – Robert Weaver Jun 26 '15 at 12:40
  • I don't think the password credentials was the critical issue with the OPM break. The actual data of value was all the other details, such a full name, SN, parents name and most importantly, details of the government security check. Essentially, all the key info you need for effective identity theft or to blackmail government employees etc – Tim X Jul 3 '15 at 0:09
  • It depends upon how you define "critical". The impact was the loss of PII. The exploited vulnerability was inappropriate authentication of a privileged user through loss of control of authentication credentials. – Robert Weaver Jul 3 '15 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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