Links

Ben Laurie blathering

30 Dec 2008

More on MD5 Collisions

Filed under: Security — Ben @ 21:14

The attack suggests that examining a suspect cert for a signing algorithm using MD5 and an unexpected field, such as a “Netscape Comment” extension, is a good way to spot the attack (if you are an expert). Funnily enough, it turns out that comments on MD5-signed certificates are actually fairly common – for example, you can see one here: https://es.gnu.org/. I’m not sure what tool makes these certificates (other than it appears to be OpenSSL based) – anyone out there know?

While I’m on the subject, people have opined that I might have been hasty in judging the authors, since they have, apparently, spoken to some subset of the people they should have. OK, perhaps I should not have used the term “0day”, but responsible disclosure means making a reasonable effort to contact the appropriate people. If you were serious about responsible disclosure and you had an attack on SSL wouldn’t you discuss it with the guys who maintain the most widely used SSL software in the world? I think you would. Perhaps I’m missing something?

And on that note, I think we should remove OpenSSL’s ability to sign with MD5. Unfortunately removing MD5 altogether is pretty much out, since that would break SSL and TLS. Refusing to verify with MD5 would be nice, too, but it looks like that would also break a lot of existing certificates, so I suspect if we’re going to do that, we should schedule it for a while in the future. Also, I’m wondering if we should rename the MD5 functions so that everyone using it is forced to do some kind of code review, if only to decide they’ll continue to use the broken algorithm. Any thoughts?

Morons Release Beautiful Attack

Filed under: Rants,Security — Ben @ 16:18

I’m in two minds whether to even talk about this, but I guess it’ll be all over the ‘net soon.

A rather lovely attack on X.509 certificates exploiting the weakness of MD5 was released today. Read the (very well written) paper for all the gory details, but the short version is you construct a pair of certificates with colliding MD5 hashes. One of these you send off to get signed, and the other you carefully arrange to have the “CA” bit set. This means the second certificate can now be used to sign any other certificate: in effect you have become a CA, using what is known as a chained CA certificate.

So why are they morons? Because they chose to 0day this attack. Why? Users could have been protected from this exploit quite easily – only browsers and CAs had to be notified, which is easily achievable without premature public disclosure. I have no idea why they chose not to do this, but they’ve certainly destroyed any trust I had in them – which is a shame, at least some of them were people I respected.

Ironically, their attack is rendered somewhat pointless right now, as it has been recently shown that Comodo will issue a certificate for any website to anyone at all, without verification.

20 Dec 2008

IETF Shoots Itself in the Foot

Filed under: Open Standards — Ben @ 20:22

The IETF recently introduced new rules for all Internet Drafts and RFCs that require contributors to grant copyright and trademark licences. This is a perfectly sensible thing to do, of course, but it seems to have introduced an unforeseen problem: it may no longer possible to produce revised versions of old RFCs, particularly if the original authors are dead, as is the case for SMTP, for example.

Oops! This is a great example of why you really need to get your intellectual property rights in order from the start, or you’ve got one hell of a mess to clear up.

18 Dec 2008

Microsoft Show a Complete Lack of Respect for Privacy

Filed under: Anonymity,Privacy — Ben @ 20:24

I am astonished to read that Microsoft suddenly removed anonymity from blog posts. Retroactively. WTF? That’s just crazy, not to mention rude. I can’t begin to imagine who got outed by this and how annoyed they must be.

I also wonder whether, when they were pretending that posts were anonymous, they revealed that they were actually tracking who wrote them all? And finally I wonder, given the litigious nature of their homeland, who is going to sue them first?

17 Dec 2008

Whoops!

Filed under: Caja — Ben @ 13:58

Never moderate your comments before you’ve woken up. I accidentally marked two perfectly legitimate comments as spam this morning, and it seems WP doesn’t let you get them back…

So, here they are. First from James A. Donald

That is a million fold increase in the number of users of capability systems.

I would like to see a capability vm that runs good old fashioned C++, wherein the only access that code has to the larger world outside the vm is by objects corresponding to data streams – which is in fact very close to he way that vms work right now.

You should look at Native Client.

Secondly, from Julien Couvreur

Congrats! That is great to hear.
I was wondering: has there been any discussion to have a sub-set of javascript (such as Caja) directly supported (and enforced) by the browser? You could probably have a backward compatible and failsafe solution where server-side validation is applied if the browser isn’t trusted?

In fact, partly spurred on by the existence of Caja, and particularly through the hard work of Mark Miller, Caja’s language expert, the ECMAScript committee has been working on the catchily named “ECMAScript 3.1 Strict” which is pretty much the same language as Caja. I assume that this will, one day, get native support.

16 Dec 2008

Caja Goes Live on Yahoo!

Filed under: Caja,Capabilities,Security — Ben @ 14:28

Yahoo! yesterday launched their new development platform for My Yahoo! and Yahoo! Mail, which uses Caja to protect users from malicious gadgets. This means Caja suddenly got 275,000,000 users. Wow! I guess this makes Caja the most widely used capability language ever.

But what I’m most excited about is that there’s virtually no mention of Caja at all. Why? Because Caja gives you security without getting in your way – the fact that end users don’t need to know about it all – and even developers hardly have to care – is a great success for Caja.

4 Dec 2008

Making No Sense

Filed under: Rants,Security — Ben @ 20:27

Paul Madsen wants to continue to beat this dead horse. OK.

unphishable : impossible to phish, see phish.
.
.
phish: a fraudulent attempt to acquire sensitive information such as usernames, passwords, and credit card details by masquerading as a trustworthy entity in an electronic communication

This more inclusive definition does not guarantee (for some mechanisms, this would be the case) that there will be nothing on the authentication server that could be used by a insider to impersonate the user elsewhere. And so, this type of unphishable does not inevitably mean that it is appropriate to use the same credential everywhere.

