Is hashing a string a secure manner for generating passwords?

Question

I have several servers that I'm using for an online business. I have passwords for MySQL, Wordpress, SSH, FTP, Domain Provider, Paypal, and many more. I wanted to have a different, very long password for each service to minimize the possibility of brute forcing and of accessing my other servers in the event that one of the services experiences a security breach.

In order to accomplish this, I decided to hash the service name using SHA256.

So I would hash "Wordpress+MasterPassword" a fixed number of times and get the password that I would use for that service.

Is this a secure way of having different passwords for every service?

Answer 1

First things first, you should use a password manager to solve the problem that you're trying to solve. A 256-bit hash like SHA-256 outputs to 32 bytes of hexadecimal characters. This means that for every character, there are 16 possible choices, 0-9 and a-f. Using a password manager like KeePass, you can generate a 32-digit passphrase using 64 or more possible characters per digit, which makes brute forcing harder.

Offline password managers like KeePass use a single strong passphrase of your choosing to encrypt a database of as many passwords as you like, so those passwords can be as complex as you'd possibly want. You should definitely do that rather than rolling your own methods of generating passwords. Rotating passwords becomes easier as well.

Now comes the cryptography to answer the general question implied by the title.

No, you should absolutely not do your own hashing of passwords.

There is an entire class of cryptographic algorithms called "key stretching functions" or key strengthening functions or password-based key derivation functions which are designed specifically for taking a key and generating a secure one-way hash which is resilient to the kind of attacks you care about. Use Scrypt if it's possible, Bcrypt if Scrypt isn't possible, and PBKDF2 if neither Bcrypt nor Scrypt are possible. There are libraries for these key stretching functions in your language of choice.

A hash function is a cryptographic primitive. There are a few applications for using SHA-1 or SHA-256 directly, but deriving passwords is best handled by key derivation functions. A good use case for a cryptographic hash function as a primitive is for generating checksums of files. Hashes were designed for exactly this use case: verification without authentication.

Cryptographic hash functions were not designed to resist the kind of attacks that key stretching functions are supposed to stand up against. Programs like oclHashcat can compute anywhere in the range of 1 billion SHA-256 hashes per second on fairly inexpensive hardware. Key-derivation functions like Scrypt and Bcrypt were designed to be attacked and to slow down attackers so that they can generate, say, one password per second on a CPU core. Scrypt was designed to be flexible to prevent the GPU attacks that oclHastcat leverages against these algorithms.

As many key stretching functions use either a hash for the input or for the output, the question is raised: what does a key stretching function give me that a hash does not? Doesn't the attacker still need to sweep the whole key space, as in 2²⁵⁶ in SHA-256's case? The answer to that is decidedly no and here's why: hashing (and even salting!) a user-entered password isn't going to distribute well over 2²⁵⁶ choices. Since computing SHA-256 is so cheap, computationally speaking, I can just brute force and start with 'a', then 'b', etc. at billions of times per second. Alternatively, I can use a good word list like the RockYou list, and oclHashcat will try these out for me and even append random salts to them; all this is done billions of times per second, so it's not that hard. A key stretching function on the other hand, should fairly evenly distribute the key over the entire key space (ie 2²⁵⁶ choices, more than the amount of particles in the known universe), making every password search more or less exhaustive if the function is a good one. Do remember that if you took a 1PB (petabyte, 1000/1024 terabytes) file, generated a SHA-256 sum of it, then flipped a single bit at some random place in the file, your second SHA-256 sum would be completely different and would be entirely unrelated to the first checksum.

If the key stretching function is well enough implemented, the attacker will be forced to use their brute force attacks or their wordlists (or both) on the key stretching function itself, which is designed to be slow. This means that they're left without options and forced to wait beyond the lifetime of the universe ;)

TL;DR: Store your passwords in an offline password database like KeePass, and if you're trying to derive passwords, use a key-derivation function. That's what both of these things are designed for.

In order of priority, use one of the following offline password databases:

1. KeePass (best compatibility across operating systems)
2. Password Safe (no Linux)

In order of priority, use one of the following KDFs:

1. scrypt
2. Bcrypt
3. PBKDF2

Answer 2

My question to you is: What's the advantage?

Even before any analysis at crypto level, your system falls down in the event of any breach.

