andrewmccall.com

Validation 1.0.0 released.

I just pushed my little JSR-303 validation lib out as a 1.0.0 release. The JSR-303 is not 1.0 so it seemed like a good idea. 

The biggest changes are probably the ones needed to support those. If you were using the library you won't notice any difference, the changes are all internal and the actual annotations haven't changed. 

I've also removed the springframework package. JSR-303 is now supported in spring 3 and their support is better.

Finally I've added some static methods to AbstractAnnotationTest, assertValid and assertViolation; I've found them useful testing annotated classes and figure someone else may too. 

Check it out and let me know what you think. 

http://github.com/andrewmccall/validation

oEmbed

I came across oEmbed the other day, completely by accident.

I've been working on a couple of projects in my free time and in a few of them I really wanted to be able to embed better information about a URL, if it existed. I'd been working up my own rough JSON schema that was in many ways similar to oEmbed.

Then I came across a tweet that mentioned embed.ly and oEmbed and embed.ly are the perfect solution. Instead of rolling my own service I'm integrating theirs.

At it's most basic it's a standard way of getting more than just a link you can embed in your site and provides a standard interface for doing it across the web. 

If you're looking to embed things in your website, take a look. There are plugins available for wordpress and others as well as a jQuery plugin you can use pretty much anywhere. 

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.

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.

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