It seems the plan here is to define certain ways of stealing your password as something other than phishing, and because I want to defend against them, I am therefore wrong. What a pointless argument!

OK, let’s call them unstealable instead of unphishable. Happy now?

What Does “Unphishable” Mean?

Filed under: Crypto,General,Identity Management,Security — Ben @ 7:36

About a week ago, I posted about password usability. Somewhere in there I claimed that if passwords were unphishable, then you could use the same password everywhere.

Since then, I have had a steady stream of people saying I am obviously wrong. So, let’s take them one at a time…

…as long as the password I type in there is send over (encrypted of course) to the backend and recoverable there as plaintext password, you have to trust it is stored/used securely there.

This does assume that everywhere you use it actually secures your password, and doesn’t just store it as plain text.

…there are many attacks to finding your password — an administrator at Facebook could look it up in the password database…

OK, OK, that’s three, but they say the same thing. This one is easily dismissed – obviously if we are using an unphishable protocol the password is not sent at all and it is not kept in Facebook’s database. If it were, then clearly a phisher would easily be able to get your password once he tricked you into typing it in on his site.

Even with perfect or near-perfect hardware, somebody will always find a way to game the system via social engineering.

Don’t forget that we are in a utopia here where users only ever type their passwords into the unphishable password gadget. I think it’s pretty reasonable to assume that if we’ve trained users to do that, we have also trained them to never reveal their password at all anywhere else, including in person, over the phone, via video-conference or during a teledildonics session. Yes, this does mean changing the world, but … utopia, remember?

Mythical crypto-gadgets simply won’t save the day. All somebody has to do is replace your crypto-gadget with an identical-looking crypto-gadget of their own making and now it becomes the new “password” input field that is so phishable

This seems to be more a criticism of the idea that we can ever get to the password utopia, which is a fair comment, but doesn’t make my argument incorrect. I will offer, though, hardware devices (such as the one I wrote about recently) as an answer. Clearly much harder to replace with “an identical-looking crypto-gadget of their own making” than software.

There is also the notion of the “trusted path” which, if anyone ever figures out how to implement it in software, would make such a replacement equally difficult even if we don’t use hardware. However, if you read the Red Pill/Blue Pill paper, you’ll see I don’t hold out much hope for this.

you could have a weak password that the hacker could attack via brute force

This one is actually correct! Yes, it’s true that an unphishable password must be strong. Clearly no system relying solely on a password can defend against an attacker guessing the password and seeing if it works. The only defence against this is to make it infeasible for the attacker to guess it in reasonable time. So, yes, you must use a strong password. Sorry about that.

The primary reason one should not use the same password everywhere is that once that password is discovered at one location, then it can be reused at other locations

I feel that we’re veering off into philosophy slightly with this one, particularly since, in the same post, Conor says

I also look forward to being able to login once at the start of my day and maintain that state in a reasonably secure fashion for the entire day without having to re-authenticate every few minutes

which is an interesting piece of doublethink – surely if whatever provides this miraculous experience (one I also look forward to) is compromised then you are just as screwed – so wouldn’t the argument be that I should have a large number of these things, which I have to log into separately?

Nevertheless, I will have a go at it. In our utopia, remember, our password is only ever revealed to trusted widgets (whether hardware, software or something else is immaterial). This means, of course, that the password can’t be “discovered at one location” – this is the nature of unphishability! Therefore, I claim that the criticism is a priori invalid. Isn’t logic wonderful?

I don’t follow.

Because I can’t be fooled into divulging some credential where I shouldn’t means that it is appropriate that I use it everywhere? Are there not other attack vectors that would drool at the thought?

I include this for completeness. Clearly, this is a rhetorical device. When Paul comes up with an actual attack, rather than suggesting that there surely must be one, I shall respond.

Finally…

Conversely, that the fact that I can use the same credential everywhere is somehow a necessary aspect of ‘unphishability’?

Indeed it is. If it were unsafe to use the same credential everywhere, then the protocol must somehow reveal something to the other side that can be used to impersonate you (generally known as a “password equivalent” – for example, HTTP Digest Auth enrollment reveals a password equivalent that is not your password). This would make the protocol phishable. Therefore, it is a necessary requirement that an unphishable protocol allows you to use the same password everywhere.

Even more finally, for those whose heads exploded at the notion that I can log in with a password without ever revealing the password or a password equivalent, I offer you SRP.

3 Dec 2008

Podcast With Dave Birch

Filed under: Anonymity,Identity Management,Privacy,Security — Ben @ 16:07

A few weeks ago, Dave Birch of Consult Hyperion interviewed me about Digital Identity. Because he weirdly doesn’t give a way to link to an individual podcast, here’s the M4a (whatever that is) and the MP3.

This was the first podcast I’ve done that I actually dared listen to. I think it came out pretty well.

Red Pill/Blue Pill

Filed under: Distributed stuff,Security — Ben @ 15:28

As I have mentioned before, Abe Singer and I wrote a paper on giving up on general purpose operating system security, and instead performing all your security-important online operations from a separate device.

Anyway, we presented this at NSPW, and based on feedback we got there, we’ve now revised (actually, rewritten) “Take the Red Pill and the Blue Pill”.

2 Dec 2008

Multi-layered Authentication

Filed under: Crypto,Identity Management,Security — Ben @ 18:28

Although I don’t usually represent Google when I post on this blog (it being my personal blog), I figured readers might be interested in a blog post and an article I wrote with my colleague, Eric Sachs, about combining different authentication mechanisms in order to improve the user experience of strong authentication without having to change all the software in the world.

Of course, there are almost certainly better ways to do all this if you can change the software – that’s our next mission!

Powered by WordPress