Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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.
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.
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.
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.)
