Can you use a hash as a password?

Question

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 :)

Answer 1

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

dog

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

3bbed9c106ceaea9e1d1f851b493a52582ae6f6deab8170da43da346a8710622b21d6c2ca14c6336bdc770f161673bef5edad6e65d86b05be62817bc9088d924

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:

1f887bb06dc585279958dc968c9873d3ddd73b6a9a98d8bee9a6ca909d25545f1d1e42f63a40827375ad6632f72ac0285e28ce89c601fb385d127a83f57ce1e1

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.

But remember: dont tell anyone your tricks to make your passwords. And always use SALTS!!!

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.