Is it safe to publish the hash of my passwords?

Question

How unsafe would be to publish the hash of my passwords?

I have written a Python script for helping me to remember my basic passwords (computer password, encrypted backup password, AppleID password, and KeyChain password).

It is hardcoded inside this:

SHA256(MD5(password) + password + MD5(password))

for each password and I periodically run it to keep my memory fresh.

I have a private repo on GitLab where I store all generic files and I would like to commit this script. I can't see any problem doing this since, as far as I know, it would be impossible to recover the original password, but I prefer to ask experts, to be sure.

EDIT: I'm adding an anonymized version of my script, so you can understand how it works:

from hashlib import md5, sha256
from getpass import getpass
from random import choice

def hash(pwd):
    pwd = pwd.encode()
    return sha256((md5(pwd).hexdigest()+str(pwd)+md5(pwd).hexdigest()).encode()).hexdigest()


dict = {'pass1': '6eaa49070c467d1edead2f6bc54cf42cdda11ae60d40aef2624a725871d3f452',
        'pass2': '240cbc4ba2661b333f9ad9ebec5969ca0b5cf7962a2f18a45c083acfd85dd062',
        'pass3': 'b018ed7bff94dbb0ed23e266a3c6ca9d1a1739737db49ec48ea1980b9db0ad46',
        'pass3': '7dd3a494aa6d5aa0759fc8ea0cd91711551c3e8d5fb5431a29cfce26ca4a2682'
       }

while True:
    tipologia, hash_result = choice(list(dict.items()))
    while True:
        pwd = getpass(f'Password {tipologia}: ')
        if hash(pwd) == hash_result:
            print('Correct!')
            break
        else:
            print('Wrong!')

Answer 1

MD5 and SHA256 were both designed to be as fast as possible. Their purpose was to compute a hash for relatively big data volumes, e.g. for files. That's why they are very fast, which makes brute-forcing easier.

A single GPU can generate ~10^10 SHA256 hashes per second. It is ~10^15 per day. Computing of MD5 is much faster, on some GPUs ~5 times faster. So let's ignore MD5 part of your algorithm and consider SHA256 only.

Suppose you have a password that consists of 10 alphanumeric characters, i.e. from a 62-character set. The number of different passwords is 62^10 ~= 10^18. It means, to brute-force such password an attacker would need 10^18 / 10^15 = 1000 days with single GPU, or 100 days with 10 GPUs, or 10 days with 100 GPUs. Thus, an attacker that can afford 10 GPUs, will break such password in 100 days.

If you use 16-character passwords, i.e. 6 character longer, then required computing power need to be 62^6 = 5*10^10 higher.

Thus, the security depends essentially on how long your passwords are.

Another important factor is the costs of brute-forcing and possible benefits for an attacker. For instance, if brute-forcing your passwords will cost an attacker 900 000 USD, and knowing your password gives the attacker benefit of 1 000 000 USD, then in total this will give 100 000 USD benefit, and brute-forcing makes sense. But if password gives only access to a bank account with let say 10 000 USD, then an attacker will lose 890 000 USD. In such case brute-forcing makes no sense for the attacker. Only you can decide if somebody will be interested in paying much money for computing power needed to brute-force your passwords.

And it makes sense to use hashing algorithms that are designed to be slow, e.g. Argon2 or Lyra2. They have tunable parameters. Use values such that a single hash takes 0.1 - 1s. Thus you can essentially slow brute-forcing down and reduce the risks even more.

Answer 2

There are a couple problems with this approach.

First of all, you're using two plain cryptographic hash functions to hash your data. By themselves, cryptographic hash functions are designed to be fast. That means that it's extremely easy for an attacker to try to brute-force your password. The only time it's safe to use a plain cryptographic hash function to hash a secret is when that secret is a sufficiently long output of a CSPRNG (i.e., it has at least 128 bits of entropy). In order to even store this password securely on a system, you should be using a password hashing function like one of the crypt functions on your system, scrypt, or Argon2, which are designed to be iterated and expensive to prevent brute forcing.

Second, you have no salt for this password. As a result, anyone can just hash the output of a large password list as found in any of a number of breaches and create a giant table of passwords using this scheme. If you were using a secure password hashing system, it would require a reasonably long salt to randomize the password and prevent generation of so-called rainbow tables to make guessing a simple table lookup.

Third, you are using MD5, which should not be used for anything anymore. MD5 has been known to be totally insecure for 17 years, and there is no longer a justifiable reason to use it at all. Carnegie Mellon University says it is “unsuitable for further use,” and responsible parties do not use it.

Fourth, it is strongly preferable not to disclose the password hashes at all. Passwords are securely hashed both to make guessing expensive and make it harder to guess even if the hashes are exposed, but if a person somehow gets your hashed password and it's guessable, they'll be able to guess it with enough effort. Your password must therefore be reasonably secure and contain sufficient entropy that it is computationally infeasible to guess even if the hash is exposed. It also needs to not be reused, because if it's ever exposed elsewhere, then you have to assume the attacker knows it (because usually, they can find it) and it then becomes just another entry in an easy word list to guess.

Answer 3

There are all excellent answers. I will try to address immediate questions.

How unsafe would be to publish the hash of my passwords?

Very unsafe. Irrespective of the algo used, please never share the passwords or the hash of it on open web. Why:

1. This is a bad practice. A bad habit. You are encouraging yourself and others around you to lower your guard.
2. Crypto (and their hacks) are very intricate. Very few people in the world can conclusively say whether what you are doing is actually safe or not. BUT there is a whole bunch of people who will NOT say anything and silently smile and let you do the mistake and misguide people. These are not just hackers, these are also state actors and intelligence agencies who have real incentives to get the general population lower their guard on privacy. Your AppleID password may not mean much to anyone, but the tiny bit bad habit that got in the air is worth something for them.
3. What is safe (or innocent) now is probably not the same in future. Who knows where you will find yourself in 15 years. Internet never forgets. Your past might come haunting you. Or it might not - it could all continue to be innocent. Bhy take chance?

