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...

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – schroeder
    Commented Nov 12, 2019 at 20:00
  • See also stackoverflow.com/questions/16635159/…
    – atk
    Commented Nov 13, 2019 at 16:42
  • If you have db access you can probably just replace the hash in the db with the hash of a known password for temporary access and restore it when done.
    – beppe9000
    Commented Nov 24, 2019 at 12:55

10 Answers 10


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.

  • This is very close to what we ended up doing - it just required a complex migration process as the plaintext is simply irrecoverable - cheers
    – MJHd
    Commented May 3, 2023 at 23:23

Short answer:

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


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.

  • 7
    OP already knows the default password ("I have the default password's stored hashed string, what password it translates to"). The goal appears to be recovering other users' passwords (or the data that they protect), for people who changed it.
    – CBHacking
    Commented Nov 12, 2019 at 0:05
  • 27
    +1 for the "hash"brown -> potato analogy. :-) Commented Nov 12, 2019 at 10:00
  • @CBHacking If they have the default password hash they can simply change the hash in the DB and effectively reset that user's password to the default. Commented Nov 12, 2019 at 13:38
  • 3
    Third option isn't shady, it's a standard migration technique. Many frameworks (e.g., Microsoft's Identity framework) even have explicit support for rehashing such passwords. Bonus points if you eventually force a password reset on any lingering, unmigrated users.
    – Brian
    Commented Nov 12, 2019 at 15:31
  • 1
    @DewiMorgan: Possibly apocryphal (I don't have a copy of Knuth's The Art of Computer Programming, Volume 3, which seems to have the best sources on the origin of the term), but I've been told that as jargon, hashing directly derives from chopping up and mixing corned beef hash. I use hashbrowns because more people around me are familiar with it.
    – Ghedipunk
    Commented Nov 14, 2019 at 22:48

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?

  • 36
    So a hashing function is a deterministic information shredder.
    – ig-dev
    Commented Nov 12, 2019 at 1:45
  • 6
    @ig-dev yup, pretty much Commented Nov 12, 2019 at 1:46
  • 11
    This is most likely irrelevant. Any password that produces the same hash will work as a password. You don't usually care if the password is "Swordfish" or "sdfj340q9t"#%¤Afaweit34iQWE#¤t", you care about if the system will authenticate you when you enter the candidate password. Also, if the hash is 32 bytes, and one of the canditates that produces the hash is "Swordfish" you can be fairly confident that "Swordfish" is the sequence of characters that the original user entered.
    – Taemyr
    Commented Nov 12, 2019 at 7:53
  • 7
    @Taemyr True normally but not for the OP who clearly wants to find the actual password for the user and not just a collision. Commented Nov 12, 2019 at 10:50
  • 8
    @Taemyr My goal was to provide a clear and concise example that shows why it can be impossible to get back the original password. I think that is helpful for the OP, and while there are obviously many caveats, the other answers here go into more detail. As a result this is intentionally minimalistic. If you disagree with my answer you are welcome to downvote it. Commented Nov 12, 2019 at 12:09

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.

  • 1
    Thanks for this, other than advice about how to run a system, which is hopefully useful to others, you are the only person who understood and accurately parameterized your response - thank you, and sorry for being curt before :)
    – MJHd
    Commented Nov 12, 2019 at 16:05
  • 19
    If you think people did not understand you it would help to actually answer their questions in a clarification to your question. Multiple people ask you for further details. @MJHd
    – eckes
    Commented Nov 12, 2019 at 22:02
  • Would a salt actually make it harder in this case? It sounds like this dev has access to the DB, which would mean s/he would probably have the salt as well as the hash. And since they are only trying to crack a single password, couldn't they simply add the salt to each candidate password before hashing? Commented Nov 14, 2019 at 0:22
  • @MartianInvader yes a salt would make it harder. The point of a salt is to make the attacker have to attack each hash individually, i.e. to prevent the use of rainbow tables. It is generally always available to anyone who has the password hash, and is't considered particularly secret.
    – Jack
    Commented Nov 14, 2019 at 2:13
  • Ways in which a salt makes things harder: Can't use a rainbow table (or just google the digest, which works alarmingly well for MD5), can't tell when multiple users have the same password, can't crack multiple passwords in parallel (and the OP is trying to crack multiple, different passwords, @MartianInvader)
    – CBHacking
    Commented Nov 14, 2019 at 4:27

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.

  • It actually will help, if you know the method how the hashes are constructed it is easier to brute-force them (but it still might be impossible)
    – eckes
    Commented Nov 13, 2019 at 19:03
  • That's true. At the same time, presumably all that is required to determine the hashing function is knowledge of a single user/password combination.
    – ig-dev
    Commented Nov 14, 2019 at 4:09

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%.


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.

  • 1
    Thank you for expanding on this point. I missed the specific needs for OP; I misread the question... but this is a good explanation of how to migrate old password hashes (such as those done by a single round of SHA2) to a more secure key stretching algorithm. I also like the point of expiring passwords from insecure systems.
    – Ghedipunk
    Commented Nov 13, 2019 at 6:56

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)


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)


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.


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


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.



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!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .