dready blog v2.0

There was a thread on the OpenID list around the subject of OpenID support in Drupal. Previously, I’ve experimented with the OpenID module originally written by Jonathan Daugherty from JanRain, now under maintenance by the folks at Bryght. That module uses JanRain’s PHP OpenID library, and it worked pretty much out of the box, with XRI support.

What I learned from this discussion thread is that James Walker from Bryght has been working on another OpenID module that is intended for inclusion into Drupal 6 core distribution, without using JanRain’s library. There are apparently things that Drupal-heads don’t like about the JanRain’s library, licensing may be one of the issues.

So I pulled the DRUPAL-5 codebase from CVS and installed it, then installed the 5.x-1.x-dev snapshot tarball to test it out. First thing I noticed was that it doesn’t support XRI, and I really didn’t expect it to. Then, when I tried logging in with my dready.org identifier, it wouldn’t work because I delegated it to my myopenid.com account. So, it doesn’t support delegate either.

Then I spent a few hours getting rudimentary XRI support into it, and made it work with delegates. Few days later, I realized that this was only a snapshot and the module is in the Drupal contributions repository. So, I threw away my installation but kept the patch I made of the 5.x-1.x-dev snapshot and started anew. The result is a patch that works with the Drupal CVS trunk as of today.

The changes are:
1. When a first-time user is authenticated, a local account is created but no role was specified. Modified the module to add the ‘authenticated user’ role to the user.
2. XRI support. This is very rudimentary and does not support canonical ID yet, but shouldn’t be hard to implement.
3. Delegate support. In OpenID 2.0, the submitted identifier (URL) is passed to the OP as the openid.claimed_id parameter, while the delegate, if present, is sent as openid.identifier.
4. In the meantime, I noticed that the while the URL normalization conforms to the OpenID Authentication 2.0 implementor’s draft 11 specification, it treats http://dready.org and http://dready.org/ (with trailing slash) as different identifiers. Well, they should really be the same as RFC3986 says that for HTTP, an empty path is equivalent to “/”. This normalization rule was reflected in rev 294 of the spec.

Of course this is only a *very* rough patch (no pun intended). I have never hacked Drupal before, and haven’t read much of its coding styles though I tried to follow the conventions in the original code. I do hope that at least parts of it can be integrated into the module though.

My development environment is here: http://dready.org/drupal/. Feel free to try it out.

I just got back this morning from attending the OASIS XRI TC face-to-face meeting in San Diego with Bill Barnhill, Drummond Reed, Laurie Rae, Les Chasen, Markus Sabadello, and Marty Schleiff. A number of good things came out of the meeting, which I’ll leave for another blog because this post is about Internationalized Domain Names, not XRI.

So we just opened the flood gates for Chinese and Japanese IDNs for .BIZ. This has been my brainchild for the past half a year or so, and represents a significant step forward for our registry in terms of internationalization. As one might expect, no support for Chinese IDN is complete without bundling as specified in the JET guidelines and RFC4713.

The tricky part to supporting both Chinese and Japanese IDN within a single registry is that the two languages share a large repertoire of Han characters. While the concept of Simplified and Traditional Chinese is well-understood within the Chinese communities, Japanese generally do not use variants the same way. Two characters that may be considered variants by a Chinese user may be seen as distinct characters with different semantics from the Japanese’ point of view. To implement a registry that respects the culture and expectations of both language communities while offering a high degree of protection against homographic attack is a juggling act in itself. I dare say that NeuStar is the first unsponsored gTLD registry that Got It Right ™.

So, how does it work? Well, suppose you registered 電車.biz with the Chinese language tag, you will automatically get the simplified version of the domain, 电车.biz, placed into the DNS for you. No one can register any combination of variants of the domain, e.g. 电車.biz and 電车.biz.

What if you registered a mixed version 電车.biz, also with the Chinese tag? Well, you get that PLUS 電車.biz (traditional) and 电车.biz (simplified) giving you 3 domains in total! That is because we respect the registrant’s request, even if it looks like a mixed- traditional and simplified string. Whatever you asked for, if it doesn’t clash with another registered domain, will always be given to you.

If, however, the Japanese tag was used to register 電車.biz, that would be the only domain that you’d get. Once that is registered, other variations of the domain name in Chinese will not be allowed to register. This is a slight deviation from JPRS’s appraoch, which treats them as distinct domains. We feel that this conservative approach offers better protection for the registrant.

So that was the skinny on our Chinese and Japanese Internationalized Domain Names offering. Is it me or do Han characters look very good with .BIZ? =)

Usual disclaimer about this being my personal opinion applies.

News broke today that at Virginia Polytechnic Institute and State University (Virginia Tech), 4 hours away from where I am, a gunman shot 32 people before committing suicide.

Jason Easley on the Blogger News Network wrote:

I have a feeling that the tragedy that occurred today at VA Tech is going to lead to a reopening of the gun control debate in the United States.

Gun control isn’t a debate in my mind — it’s a no-brainer: guns should not be widely accessible. Period. Then again, I’m not American.

