Cross-Domain Password Protection

Post date: Jan 24, 2012 8:39:56 AM

I know it's terrible practice, but I only use 1 or 2 passwords to authenticate at a lot of different sites. Lately, I've been reading about a lot of phising attempts which involve setting up a seemingly new site and having people register to try it out, whose only purpose is to gather usernames and passwords, in the hopes that people use the same password for the site as their email account. I know I've been guilty of this a few times (although I usually try to cycle my passwords so that this doesn't happen). Well, I thought of a way that I (or anyone else) can still use just one "master" password to sign into different websites, but for each different website to see it as a different password (thus defeating the cross-domain login hole). It involves cryptographic hashing, so first I'll give a little background on that.

A cryptographic hash is simply a way to take a block of text (in this case, our password), and transform it in an irreversible way into a shorter, digested version. Simply hashing your password alone isn't enough to stop cross-domain phishing, though - since it would still be the same if you use the same hash for each site. An important property of good hash functions is that for any small change of the original text, the hashed version is, with overwhelming probability, totally different. In cryptography, this is called the avalanche criterion. This is important due to how we'll make our password different. In this case, we'll use the SHA-256 hashing algorithm to generate our hash, although we'll normally only use some of the resulting output (10 characters in the base64-encoded output).

So here it is: you simply take your master password, say "x", and then append the domain of the site you're using, say "google.com", to it - making your password "xgoogle.com". Now, this is where hashing becomes important - if you simply used the password "x<domain.com>" for every website, and a phishing site caught your password in plain text, it would be pretty easy to crack your code. So, instead, you use the hashed version of your password - in this case, "mypasswordgoogle.com" becomes "7djhEjEeld", where as "mypasswordamazon.com" becomes "pZFQNDQ9bx". Clearly, two very different resulting passwords for two different sites, with no obvious connection between them. (Even finding a hash collision against the hash (i.e. finding some text which results in the same output) isn't enough to guarantee that the original password was recovered!)

Now, you may be thinking that this is all well and good, but how are you going to hash the password every time you login? The solution is twofold: first, saving passwords in your browser will still work. Second, I've hosted a script which will automatically generate these in a secure manner (no password data ever transmitted to the server) at: Password Generator. So, any time you're connected to the internet and need to access a SHA-256 hash to figure out your password, you can simply go to that link. It's hosted using Google infrastructure, so it's availability should be pretty nearly 100%. And, if it's ever down for whatever reason, there are certainly other places which will offer you a SHA-256 hash of a string, although probably not in as specialized of an interface. The site here also includes workarounds for sites that place weird restrictions on the type of password you can use, such as at least 1 letter, number and symbol, or max length 6.

I've decided that in the interest of my security, I'll start using this scheme for all my future passwords, and perhaps change over some of my existing ones if I find it to be easy enough to use. Let me know what you think of the idea in the comments section, and whether or not you'd think of using something like this to stay secure.

dantastic password