I have written a Python script for helping me to remember my basic passwords (computer password, encrypted backup password, AppleID password, and KeyChain password). It is hardcoded inside this: SHA256(MD5(password) + password + MD5(password))

Please never ever create Crypto algo of your own. Please see point #2 as why. Others have tried to answer the exact technical reason as to why this particular algo is flawed. It is better to remind your self that not just this one, but any algorithm that we came up ourselves - is flawed. In the world of crypto the safest path is the path well trodden. Without exception.

I have a private repo on GitLab where I store all generic files and I would like to commit this script.

Committing the code is fine, committing the hash is not.

I can't see any problem doing this since, as far as I know, it would be impossible to recover the original password, but I prefer to ask experts, to be sure.

Thanks for asking. :) impossible is a very strong word that no expert will use in its unbound sense. Even if companies like Google (for example) have their passwords tremendously hashed to the point of really-truely-unpossible to recover, still you do not see them publishing the hashes. Basically, please hold on to the "secret" stuff as if they really are secret. Hashing or frying does not decrease the sensitive nature of the data. Hashing is just one defence. Not an absolute one.

So, please

4. do not invent your own crypto algo.
5. do not hardcode hashes/passwords/keys in source code.
6. definitely do not commit/push then in source control.
7. do not publish the hashes.

Answer 4

Back in the day when airbags were an expensive option on expensive cars, I used to ride with a colleague who had a BMW-635 with an airbag. He believed he didn't need to wear his seatbelt because the airbag would save him. Nobody believes this any more. Both safety mechanisms are necessary, have complementary purposes

Passwords used to be stored in plain text. Then we started hashing them. Then hackers started building rainbow tables, so we started salting them. Now hackers are stealing password hash files and brute forcing them, so we stopped using MD5 and SHA1, and implemented 2048 rounds of hashing to slow down the brute force attacks. Too slowly, we are switching to slow hashing algorithms for passwords, to slow down brute force attacks even more

Still, hackers are stealing hash files, and still they are brute forcing. Ten to fifteen percent of passwords are guessable in 24 hours of brute force, because too few people understand "long and random". Elsewhere, I suggest 7-word Diceware passphrases, and nobody responds, not even with "please explain". Now, those 10%-15% of passwords were cracked from a hash file which was stolen or leaked from some insignificant member-only closed forum. But 30%-40% of those users have the same username and password on more important logins - gmail, applemail, msmail - and they use those email accounts for banking

The point is, don't be the guy who doesn't wear his seatbelt

Use long and random passwords, and never expose the hashes

Answer 5

Quick notes:

1. Typing your password more is bad.
   This scheme requires you to regularly type your password on internet-connected devices at times you didn't have to before. That opens up additional opportunities for a key-loggers, videos of you typing, a corrupted variant of your script, etc., to steal your password.

2. Fast hashes are easier to dictionary-attack.
   You're using fast hashes that could be easily dictionary-attacked. Other answers have explained why this is a bad thing.

3. Secrets shouldn't be used multiple times.
   SHA256(MD5(password) + password + MD5(password)) inserts your password 3 times, which is bad. Generally, never reference a secret (like password) more than once.

4. Consider blinding before calling an external function.
   You're passing your password into the MD5() and SHA256() functions plain-text-style. If either is backdoor'd, then they get your password. Consider blinding.

5. This increases opportunities for mistakes.
   This scheme doesn't save you from having to save your passwords somewhere, so it's adding another moving-part to your security strategy. That's generally not a good thing, as it enables more opportunities for blunders to derail your security.

6. This increases attack-surface-area.
   This scheme doesn't save you from having to save your passwords somewhere, so it's adding another moving-part to your security strategy. That's generally not a good thing, as it gives attackers more vectors to attack along.

7. This isn't playing to your strengths.
   Information-security is about asymmetric computational ability, in whatever form it might take. Here, you're using scripting with weak crypto in an online format that relies on other folks' software playing nice for you.. you're opening yourself up to all sorts of problems, apparently just to use old-fashion crypto methods. And why? Old-fashion crypto is notable for being what other people understand well, and apparently not you.

   If you're not a cryptographer, then security-through-obscurity for personal use may be the better way to go.. just writing stuff down on a piece of paper that you store somewhere weird. Because a lot of folks may know all sorts of gaps in the software, systems, and algorithms used, but a relatively small number of people want to search your home for the one place you may've cryptically written down your passwords on a random thing. And generally speaking, there's little overlap between the population of people on Earth who love math/algorithms enough to become cryptographers and the population of people on Earth who're willing to rummage through your dirty laundry to see if there's a sticky note at the bottom of the hamper. Because it's probably not in that exact spot, and, ew.

   Satoshi Nakamoto scribbled their private-key in a dirty porto-potty, right on the wall where everyone could see it (if rather messily). It's likely that a lot of people have seen it by now but simply not recognized it. Ya know, hypothetically.

Answer 6

Not only publishing hashes is unsafe, because this means that the attacker won't need to actually look for a security hole to acquire the hash and the attacker can start attacking the password immediately, but MD5 itself is known to be vulnerable for a long time. Not to mention the fact that sometimes capturing the hash is enough. Some attacks like PtH can exploit vulnerabilities in the authentication protocols and unauthorized person might be able to gain access even without actually cracking the password at all. So, publishing password hashes is terrible idea, even if they are relatively secure. If there is a security vulnerability, the attacker can provide the hash instead of the actual password and he still will be able to gain access.