I’ve just renewed my domain for another 10 years and figured it was time I put something on the website. It’s been pointing to a github pages 404 page for some time.

So I’ve been running OS X 10.10 for a while and tonight decided I’d try to install the Java 8 JDK (JDK8u05) and have a play for a project I’ve been messing around with. Unfortunately I got this:

Does this work?

Sainsbury's online grocery site was broken last night; it kept giving me 404 errors when I tried to pay for my order. There was one slot left that would get here before I had to pick the kids up, I'd booked it and wanted to keep it,  so I emailed their customer support. I was hoping maybe they'd tell me when it would be fixed, reserve the slot for me or something. 

I kept checking my email and trying their site and eventually later in the evening it worked, so I forgot about the whole thing until this morning when I got this: 

From: "Sainsbury's Online " <sainsburys@mailuk.custhelp.com>
Subject: Shopping online [Reference: 120110-00XXXX]
Date: 11 January 2012 09:54:42 GMT
Reply-To: "Sainsbury's Online " <sainsburys@mailuk.custhelp.com>

Dear Mr McCall

Thank you for your email about our website. I'm sorry you've been having problems on our website due to an error 404 message. I understand this must be frustrating.

I've spoke to our Customer Support Team and they have told me that Microsoft have been experiencing issues accessing the Sainsbury's servers that our website is based upon. They suggest that you search Google for "Error 404 Fix" and a Microsoft Tool will be available for download. Once downloaded this tool will fix the error and you'll be able to use our website again.

If you need any further help please contact us on 0800 328 1700. One of my colleagues will be happy to assist you.

We appreciate you taking the time to contact us and hope this issue is resolved for you soon.

Kind regards

<Name Removed>
Customer Manager
Sainsbury's Online

I don't know what I can add to that. 
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. 


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. 

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.
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.

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
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. 

subscribe via RSS