Crack hashed passwords using a known password

Question

I'm a dev trying to deploy a new dashboard I've written at work, the old one is a mess of hacked together libraries and only about half of the codebase is still even in use (dead code everywhere that just never got deleted, but doesn't do anything)...

I'm not willing to kill myself over this nonsense one more second, I am trying to get the user notes from accounts where a user (rarely) changed their password from the default. I have the default password's stored hashed string, what password it translates to, the hashing mechanism used, the encryption method used, and the hashed strings of the other passwords.

There just has to be a simple way to use this information to decrypt the other passwords right??

If this is not possible, can someone explain to me why? I get the one-way nature of hashing, but given how much information I have about the process end to end, I essentially have the entire process known, so I'm not sure that matters in this instance...

To summarize:

Can I use the knowledge of hashing and encryption mechanisms, along with a sample hash string and its plaintext value, to crack other passwords produced by the same code?

PS: If it helps, each default hash is identical regardless of when it was made...

Answer 1

You got it wrong

There is no "there has to be a way". If there is a way, no password would be protected from a previous employee who leaves with a copy of the database. And then, from any actual employee. This is a very bad "security" system.

Passwords are stored as cryptographic hashes to prevent anybody from seeing the original data. This includes you.

You need not decrypt the passwords

You will be in charge of the new system, and the new complete login process. You know the entire old process. So, in the new system, you only need the old password database and a copy of the old process.

If a login on a new system fails with no data, you execute the previous process on the old password database.

If this succeeds, you know that the password provided is valid, but old. You should, then, create a new credential on the new system, and delete the old database entry, and so any user is migrated with no pain.

Answer 2

Short answer:

You can not decrypt the hash. You will have to use other means to recover it.

Explanation:

The result of a hash isn't an encrypted version of the password. It can not be decrypted, any more than you can take hashbrowns and rebuild a full potato. The result of a cryptographic hash is a scrambled up version of the data, with much of the original data lost. You can guess what the lost data might have been, but you'll probably be wrong, and with cryptographic hash functions, being a little wrong at any one point will make the calculated data vastly different from the original data.

However, you can recover that default password using different means, assuming that you have access to the old system's source code. Here are three possibilities:

1. Since it is a default password, and this password is identical for everyone, the original developers didn't put much thought into password security. Check the source code around user creation; the password may be stored in plaintext.

2. The default password has to be communicated to the new user somehow. Create a new account, ask your IT admin, or ask the HR rep who gives the password to new employees.

3. (Somewhat shady) You can also just copy the passwords over wholesale from the old system to your new system and, when a user logs in using the default password, you'll have it in plaintext for a brief moment while the authentication system verifies that the password matches the stored hash. Use this as an opportunity to switch everyone's password to a key-stretching algorithm such as PBKDF2, bcrypt, scrypt, or Argon2id.

And, if all of that fails, get the user on the phone, explain the situation, and schedule a time where they can watch you work and reset their password immediately afterwards. (I'm only putting this as the last option, because it was mentioned in comments that this is the situation that you want to avoid.)

In all cases, you should expire the password immediately (because you just compromised it). However, the use of a default password hints that the application probably doesn't have a password expiration feature in it, so this is likely a moot point.

And while you're working on authentication systems, head over to the NIST Digital Identity Guidelines, browse the whole thing, and pay special attention to SP 800-63B.

Answer 3

I will add to the plethora of answers here with a simple example, because I find that reducing things to the basics can often be very informative. The key is that hashing algorithms destroy data. An Argon2 hash always has 32 bytes even if you feed it all of Wikipedia. The only way to make that happen is by throwing away lots of data, and once thrown away it is gone.

To demonstrate I have a simple (and terrible) hashing algorithm. It checks its input for any capital letters. If it finds any capital letters it outputs True. If not it outputs False. Here are some example inputs and outputs:

123456 -> False
asdfer -> False
rfjeif -> False
27_+$( -> False
weAdfy -> True
ErYHV1 -> True
12345W -> True
WERERE -> True

Now I have a user's hash and it is: True. What was the password?

Answer 4

Your question is a little confusing, so if the following doesn't fully fit your situation, please correct the following assumptions:

• Your system stores encrypted data for multiple users.
• Each user's data is encrypted using a unique per-user key, or using a master key that is encrypted (wrapped) with a per-user key.
• Each user's key is either encrypted (wrapped) with a key derived from, or is directly derived from, the user's password.
• You know the passwords for some users but not others.
• You know the password hashing algorithm used for authentication.
• You have access to the authentication hashes.
• The authentication hashes are not salted ("each default hash is identical").
• You either know, or can access, the algorithm used for key derivation from passwords.
• You want to decrypt the data for users whose passwords you don't know.

Without knowing more about the system (such as the ciphers used, the hashing / key derivation algorithms used, and so on), I can't necessarily find the weakest points in the system to attack. However, as described, it sounds like the weak link is the password hashes. If they are in fact the same for a given password, that indicates they aren't salted, which implies a very weak password hashing scheme (possibly something as bad as single-round MD5). For an unsalted hash, you can probably use a rainbow table (a lookup table mapping pre-computed hash digests to their input values). However, even if you can't (for example, the passwords you want are not present in the tables you can find), brute-forcing such hashes is usually quite easy; modern consumer GPUs can perform literally billions of such hashes per second, so all you need is suitable hardware (locally or in the cloud), a set of candidate passwords (and processes to generate more, possibly including literally just brute-forcing every possible character up to a given length), software such as "hashcat" or "john the ripper", and some time.

---

To more directly address the question: all modern encryption and hashing standards operate on the assumption that it must be secure even if the attacker knows exactly what the algorithm's steps are. Knowing the algorithm - which strictly dominates the value of knowing some (input, digest) pair for a hash algorithm, because you could compute that digest yourself given that you have the input and the algorithm - is the baseline assumption that all modern crypto needs to be secure against. Crypto wouldn't be worth much if a few (let's be generous) million input/output pairs was enough to break the cipher or hash algorithm.

Answer 5

No, the information about known passwords will be of no help to crack the unknown passwords.

Hashes are the result of one-way trapdoor functions. Hashing differs from encryption in that encryption can be reversed, whereas hashing cannot. Hashing destroys information, and there is no way to reconstruct the original password from a secure hash. If there is a slight change in the original password, the resulting hash will be entirely different. Hence you cannot even compare two hashes to see if the original passwords are similar.

Many open-source projects disclose how their application's passwords are hashed. This does not make the hashes any less secure. There are also databases consisting of known password-hash combinations. Those do not help to crack passwords that are unknown to the database.

You are left to the conventional methods of cracking passwords, which usually involves trying possible passwords in an automatized manner to see if they match the hash. This is by no means easier or faster than 58 phone calls.

Answer 6

The short answer is that all the info you have helps but if you are unwilling to take the time to make 58 phone calls, then you will not like the weeks/months/years it might take, even with all your inside information.

Consider this: every password system everywhere is the same as yours: they know the hash, the system, and they can make as many of their own passwords to test. And hashing is still considered secure, even under those conditions.

You could try running password dictionaries against your hashes to see if users used guessable passwords. But that still won't be 100%.

Answer 7

Ghedipunk mentions this solution but I wanted to expand upon it.

If you are able to duplicate the hashing mechanism successfully, then you can update your users passwords just-in-time.

That is, when a user logs in check if their account credentials are stored using the old method. If it is, validate the credentials against the old method and then immediately upgrade the account to a new (secure) credential.

In the new system, I would also recommend expiring all user accounts using the old method so it forces them to change their password.

The point of cryptographically storing passwords as hashes is so that no-one, including administrators, can discover the plain-text password.

Finally, for you and others, if the old authentication method is found to be secure and follow best practices, then there is no need to utilize a new method. Simply move the old authentication method into your new system.

Answer 8

As the other answers state, recovering the passwords directly will not be possible.

However, given that the data you want is the user notes, there are other options:

DB Admin User

Presuming you have legitimate access to the back end, you could pull the data as a admin user of the db. (see Trotski94's comment)

MITM

You could deploy the new dashboard, and only import the new data when the user gives you their password. This is effectively a MITM. (see comments of Conor Mancone and eckes)

Hashcat

Failing those options, run the hashes against hashcat (the password recovery tool). At the very least it might cut down the number of phone calls you need to make.

Conclusion

Unfortunately, other than the first option, its probably less effort just to make the calls.

Answer 9

Define simple.

Given that you know and have the algorithm, and can verify it for an example, it is trivial to "brute force" the other passwords.

Given sufficient resources, and time. If you break the space up into blocks (work units) and test in parallel things will be easier. Barring a click frenzy driven resource drought you could have a hundred thousand threads going for less than a day to 15 characters say, even without GPU instances and CUDA. This is done for blockchain, Folding at home, SETI at home etc. routinely.

Hashcat is a good place to start, but if the hashes are truncated or substrings you will still need to tweak code to compare with a mask. You probably won't be able to customise an "Antminer" for this.

It is of course way easier just to update (overstrike) their password to a known value, and force them to reset it. It is common in development to just update the hash to an arbitrary password's hash.

At the root of the problem is that you (or your legacy system) is not tracking password age or changes. You want to extract data only for those who have not changed their password or took their time, or changed infrequently?

Have you tried a "group by" and "order by descending"? If they all have the same default password they'll float to the top of that.

I do support the idea of eventual migration, with a legacy store and a "modernised" store.

Answer 10

No.

The whole point of a decent one-way encryption is that just knowing how the encryption works is insufficient to reverse it.

If that weren't the case, people like yourself would be able to decrypt other people's data with only the small amount of information you've told us you have.

It is self-evident that that is not security.

These algorithms are literally designed to thwart exactly what you're trying to do.

Also, the encryption in this case being a hash, there is no one-to-one mapping of data to hash. You claim you understand the notion of a one-way hash, but it seems to me that you still have some reading to do!