After laying out both sides of the debate by quoting various political figures, he went on to say:

The person who carried out this attack could have just as easily used a bomb as a gun. Because of the lack of campus security, this was a unique incident that should not be lumped in as part of the gun debate. I have always thought that if someone is intent on killing they will find a way. Removing all guns isn’t the answer, but I do think that we need to ask ourselves why does the U.S. have so many more violent incidents like this compared to the rest of the industrialized world. It isn’t an easy question to answer, and I don’t think the solution is as simple as taking away all the guns. I am far from what would be considered a “gun nut,” but to me it is clear banning guns, except assault weapons, isn’t the answer. I think our societal problem rests more in the hearts of the individuals that carry out such actions than in the instruments that they use to kill others.

Sounds like a vicious cycle to me.

1. Gun advocates defend their right to own guns in the name of self-defense. ¹
2. But easy accessibility to guns leads to violent crimes. ²
3. Violent crimes makes people insecure, though insecurity is force-fed to the consumers in this fear-driven society.

The cycle continues…

This reminds me of a clip in Bowling for Columbine:

¹ I find it hard to believe that anyone would walk out of the gun shop thinking “if someone breaks into my house, I’ll scare him away with my gun.” It’s more like “I’ll kill the bastard!”

² One might argue that guns could not be linked to shootings. I think that’s objective BS that won’t hold up against the conscience.

Ever since I learned about the RegisterFly trouble, I’ve been frantically trying to transfer my domains out of that crook of a registrar.

Some of my domains registered with RegisterFly had Enom as the registrar of record because RegisterFly was an Enom reseller before “getting accredited” themselves. One of them was particularly problematic because the authorization code was not showing in RegisterFly’s control panel and I had to send a bunch of documentations to Enom to get the domain moved to an Enom account. I’ve been twisting my fingers for the past week and am relieved to finally have all my domains transferred to GoDaddy. The only thing I lost out on is some $15 worth of credit in the RegisterFly account, which I am dead sure will not see the light of day.

Now, as long as Bob Parson doesn’t start using the company funds to buy a private jet or some villa in the carribean I reckon I’ll be safe.

Few lessons learnt from this exercise:

• Always keep your whois data up-to-date, particularly the email address
• Renew early (at least 3 months before the expiry)
• Select a reputable registrar - this one is hard as they all suck, just a question of which one sucks less, and a balance between price and reliability.

All my domains are with Registerfly, which is in deep trouble. I won’t re-iterate all the details here because GoDaddy’s Bob Parson has summarized it very well in his post.

So, I’ve been busy trying to transfer my domains to GoDaddy. In case you think I’m some big-time cyber-squatter¹, I have 17 domains in total - hardly any “portfolio”. Keeping my fingers crossed that all my domains including dready.org survives the transfer (it’s tricky because the expiry is near.)

¹ aka “domainer”.

Many of you knew that I was moving to the US — I’ve been saying it for months. So, I finally made the move and am glad to announce that I’m officially here, and am settling in quite well.

Some photos are in order.

After spending a night at Aelvin’s place in NJ, I flew to Washington Dulles Airpot on Saturday 10th of February and arrived at the Hertz car rental to pick up my month-long rental car. I paid for an upgrade and they were nice enough to give me a 2007 Camry, only travelled 1,400 miles.

Next, I went to the apartment to sign the lease and get the keys to move in.

Living room looking at the balcony.

Bedroom

Washer and dryer nicely tucked in a closet

Kitchen

Bathroom

Balcony

View from balcony

Same view on Valentine’s day

Same view on Sunday 25th Feb

View of my apartment block. My unit is the balcony on the third floor.

Across the street from my apartment compound.

When viewed from my balcony on Sunday.

Snow flakes on my car window while driving to work.

On the evening that I arrived, Les and Kim were nice enough to bring me an air mattress and Sony flat screen TV plus some essentials all the way from Baltimore. That was a life saver, thanks guys!

The first weekend was Chinese New Year and since Monday the 19th Feb was President’s Day. Seeing that it was a long weekend, I decided to drive up to NJ to spend with Aelvin and his family. It was a nice and quiet one, but I didn’t take any photos except on my way back (using my brand spanking new Blackberry Pearl):

Along Interstate highway I-95

In the tunnel near Baltimore

And if you’re curious as to what my place and surrounding is like, here’s a satellite view:

This satellite map shows you how to get from my apartment to my work place. Yep! 6 minutes and a traffic light later, I’m there!

That’s it for now!

From the innovative mind of Simon Willison comes IDProxy:

idproxy.net, launched today, is my attempt at speeding up the process. It uses Yahoo!’s Browser-Based Authentication API to allow you to sign in with a Yahoo! account, then lets you create one or more OpenIDs (of the form something.idproxy.net) to use with sites that support the OpenID standard.

Basically, it’s an OP that authenticates against Yahoo - call it an intermediate IdP, Proxy OpenID Provider, OpenID-Yahoo bridge, whatever.. it rocks!

