Hashing a password before using for online accounts

Question

I don't actually know what I'm talking about, so apologies if I get anything wrong. At the moment I have a password naming system for most of my online accounts that looks something like this: masterpassword + appname, where appname is the name of whatever service the password is for. ex. $sickpass123$_SoundCloud and $sickpass123$_Gmail. The idea is to have an easy to remember master password combined with the app name so every password is unique. I am worried though, because if a proactive individual manages to figure out one of my passwords, it would be easy for them to figure out the other passwords since they all contain the same master password.

I thought of running each password through a hash function (every time need to enter it) as this would ensure that each password is unique. ex. 8d9f24e142b33c2f7f3d59fc7c6043a7 and 84e08387ef918182154713d388f5ea62. In addition, I could encode the hash output in base64 or ascii85 to fulfill the capital letter/number/symbol requirements for passwords in online services. ex. OGQ5ZjI0ZTE0MmIzM2MyZjdmM2Q1OWZjN2M2MDQzYTc= and ODRlMDgzODdlZjkxODE4MjE1NDcxM2QzODhmNWVhNjI=.

I am also aware of password generators, but they generate a random string each time rather than a predictable output. I would rather have the same output be generated every time I enter my password. That way, it will be easy to remember every password, but the hash function will make each one virtually unique. Also, if only the hash output is given to websites, rather than the original password, the sites themselves will not know my pattern.

1. Is there any problems from using the approach I am suggesting? Would it actually be less secure if the server encrypted my already encrypted password?
2. Should I encode the output in base64 or ascii85, or something similar?
3. Which algorithm would be best suited to this task? Do I need something more secure like SHA-1 or will the more primal MD5 be adequate (would anyone care enough to try to break the hash)?

EDIT: Thanks for all the answers. They were all very informative. I think I might try a password manager, perhaps MasterPasswordApp as @Matty suggested, as it'll be easier to manage.

Answer 1

Is there any problems from using the approach I am suggesting?

Yes, there are several.

First of all, some sites generate first time passwords, or even long time passwords. You may want to store those too. What if a site requires frequent updates?

If one password is reversed, you'd still loose confidentiality.

Would it actually be less secure if the server encrypted my already encrypted password?

No, usually not. If you don't know the server's key then using encrypted input will not change encryption. Same goes for password hashing basically. If you don't operate with the same parameters (e.g. salt), then you are unlikely to be vulnerable.

Should I encode the output in base64 or ascii85, or something similar?

Anything the target site accepts. This points to another issue since the sites may require passwords in a specific format. Both the alphabet (character input) of the password and the size may be restricted. So some sites would be better off with base64, some with base 85 and others with neither of the above. E.g. an 8 character base 64 string only has 48 bits of security, allowing brute force attacks. How are you going to remember which format is best for specific sites?

Which algorithm would be best suited to this task? Do I need something more secure like SHA-1 or will the more primal MD5 be adequate (would anyone care enough to try to break the hash)?

When constructing security protocols you'd have to assume that somebody "cares". Otherwise you might as well skip the whole thing. That said: no, SHA-1 or MD-5 will likely not influence the choice much.

---

That all said and despite all the indicated issues, hashing the password is still somewhat more secure than providing a password with extension directly. But since you would need to have a device & application for this anyway, I'd recommend using a password manager instead (that e.g. applies a password hash or PBKDF over the master password to decrypt the database).

Answer 2

There are several different scenarios to consider. If you assume all the sites/apps do things right, use a strong password hash, stay uncompromised, then no one should be able to find your master password anyway (unless it is a very poor low entropy password). So how or whether it is combined at all does not matter.

More likely, you are interested in protecting your passwords if something goes wrong. A couple of possible ways that could happen:

1. A service uses poor hashing practices, like just a single iteration of MD5 or SHA-256, and its password database leaks.

2. A service has its plaintext passwords captured e.g. by an attacker compromising the site and modifying the code, or due to a memory leak like the Heartbleed vulnerability caused.

In either of those cases you are relying on secrecy of your algorithm rather than its strength, unless your master password has enough entropy (e.g. >80 bits) to resist brute force and dictionary attacks. That is unlikely with a normal password, but if you only need to remember one you could generate a strong enough password (or passphrase).

If you wanted to keep a weaker password secure even if an attacker found/guessed your algorithm, you would need to use a stronger password hash. For example, scrypt. If you can assume the password is very strong then MD5, SHA-1, SHA-2 etc. are all about equally good – because none of them lack preimage resistance.

---

Now, to directly answer your questions:

1. Is there any problems from using the approach I am suggesting? Would it actually be less secure if the server encrypted my already encrypted password?

Encryption is really the wrong term, but it is fine to hash it twice.

2. Should I encode the output in base64 or ascii85, or something similar?

The encoding does not matter for security, so you should choose it for convenience and compatibility. In practice some services may disallow certain characters, require certain characters or require a certain length.

3. Which algorithm would be best suited to this task? Do I need something more secure like SHA-1 or will the more primal MD5 be adequate (would anyone care enough to try to break the hash)?

SHA-1 is no more secure in this use case than MD5. Like I explained above, the choice is between a fast cryptographic hash like those two and a slow password hash.

Whether anyone would care is a judgement call you will have to make. It probably depends on the services you would use, like banking vs. Stack Exchange.

Answer 3

The approach you describe is very much like the approach that is used in the masterpassword app (http://masterpasswordapp.com/).

Roughly they generate a password for each site depending on:

• Your master password
• The site name
• A number (so that if you have to change your password you can just increase the number)
• Some salts that they decice.

And then they provide several formats in which to present the password, so that almost all sites will except one form or another.

As hash function they use a combination of SCrypt and SHA-256 (see also this question).

There are two downsides to this that I can see:

1. You still have to find a way to remember your username for each site, as it stores nothing (you also have to remember the number and the site's name, but that should be doable).
2. If you need to reset your master password, you have to reset ALL passwords.

Still, it's a good way to manage your passwords, as you don't have to rely on any 3rd party whatsoever (it's completely stateless), and there's pretty much nothing to backup (except maybe if you store the usernames and numbers elsewhere, but that is not critical information).

Answer 4

@Jeroba88 your idea of using a hash function rather than just appending the service name to your secret password is simple yet crucial to achieve what you have set off to do. Some level of customisation (be careful), such as using PBKDF2 (or Scrypt) in place of just a plain HASH(Password|Service) (especially since it's probably preferable to use HMAC(Password,Service) to protect against Length Extension Attack in principle.

Finally all points made by Otus about encoding being arbitary totally stand up in practice. You may be interested to see, I've made an open source program working on the very principle, you seem to layout here: at the center of it is SHA-2 and a second hash function designed to run slower, to prevent easily brute force attacks. For an outline how this is done, see PBKDF2. I can link my code later if that takes your interest and is permissible.