# 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. – fkraiem Jun 5 '16 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)... – SEJPM Jun 5 '16 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 :) – blacklight Jun 5 '16 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. – Ella Rose Jun 5 '16 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. – Neil Slater Jun 6 '16 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? – blacklight Jun 6 '16 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. – Rodrigo Calvo Jun 6 '16 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? – blacklight Jun 6 '16 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) – blacklight Jun 6 '16 at 8:04
• how does your program know how many times to hash input if the round #s are non-deterministic? – dandavis Aug 11 '16 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

First I would say, using a 512 bit hash output seems to be a really strong password. Like in the other answers mentioned, it is extreme madness trying to bruteforce this hash. But I would recommend to use a random password or a hash generated password out of a strong random function like a "Globally Unique Identifier", the output of such a function looks something like this:

936DA01F-9ABD-4D9D-80C7-02AF85C822A8


There are 0-9 and A-F (hex) used as letters. So there are 16^32 possible output strings. You can now use your hashing function with one (or more) rounds and use the output hash as your password. I think this would produce stronger passwords then using "real" words with salts and mutliple hashing rounds.

• well this was what i wasthinking: with quatum computing coming closer everyday, the need for longer and stronger passwords grows too, but for normal people these can be very hard to remember, so i thought, if i could just use a normal password, and then use a long and secure hash as a password. – blacklight Jun 6 '16 at 20:08
• I fully support your thoughts, but I would mention that your password creation logic can be stolen too and with this knowledge the attacker does not need to bruteforce the hashes but can bruteforce your logic to generate the hashes. This was mentioned already in other answers and comments, but I think this is a really importent point. You should specify threat model for your application to define against which intrusions your solution should be steeled and if it would be possible to steel or reverse engineer your code. – John Doe Jun 6 '16 at 20:13
• about the logic, that why i thought of random number generator, because the number of times a ash is then hashed again diffrinates, and say if you have like a 1000 iterirations, then ever possible password that you try out with a brute force, should also be hashed a 1000 times so that would (i think)lead to a big grow in how much computing power you need for an effective brute force or dictionary attack – blacklight Jun 6 '16 at 20:49
• Not all UUIDs are random. Only Type 4 is random, with 122 bits, which is plenty enough on its own already. Other types of UUID have massively less entropy than that—they're based off deterministic names or timestamp + MAC address. So hashing an UUID won't make it any more secure—in fact, some of the UUID schemes are already hashing their inputs! – Luis Casillas Jun 6 '16 at 22:40

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.