The hash is 1a469f2c34699d2b4ac3343fe6020a, all of my users passwords have this password hash when i looked in the database. So if I would try to crack a users password how am I supposed to do that if they all have the same hash? The hashtype is MD5. And why are the hashes the exact same for every users password?

closed as off-topic by Anders, Steffen Ullrich, Mark Buffalo, Tobi Nary, schroeder Nov 4 '17 at 11:23

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – Anders, Steffen Ullrich, Mark Buffalo, schroeder
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Sounds like your sql query to retrieve the table or the implementation of calculating a hash and store it in the db are either wrong – Megabeets Nov 4 '17 at 9:36
  • 2
    And it cannot be (pure) MD5 as you claim - according to your question these are only 30 characters hex but MD5 would be 32 characters. – Steffen Ullrich Nov 4 '17 at 9:39
  • Why would you want to crack your user's passwords? Is this a real application or a test application for infosec training? If you want answers as to why an application might be doing something, anyone would need a LOT more context and a lot more details. Even you. Break down the problem into its layers and confirm the proper operation at each layer. – schroeder Nov 4 '17 at 11:25

The short answer is, you obviously have a (critical) bug in your hashing code. As it stands, anybody can probably sign in as any user at all, because for some reason your password hash function always produces the same output.

There's a few different ways this bug could come about, none of which are inherently obvious. One thing to definitely consider, though: are you actually including the password in the data you feed to the hash function, or are you terminating the hash without adding the password?

Another risk is that the bug is actually in your database code, and when you're creating / updating a user's password hash, you're accidentally setting it for all users, rather than just the specific one being created/updated. This is highly exploitable: I create my own account, and then use my password to log into an arbitrary user's account, because their hash got changed to mine.

OK, enough hypothesizing. The actually important stuff here is that, frankly, you should not be writing your own authentication system. Even leaving aside a critical bug that really, really should never happen - you should have found this during development or unit tests, if nothing else - your system is just not secure.

  • You shouldn't be using MD5 for anything, it's got known weaknesses and is considered cryptographically broken. You should be using the SHA2 family of hash functions for anything that needs a fast hash; even SHA1 is considered deprecated for new code.
  • You should never use a fast hash for storing passwords. Passwords should be hashed using a deliberately slow and expensive hash function, so that if somebody dumps your password database, it's hard to brute-force the password hashes it contains because each round of the brute-forcing takes a while.
    • Using a single-round fast hash, commodity hardware (like high-end graphics cards) can compute billions of hashes per second, enabling absurdly fast password-cracking. Instead, use functions that are intended for key generation or password storage.
    • PBKDF2 is the most common, but is also the oldest and least-amount better than a single fast hash. Bcrypt is better, but against modern hardware it's not really very good anymore. Scrypt, with the right parameters, is the generally-accepted modern option. There also exists Argon2, a new algorithm designed specifically for password hashing, and the winner of a three-year competition to determine the best such algorithm, if you want to be cutting-edge.
  • You don't mention per-user salts; are you using them? Salting passwords is absolutely essential, otherwise an attacker can just generate a rainbow table for whatever hashing scheme you use. Per-user salts break this attack, and also mean that (under normal situations) even if two users choose the same password, you can't tell that they did just by looking at the database; their hashes are different. All the good password hashing schemes take a salt. Salts should be randomly generated and are usually at least 16 bytes (128 bits) long.

At this point, I really have to say: you should use an authentication system written by somebody who is familiar with such systems, and who has a well-tested version ready to use. Don't try to write such security-critical features until you understand the area better.

  • 2
    "because for some reason your password hash function always produces the same output." Not nececarilly. We have no idea where in the application the bug might be. The application could just as well be bug free, just that the DBA forgot to set an WHERE clause to her UPDATE query yesterday. There are a million different explanations for this and we cant really know what has gone wrong here. – Anders Nov 4 '17 at 10:35
  • 1
    seems like i fucked up quite well – Hagge15 Nov 4 '17 at 20:35

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