1

Being interested in security, hashing in particular, I thought of a strategy that could either help or compromise password security.

The main way to ‘break’ hashes is to brute force them.

So, while sometimes it is hard to tell, most of the time you can guess or at least shortlist a few different hash algorithms your hash might be, and try the most likely first.

This is my idea: A hash, let’s say MD5, is produced, and then, for example, 100 random characters are added to the start or end, and then this new string is stored in the database.

This might make it almost impossible to guess what type of hash it is, if the database got breached.

Now you might argue that this is essentially just a much weaker way of encryption- but here’s the catch- the amount of characters added is different for each user!

User A gets 98 added, but User B gets 82 added!

This relies on two things, however, the hashing algorithm is kept secret, and the adding is done client-side that gets backed up to another separate server.

Can some expert tell me if this is a great idea or a bad one!

If it is bad- please provide some reasoning- and remember, please do not judge me if I have missed a massive flaw- I am no expert- just an application and database coder and security enthusiast.

12
  • 3
    If adding the random characters is done client-side, how is this random information distributed to all clients? If someone tries to use a public kiosk, how would it know the user's random information?
    – Barmar
    Commented May 15 at 14:30
  • 19
    The answer to “Is this idea for password storage or encryption that I just made up a good one?” is “No, use industry standard password hashing or encryption, it was developed by experts”. Never roll your own.
    – Josh
    Commented May 15 at 16:02
  • 14
    "A hash, let’s say MD5" - I know it was just an example, but I'm going to mention it anyway: never use a plain hash for password storage. Use a slow iterated password hash with salt. Good dedicated password hashing algorithms include (from better to worse): argon2, scrypt, bcrypt, PBKDF2. And avoid MD5 (and SHA1) for anything.
    – marcelm
    Commented May 15 at 17:16
  • 2
    Obscurity is not security.
    – user207421
    Commented May 15 at 23:09
  • 5
    So, obvious question - if you're adding some random content to the pre-hashed password, how do you reconstruct that random element in order to verify the password was correct? If the answer is that you store the random content in the database alongside the hashed password, then you've basically just re-invented salting... Commented May 16 at 5:27

4 Answers 4

59

You recently asked about "security by obscurity". This is that. A very complicated process that fails once it is known.

And if the database of hashes gets leaked, from one server, why do you trust that the other database isn't? This adds very little benefit over the established process of using a strong hashing algorithm (not MD5) with a salt.

The other problem is that you are hashing the password client-side, which means the hash becomes the password. Once the database is leaked, you don't need to break the hash, you just pass that hash to the server. You don't need to know what the original plaintext password was. So all this complication is meaningless.

Please look up "security by obscurity", Kerckhoffs Principle (which was mentioned in your other question), and client-side password hashing.

7
  • Thanks for pointing out those flaws. Yes- it seems that this just makes more problems than it actually solves! Commented May 15 at 7:07
  • 3
    You may want to extend the answer: "the hashing algorithm is kept secret" - this is the violation of Kerckhoffs Principle.
    – mentallurg
    Commented May 15 at 8:03
  • 1
    @mentallurg I'm going with the broader application. It's not just the algorithm type that is trying to be kept secret in the OP's design. Wider applications of Kerckhoffs' suggests that the entire design should survive being known and this design holds a lot of secrets.
    – schroeder
    Commented May 15 at 8:09
  • Hashing server side is standard practice and they didn't specify that there would be no server side hash before storage. Client side hashing does not rule out server side hashing.
    – n-l-i
    Commented May 16 at 6:42
  • 3
    @JamesT Sometimes the status quo is there because of inertia, convenience, or other reasons related to practicality rather than technical optimality. There's no harm in asking, you might get an answer like "That might be theoretically better, but here's why it's not feasible."
    – Barmar
    Commented May 16 at 15:00
20

Leaving aside some of the technical implementation issues (how you're generating the "random" characters, how your servers communicate to work out how many they need to strip off each side, etc), this is a direct violation of Kerchoff's Principle, which states that:

A cryptosystem should be secure, even if everything about the system, except the key, is public knowledge.

And it means that if an attacker ever gets access to your source code, then suddenly most of this extra security is gone.

It would also be relatively easy for an attacker to determine the scheme, all they need is the padded hash of a single account that they already know the password for, and they're quickly spot that it contains md5($password) and then has some extra padding. It would make it a little harder to crack as them as they don't know the position of the real hash, but still orders of magnitude easier than cracking a proper password storage algorithm like bcrypt or Argon2id.

If you want to prevent an attacker to cracking hashes with only database access then you can use a technique like peppering or encrypting the password hashes in the database.

But if you're using an algorithm like Argon2id with sensible parameters, the hashes are already very hard to crack - so you're much better off doing something like that than trying to build your own password storage systems around a weak hashing algorithm like MD5.

As a general rule of thumb, any time you're thinking about doing custom cryptography it's probably a bad idea, because cryptography is really really hard to get right.

0
4

If you are doing the hashing and padding on the client side then how can you keep your algorithm secret. Considering you try to obfuscate your code, still it can be de-obfuscated easily by someone who is really motivated. So it's a fail here on this point.

7
  • Thanks @schroeder for pointing out. I now understand what the question is. I will still stick with my 2nd point which is that as an attacker i have both the hashing algorithm and the padding algorithm in my hands (it might be obfuscated but it is there somewhere on client side), which reduces my work of breaking the db and figuring out the hash. Now as an attacker, i simply need to observe the pattern and find out the pad positions. Once its done I can simply perform a brute force attack as usual and try to login as someone else.
    – und3rh00ds
    Commented May 16 at 10:16
  • Also its highly unclear about the methods the server will use for validating the hash, I am assuming both servers will communicate among themselves and retrieve the padding using some common id. I am assuming the server will generate the id and store the padding with id on separate server, correct me if i am wrong.
    – und3rh00ds
    Commented May 16 at 10:20
  • This assumes the attacker has access to the client. From the comments, and the design, I don't think the OP had the threat model of an attacker having the client as well as the server.
    – schroeder
    Commented May 16 at 10:47
  • What i am trying to say is the attacker can itself pose as client and test out the application by trying different passwords and figuring out the pattern, which doesn't require access to client by becoming client himself.
    – und3rh00ds
    Commented May 16 at 10:56
  • ... how does someone "pose as a client" or "becoming client himself" without first having access to a client or gaining access to a client? Your comment makes no sense.
    – schroeder
    Commented May 16 at 11:12
2

the amount of characters added is different for each user!

[...]

This relies on two things, however, the hashing algorithm is kept secret,

That's all anyone needs to know to see that this is a bad idea.

You're building a custom method that relies on parts of the method being secret. And you just posted about it on stackoverflow.

Security works with secrets sometimes, but the secrets are never in the method, because we want the method to be examined by as many people as possible so someone smarter than us can find the issues that we didn't see.

4
  • thanks for the answer but please also remember I am no security expert, and as many of others have pointed out, this is a bad idea, and this was also just an example- I will not be actually implementing it into one of my web apps. But thanks again for the answer and yes- one should never reveal their obscurities. Commented May 17 at 9:59
  • One should never have obscure security components in the first place.
    – Ja1024
    Commented May 17 at 16:27
  • @security_paranoid I pointed out that you just posted it not to shame you, but to show you the contradiction in your own statements - you realise that a security idea should be checked by many others, but want to keep a security idea secret. You can't have both.
    – Tom
    Commented May 18 at 8:10
  • @Tom I was never annoyed or anything- I really liked your answer- and you are 100% percent right! Commented May 18 at 9:02

You must log in to answer this question.

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