Had a good lunch this afternoon with collegues in the security space. They are doing what I've been thinking about doing for a long time. So there is a good chance I'll be back in the security business again. Security business should be less like Halloween with scary strangers and more like Thanksgiving and Christmas with trust and harmony. Hopefully, I'll make a good Santa with gifts and not a scarecrow with heart of straw.

Via Phil Windley, a must read slides titled Attacking XML Security (warning: 1.7MB PDF) from Brad Hill's 2007 Black Hat session on vulnerabilities of XML-based formats and protocols, particularly XML-DSig and WS-Security. Second half contains the best parts. If you use XML either directly or indirectly, consider it a required read. It would be great if there are videos of the session though.

BTW, did you know that latest Flash runtime supposedly includes XML-DSig validator? I haven't used it yet but it's interesting from security perspective.

BTW2, Phil's Internet Identity Workshop 2007 is coming up early December. Register!

BTW3, SHA-1 continues to lose respect.

It's not the theft of identity that concerns people. It's what thieves do with stolen identity. So if there was a way to prevent high damage activities thieves can do with stolen identity, we would all be better off. How often does an average adult apply for a new credit card or get a mortgage? For most people, the answer will be rarely. And when those occasions arise, the time window is relatively brief. So why are we keeping the door open all the time, inviting thieves?

I wouldn't mind paying for an identity service that helps me control specific uses of my identity, informing providers of affected services accordingly. In a way, it's a security related application of Doc Searls' VRM idea. When I am ready, I'll let you know. Until then, refuse applications from me. Even better, call the police so unsuspecting identity-thieves will get caught.

Related Post: Inconvenience as Service 

I think *discovering* security holes is clearly benefitial but *inventing* new tools that make it easier to exploit those holes seem overzealous to me. Yes, I understand these tools can be used to protect but what about tools that use questionable means? Jikto, for example, uses unsuspecting website visitors' browser to scan other websites for holes. Would any businesses use such tools to protect their sites? If not, who does it benefit? Is it security researchers' job to push the envelope of black hat's state of art?

"This is going to drastically change the scope of evil things you can do with JavaScript," Hoffman said. "Jikto turns any PC into my little drone. Your PC will start attacking Web sites on my behalf, and you're going to give me all the results." - Billy Hoffman, creator of Jikto, a researcher at SPI Dynamics

I believe that even the loftiest principles should be bounded by context. While I don't think security research should only be done reactively, I think active research community should provide better guidelines to prevent people going overboard.

According to this article at Hardened PHP site, well-placed image upload will let any flash movie cross-domain access to the image URL's subpath.

Flash cross-domain policy file can be anywhere and, because Flash plugin doesn't check the file format throughly enough, even hidden inside an image masquerading as a valid cross-domain policy file. Once the image file is there, any movie can call loadPolicyFile with the image's URL to access resources without tripping cross-domain policy check.

Oy. Now we have to scrub images as well?

KVM is interesting and Quamranet is making smart moves but I think what Qumranet might be doing with it may be more interesting. According to the News.com article, less than a dozen out of their 30 or so engineers are working on KVM so what could the rest be working on? My guess is on building a secure bedrock for desktop OS, specifically Vista, capable of securing PCs without drowning users with endless confirmation dialogs by monitoring software activities as well as that of the users then taking smart actions with optional external security policy service, a very ambitious yet rewarding goal although the idea of running Vista on top of KVM-enabled Linux is rather amusing.

Scott Sherrill-Mix has written WP_Identicon, a 9-block implementation of identicon for Wordpress. He even added extra shapes. It's also listed at Wordpress Plugin Database site.

Get it for your Wordpress (roundhouse link-kick to Matt ;-p) blog!

News.com reports that a joint study by four Harvard and MIT researchers claims that SiteKey (aka PassMark) is ineffective. Ouch. While I have little doubts about their integrity, I do wonder if the study is not flawed. For example, doesn't using people who willingly let others observe them signing into their bank account for such a study skew the result? It's probably not as bad as counting virgins among prostitutes but I would like to hear more about how they accounted for such problems.

To be frank, I don't think we ever did a formal study like they did. Why? First, time. Second, money. Third, lack of deathwish. I mean, that's like stopping by the hospital before going to the prom to see if you have a fatal disease, isn't it?  Fourth, user experience (image and questions) was only a part of the PassMark story.

Update:

This news apparently made some people curious enough to do some ad hoc experiments using their own bank accounts. That's a bad idea, folks. If your behavior stray outside your normal user behavior pattern, you are inviting future inconveniences at best.

I just deployed the latest version of Daily which uses canvas-based implementation of Identicon. If you use a browser with Canvas element support (Firefox 1.5+, Safari 2.0+, Opera 9.0+), take a look at some of my posts with comments (including the one that started the avalanche if you want to see the rare sight of 400+ canvas elements being rendered on the fly). You'll notice that identicons look much smoother looking now. On IE, it looks the same. I could have used excanvas but I didn't feel it was stable enough.

One thing that puzzles me though is that Firefox 2.0 seems to fetch the URL of image element *inside* the canvas element when I was expecting that to happen only when canvas support is not available (i.e. no canvas support or when scripting is off). That hurts, particularly for monstrous posts with hundreds of identicons. Currently, I am detecting only problematic canvas support (Safari 2.0) to generate canvas tag without image element within it but it looks like I'll have to do more to emit only the canvas tag if I am going to avoid unnecessary image requests.

Anyway, let me know if you run into any problems seeing identicons. Meanwhile, I am going to spend some quality time with the Identitune idea.

Update:

Apparently, identicons are not rendered on javascript-disabled Firefox browsers because canvas support is not disabled when script is disabled. They should spell out expected behavior in the canvas spec. While at it, an attribute for specifying data is needed. For now, I am using title attribute but that feels wrong.

Update 2:

Fixed noscript/canvas issue by adding img version inside noscript tag. Fixed unnecessary img URL fetch in Firefox by skipping fallback img tag inside the canvas tag (this speeds up canvas version load lightening fast, even with 400+ identicons in a page!). I think canvas support in browsers needs to workout these common issues.

I'll be attending Doc Searls' Mobile Identity Workshop on Friday.

Both thumbs up for Berkman Fellowship: getting paid to disrupt the world for the better must be one of the best jobs ever. :-)