The OpenID phishing issue is a hard one to solve, particularly because it aims to:

1. be user-friendly, i.e. it should pass the mother-in-law test; and
2. work on the web platform without special software or browser plugin

So, why is this suddenly a problem?

Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ’shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.

This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there are research¹ to prove that people get tricked very easily.

Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:

Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.

…

This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.

The picture is not so sunny, however, because most users:

• won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
• won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com

And even if they installed those anti-phishing toolbars and what not, they still fall for it!

While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.

So, here’s an idea for a browser (or plug-in) implementation:

FUNCTION form.onsubmit()
  IF !form.contains-password-field()
    RETURN ok
  END IF

  IF form.action.domain IN trusted-domains
    RETURN ok
  END IF

  SHOW WARNING-DIALOG (delayed-dismissal=5 secs)

  IF continue-button.clicked
    ADD form.action.domain TO trusted-domains
    RETURN ok
  ELSE // cancel-button.clicked
    RETURN not-ok
  END IF
END FUNCTION

The idea is that you should only submit passwords to sites that you have previously added to the trusted-domains list. This idea is not new, and has been proposed by several on the OpenID list.

Where I think could really make a difference is the way in which WARNING-DIALOG is constructed. It should contain the following:

• If the current page and the form target page are on different “effective domain”, emit warning. There are legitimate use cases for this, and we don’t want to overemphasize it, but it should raise suspicion.
• Display the “effective domain” of the form prominently.
• If the form target is not a HTTPS URL, emit warning.
• Warn the user that the target is not known to the browser to be trusted, and that this could be a sign of phishing.
• A continue button that is greyed out for 5 seconds to force the user to read the above information.
• A cancel button that is focused by default so hitting enter will dismiss the dialog and cancel the request.

An “effective domain” as I call it is defined as the DNS name in the URL stripped of insignificant parts. This basically means that we can use Mozilla’s Effective TLD Service that I blogged about earlier to summarize a URL for display to the user so that us.rd.yahoo.com becomes just yahoo.com, and it will correctly work for things like www.netbank.com.au, which returns netbank.com.au instead of com.au.

A sample dialog might look like:

There are a few advantages to this proposal:

• it works on all password forms, not just for OpenID
• it forcefully disrupts the flow of the user and the delay may help the user to be more cautious

The downsides are:

• it only works for password phishing, other information such as credit card numbers will go through without warning
• phisher can replace the password input field with javascript / DHTML / flash to bypass the check

Even with these restrictions, I still think that it brings significant value in terms of mitigating password phishing attacks. This is of course very raw and there is much room for improvement. All comments and suggestions are welcome.

¹ Thanks to Mike Beltzner for the links to these phishing research papers.

UPDATE: Kim Cameron’s latest blog post about Integrating OpenID and CardSpace has some nice pictures of the modal OpenID phishing attack scenario.

This was going to be a “Dear LazyWeb” request, but after some research I found what I wanted.

Recent discussions about security and phishing on the OpenID list got me thinking about the problem space.

DNS plays a critical role in the security of OpenID because

1. URL is the identifier type used
2. User should only trust the OP with which he/she has an account with.

The “Phishing and OpenID” discussions on the OpenID list actually hinges on point #2 above. Ben Laurie wrote about it here. In short, OpenID opens the door for a malicious RP to send a user to a spoofed OP-lookalike and collect his/her password.

Back to DNS. I have, on numerous occasions in the past, tried to look for a list of domains where registrations are open for public. This varies from TLD to TLD, e.g. .biz accepts registration directly on the second level, .us also does but delegates two-letter subdomains to US states, and .uk only accepts registrations on the third level after .co.uk, .ac.uk, etc.

Well, it turns out that the Mozilla folks needed this list in order to disallow web sites setting cookies for the entire .co.uk or similar domains. Currently, they block just the TLDs so example.com cannot set a cookie for .com, but 2nd level onwards domain cookies are allowed. This could easily cause cookies to be stolen by any site rooted in the same domain.

So, this advisory started this bugzilla entry at Mozilla and it eventually led to the creation of this API and this list (see attachment). They call it the “Effective TLD” list, which is really a misnomer because they are not necessary just TLDs. It was decided in the bug discussions that the term “effective TLD” is easier to digest that anything else, though I’d prefer to call it “Security Restricted Domains”. Whatever, as long as it gives me the content I want.

Many will probably criticize Mozilla for creating yet another list that gets stale the moment it is created. Indeed, TLDs get created and 2LDs within TLDs are introduced and deprecated so often that such a list will be hard to maintain. Moreover, many organizations assign names to registrants at a level that doesn’t involve the TLD registry. Examples include CentralNIC’s .<country-code>.com and *.blogspot.com, and countless others. Add to it the introduction of IDN TLD may well be in less than 2 years. Keeping a definitive list is not feasible. Nevertheless, I would argue that depending on your needs, this list could still be very valuable, as is the case with the cookie problem that they are trying to solve.

So, what has this got to do with OpenID? I shall leave that to a different post.