# Can you use a hash as a password?

There are several methods of making a strong password, making it longer is one of them. now we also have hashing algorithms which have outputs of 512, so i wonder, would it be safe to basiclly use a simple password like dog, and then use the for example 512 bit hash output as the password.

EDIT: out off all the answers i think i thought out something that would be secure so consider the following: if i write a program which hashes a word with a number that comes out of a cryptographiclly secure pseudorandom number generator(having a minimum of 5 hashes, and then use the out put as a password, for example: i use the word dog as word, then number generator provides me with a random number of 5 or higher which defines how many times it needs to be hashed. in this case, we got the numer 30 for example, then we hash the word dog 30 times with a secure hash function. then this would be a secure password against dictornary attacks right? because if they dont know how many times you hashed it, then trying a dictornary attack should become a much harder task to achieve, and for brute force: trying to crack a 512 bit password with letters and numbers should be madness, and if you use a salt along side of it, it should become really secure. so if someone is able to write something like this, and combine it with a secure and encrypted password vault, then it should be a pretty powerfull tool for password creation and management. so this is basically the idea, feel free to point out things i missed or possible weaknesses :)

• "Safe" against whom? More generally, how do you define "safe"? Most likely, this should be on Security.SE. Commented Jun 5, 2016 at 19:42
• Well, you're screwed in this scenario as soon as the attacker finds out you're using hashes as passwords (+ algorithms + encoding)... Commented Jun 5, 2016 at 19:43
• well as far as i know, its supposed to be impossible to find out the input by just knowing the output of a secure hash, so even if they know which hash algorithm i use, they still don't know what my input was, plus the problem may also be solved by using a salt in someway, but then again, im no expert and i want to learn :) Commented Jun 5, 2016 at 19:50
• It's too easy to build tables of all hash inputs smaller then a certain threshold. Attackers don't attempt to invert the hashes given the output, they simply generate all the hashes for short inputs ahead of time. Reversing a hash can be done in (effectively) constant time if the table is small enough to be stored and accessed. Commented Jun 5, 2016 at 19:56
• After your edit (which changes the question a lot BTW, so you should really accept the best answer here and start a new question): If you use a cryptographically secure RNG, all the manipulations afterwards do essentially nothing useful. Just use the crypto RNG output directly, perhaps mapped to a suitable character set that can be entered into the system needing a password. Commented Jun 6, 2016 at 8:30

It's a good point, because in the first instance:

dog

Is less secure than their SHA-512 hash used like a password:

Using brute-force in this case is madness, so the best option to crack it is a dictionary attack... only if the attacker knows that you are using a hash like password.

OK, lets use a strong password and hash it:

MyD0g1sBEAUTI_FUL

We got this:

7ccd45a479d20ae695e33dd153382a6868258728532203cb371ab9f3a7efc57b796fb88f816326de5ff6ae5fcb9de74ef022ebba22ffa571b5b4a8ec5fb19811

Dictionary attack goes harder to accomplish, but you are using the same length, the same number of characters / numbers ...

Lets try to use a hash of a hash like password. The previous one get this rehash:

Unless the attacker knows that you are doing 2 or more rehashing, dictionary attack is useless. But brute-force goes the same: still the same lenght, number of characters used and so on.

• so in some way, it can be very secure, but you need to hash it multiple times (without mentioning how many times) and use a password which is not likely to be in a dictornary attack? Commented Jun 6, 2016 at 7:36
• If I know that your password is easy as "dog" or "tree" or whatever and you are using a hash of this, I will use a simple dictionary attack with a hashing function in the middle. Too easy. Take a look of this: en.wikipedia.org/wiki/PBKDF2 You take a password and rehash it many many times to take a derivated key. Its almost the same. Commented Jun 6, 2016 at 7:51
• what about this: if i write a program which hashes a word with a number that comes out of a cryptographiclly secure pseudorandom number generator(having a minimum of 5 hashes, and then use the out put as a password, for example: i use the word dog as word, then number generator provides me with a random number of 5 or higher which defines how many times it needs to be hashed. in this case, we got the numer 30 for example, then we hash the word dog 30 times with a secure hash function. then this would be a secure password against dictornary attacks right? Commented Jun 6, 2016 at 8:01
• if the program always gives a random number of hashes, and you prevent that other people know how many times it is hashed, then they should be unable to practically perform an effective dictionary attack, which is also secure against brute force for years to come, since its 512 bits long, and hash random numbers and letters. (well thats the idea , feel free to correct me if i am wrong) Commented Jun 6, 2016 at 8:04
• how does your program know how many times to hash input if the round #s are non-deterministic? Commented Aug 11, 2016 at 20:49

I'd say the key thing that you need to spell out to answer this question is this:

• What information does the attacker have?

This ties to one of the basic concepts of cryptography, called Kerckhoffs's principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." (I recommend you read that page and take its lessons to heart, along with the security through obscurity entry as well.)

So if we apply Kerckhoffs's principle to your proposal, we would assume that:

• The attacker knows that your password is the hash of some secret word that you choose, but not which word;
• The attacker knows which hash function you used to hash this word, and how to compute this hash function.

Then we trivially conclude that this isn't any safer than just using the word as the password. And since "dog" is a very common word in the English language, it's an obvious one for an automated attacker to try.

I'd say that in your question you are doing something that most laypersons do when they propose password rules or schemes like this one: you're assuming that the attacker won't know or guess the rule you're using to generate your password. But:

• You just told your idea to the whole Internet.
• Even if you hadn't, there's a good chance that an attacker might think of the same idea.

So really, the best passwords are random passwords, because there's no rule that an attacker can use to predict them.

EDIT: Funnily enough, a few days before this question, Duo Labs published a security analysis of OEM PC software updaters (press release; PDF report), that contains this gem (p. 16):

Unfortunately, the encryption utilized is RC4 with the pre-shared key “e8fded24af79202d7da48adefe4a3a04”, which is the MD5 hash for “Asus Live Update.” As this layer of encryption boils down to simple obfuscation that can be dealt with on the fly, it provides no security value.

This is almost perfectly analogous to the question's proposal:

• Pick a secret passphrase ("Asus Live Update");
• Hash it with a standard hash function;
• Use the resulting hash value as an encryption key.

And yet the researchers, just from seeing the hashed value, managed to guess the passphrase and the hash function used to obfuscate it. So there we have it, a documented real-life failure of the strategy.

A password has low entropy. Assuming that you hash in order to reduce the winning probabilities of someone trying to guess it, you do not do a lot better. The adversary will simple try all the possible combinations, evaluate the hash and check equivalence as long as he has acquired the server with the saved hashed passwords

You are relying on security through obscurity so I would say it's not secure to use such algorithm.

Moreover, you posted a question on how secure it is so it has become automatically a bad practice: you can't be 100% sure your idea has been included in some cracking tool

So what if you hash a simple word (dog for example) and then you chose both the length of the password and where woud it start in the length of your hash. Even if you know the method you have to know both the word used and the numbers (starting letter and length) chosen which are both almost arbitrary. Maybe you could make an estimation of the length(since password lengths are quite standard) but i think it would be pretty damn hard to guess while the user just has to remember a word and two numbers.