Even more secure passwords.

A few days ago I posted suggesting that you salt your passwords, I'm back armed with even more knowledge and better advice. Turns out the relative strengths of one hashing algorithm vs another can in fact make a difference, in a way I didn't even consider - their speed. 

Most crypto hash functions are designed for speed, you want to be able to compute the hashes of lots of data pretty quickly if your pushing it down the wire. That speed works in an attackers favour if they're brute forcing a list of passwords and newer hashing functions can make it worse, one of the requirements for SHA-3 is that it's faster than the SHA-2 family. 

So what's the new right answer? 

Choose a function that takes enough time that an attacker has to work for each and every password - ideally long enough that it would take forever to crack just one - while making sure that legitimate users aren't waiting forever while you check their passwords. 

There are two ways of doing this, run a fast hash function many times or deliberately pick a slow hash function.

Running many iterations of a fast hashing algorithm is pretty self explanatory, run it twice and it takes twice as long, run it a thousand times and it takes a thousand times as long to attack each password.

Bcrypt is an example of the second, based on the blowfish algorithm it uses the fact that the key setup step is a relatively expensive operation and difficult to optimise. By making use of this bcrypt allows you to set a work factor and creates a hashing algorithm that is expensive and also difficult to optimise. 

Which is better? I have no idea, both are widely used and it really depends on your environment. I'd love to hear what others think though.
Read More

Chrome OS.

I don't think Chrome OS is going to be a success.

It's perfect for Google, shows that all you really need is a browser and does it in a compelling way. But it's not going to be a success and I'll cast my lot in with those that predict that it'll get rolled into Android.
The reason I don't see it working is that Google won't use it. Google is a company of engineers, developers and hackers - what do they want with a computer they can't use to do that?
The Chrome OS team is designing and building a product for someone else. Taking things away is a great thing, look at Apple, but if you take so much away that it becomes a product for someone else and you're no longer eating your own dog food. That doesn't usually work out well.

I may be wrong, maybe the team is great and maybe they can overcome the obstacles, but I'll put my money on the best that will come of Chrome OS is that it's evolved into another product or as many are predicting, rolled into Android.

Read More

Salt your passwords.

Gawker media is the latest in a long list of compromised systems that have exposed user passwords. Unlike when it happened to the ASF a few months ago, I'm unaffected.

Forbes and others are banging on about weak encryption being the problem, it's not. Passwords aren't encrypted generally, they're passed through a one way hash function. You can't undo the hash, so you can't decrypt the passwords. When you hash the same value though it will always produce the same hash - so you can ask a user for their password, hash the value they enter and check that against the hash you've stored.

The relative strengths of one hash function vs another actually makes very little difference when it comes to passwords. As long as it's collision free for the set of possible passwords, which almost all will be, they're really strong enough no matter how old they are. 

Gawker made a basic mistake that even the most advanced algorithm wouldn't help, they're not salting their passwords. 


Cracking hashed passwords involves computing the hashes until you create the same hashed value. You run the algorithm across a list of know common passwords, dictionary words and common variations. The same value will always produce the same hash, so everyone who uses the same password will also always have the same hash. You just need to compute all the common/obvious ones and look at all the users to find the ones with that match your list. Lots of those users will probably be using their password for email and other services too... oops.

Salting adds something unique to a user, say their email address or ID, forcing an attacker to compute every possible password for each user individually.  Even if two users have chosen the same password they will have a different hash. The better the salt you can choose, the more work an attacker has to do to get passwords.

It's not a panacea though, you've still exposed their details and given enough time a determined attacker can and will be able to recover every last password. What it gives you is time to disclose the breach and your users time to change their passwords on other services which may be the same.

UPDATE: I've added a new post with some more thoughts, clarifications and corrections here
Read More

Maven and self signed client certs.

I've been using a self-signed client certificate on my development server. Today working on my OAuth lib I started getting problems connecting to twitter, failed SSH handshakes. With a message something like: 

Connection has been shutdown: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

It's because in my maven command I'm using a custom truststore which doesn't have any of the default root certificates in it, just mine. Running this command imported the default roots into the truststore I've been using with maven: 

[code] keytool -importkeystore -srckeystore $JAVA_HOME/lib/security/cacerts -destkeystore ./trust.jks [/code]

I got a long list of  Entry for alias keychainrootca-xx successfully imported and now everything works as it should. 

Hope it helps. 
Read More

Git checkout a tag.

When I recently rebuilt my development server using Puppet I decided not to backup my nexus repository since there were all of three files I'd built in there. Today I wanted to start recreating them and couldn't find out how to checkout a git tag. 

A couple of google searches weren't terrible successful and it's something that's not really explained well so here it is. 

To checkout a tag you just have to 
[code]git checkout <TAG_NAME> [/code]

Yes it's that simple. 

You'll probably get the same warning message telling you you're in a detached HEAD state. If you intended to do some work here it's probably a really good idea to take the advice the message gives you and create a branch. You could do that when you checkout by adding -b

[code]git checkout <TAG_NAME> -b <BRANCH_NAME>[/code]

I didn't want to do anything except a [code]mvn clean deploy[/code] to get my library deployed back to nexus, then get back to where I was. So I didn't. 
Read More

Multiple users, same key in puppet.

I've been a bit quiet on the server front and to be honest a bit stuck. I'm new to Puppet and it took me a while to figure out how to get users working the way I wanted them to. Sleeping on it and reading some more and eventually I got there. I also have a day job to hold down and a family to entertain on the weekend, so as much as I really wanted to get this done life got in the way.
Read More

Groups in puppet.

Last time I ended up not being able to create my user because I didn't have a group for it and ran out of time before I needed to call it a night. So I'll start tonight by creating a group for my user.
Read More