Say your WordPress system was hacked - you would want to change the password for this system to be on the safe side.

So sha-256(Wordpress+MasterPassword) becomes sha-256(Wordpress+NewMasterPassword).

This means you now have to update the passwords for

• MySQL
• SSH
• FTP
• Domain Provider
• Paypal
• many more

"Many more" could possibly include hundreds of unrelated systems.

Now, imagine a cracker knows this is what you're doing. Kerckhoffs's principle states that

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

So you have your key, which is unknown to the attacker. If an attacker manages to get at the hashed values on the back-end of one of the systems you use, they would simply run their password guess list through the same method that you used to generate it. i.e.

sha-256(Wordpress+Guess)

Note that any salt is not considered private, otherwise it is really part of your key (and back round again to Kerckhoffs's principle).

If the attacker tries each hashed password guess generated as above, hashes it with the salt and algorithm used in the breached system, and then gets a match they have then found your password on that system. She can then simply derive the password from your other systems now the master password is known.

Since pure SHA-256 is used, and not a slow hashing algorithm such as PBKDF2, the hashing of the guesses would run relatively quickly, although the actual speed of the attack will per site will depend on the password storage algorithm that particular site used. Therefore you are as secure as the weakest algorithm in any breached site.

Using PBKDF2 would solve the hashing speed issue for the list to make it slow, but it still leaves the issue of updating every password for each single breach to match any new master password.

Solution: Use a password manager to protect all your passwords using a master key to unlock an encrypted database. See here for why this is a better solution.

Answer 3

I wouldn't do what you are suggesting. It's too easy to guess the Website info ("Wordpress" in your example) and the salt is presumably public. You would do better hashing MasterPassword+Website where MasterPassword is a well-chosen, secure, random string. You can use the same master password for all of your sites. Even if the password for a site gets exposed, the attacker will not be able to calculate your master password.

Answer 4

No, hashing a password does not increase your security.

The security of your password is based on its randomness and length. Hash functions generate a "representation" of a given value in a specific format. The result might look random, but it is following a set of rules, the exact opposite in of randomness. This means that such a password is easier to analyze and therefore bruteforce.

Adding a specific string in a password is also very deterministic. Breaking cryptography often results in reduced cracking times. If an attacker cracks one of your passwords, next ones will be easier, as he knows that you use the same string every time. This would make further attacks quicker.

Using a password manager with random string generator built-in is the best way to keep your passwords safe.

Answer 5

Although a lot of the answers here say to not use SHA256 as a password generating function, they all seem to mention speed as the primary reason. It's too fast. And since it's too fast, brute force search becomes feasible.

What they don't say, however, is that you can apply SHA256 as many times as you'd like in a loop on the input. i.e.

sha256sum(sha256sum(sha256sum.....(salt + master password)))...

This would make it as slow as the other algorithms.

I don't see why this is worse than using some of those other algorithms being suggested. SHA256 is also a very basic function available on all systems, and it's been proven to be an effective one way function.

Answer 6

It seems just as safe as any other scheme, however since your using the service url as a starting point you have a possible easy to guess password (part of it is now public knowledge).

Now if you would use a different word you can use this trick to get your salting from the name (factorise the ascii values of the name for example). and hash the key word n times with sha256.(as the salt was in your original and n from your original question.

That way no secret is public. (a salt should not be considered secret or a password) and your at least as safe as the hashing beeing used to store your password with ;)

Answer 7

You would be limiting yourself to the range of keys the hash may output, which is likely less than you would generate using a password manager.

SHA-256 has a range of 0-9 and A-F with only 64 bytes of output, turning

pXieG)MF8YRI`{H+/wCw(i/uE*ja#MFl^OQZq=oj!@R6miK_E#RffzZ9C^9}F~KYN;H>{W{7"$x.,7cK4T&9czC4Sv=.uw5\g{fD

into

43ed7e8394763351f0f6be1f91d3affad785da03384cab942f5cc48c544230c6

The original password is substantial, so hashing it and using the hash as a password only serves to reduce its entropy.

As recommended above, using Keepass or another password manager that suits you would be much more preferential. I personally use Keepass, and I find comfort in knowing my password is over 100 chars and uses an astounding range of keys I couldn't possibly type manually with any level of speed.

If I misunderstood your question, just let me know! :)