This morning, Flickr released a new feature . One that let’s you find your friends from your existing address books on Yahoo! Mail, Gmail and Hotmail. All without providing usernames or passwords. Aren’t APIs wonderful?
I
twittered about the new black
and got a reply from
Amanda
asking
isn’t that encouraging people to get phished?
In a nutshell, the answer is yes.
Super green
Folks who think about such things are rejoicing that there are now so many site-specific APIs and authentication protocols such as OAuth that avoid what Jeremy Keith called the Password Anti-pattern . And I’m one of them. The Password Anti-pattern is a Bad Thing™. I don’t think anyone would disagree with that.
Removing the Anti-pattern means that the authenticating site doesn’t get full unlimited access to the account in question. In Flickr’s new feature, they get access to only the details of who is in my Gmail address book - not my emails and certainly not access to any other Google products I may have enabled on that account. Google’s authentication page confirms for me that Flickr is requesting access to only my contacts and only for a one-time use:
Flickr.com is requesting access to your Google Contacts account so that it can access Google Accounts on your behalf. You can revoke access at any time under ‘My Account’. Flickr.com will not have access to your password or any personal information. Learn more .
Flickr.com is only requesting one-time access . If it needs to access Google on your behalf in the future, you will be prompted again for permission.
All of this is hot, hot, hot! As long as you’re actually on Google’s authentication page.
Phishes away!
A major argument Jeremy stated against the Password Anti-pattern is that
it teaches people how to be phished
, but these new authentication methods don’t fix that. They
still
teach users that allowing your existing site to authenticate to a third party site is a Good Thing™. It’s a simple matter to produce the appearance of following that authentication process while actually harvesting details.
The solution to this is the same it has always been. The user needs to check the URL of the page they’re on and make the call. The problem with that is also the same as it has always been. Some users, possibly most users, don’t do it.
Are we making things worse?
The new authentication methods may actually train users to phished even more readily than before because there is less of a cognitive cost to the process. Ever since computers came into use, users have been hammered with warnings about the importance of passwords. The web has damaged that somewhat with our profligate password ways, but I reckon there are still plenty of mental alarms to ring when somebody asks for your password.
Using sexy protocols and APIs don’t cause that hesitation. The process has been designed to create a neatly streamlined user experience. Just click a few buttons and it’s over.
A phishing site is unlikely to do that, of course. These days API access requires registering for a key, allowing the API providers to track usage. Providers have varying levels of diligence, but it seems unlikely that an application could do phishing on a significant scale without being caught.
The most likely alternative is that they simply pretend you’re not currently authenticated with the third party site and request your username and password. Hopefully, that’s enough to give pause. Particularly if the app is telling you you’re not authenticated with Hotmail when you have Hotmail open in the next tab over.
What’s my scene?
In the Password Anti-pattern article, Jeremy took a moral stand: even if it costs me a contract in the short-term, I will refuse to implement any kind of interface that involves asking the user for a password from a third-party site. I urge you to do the same.
That was admirable and eminently reasonable. Many agreed. He provided what he thought was a viable alternative by pointing to the same authentication methods I’m discussing here.
I thought it was the right choice at the time, too. I stood with him. I don’t know if his stance has changed now, but I know mine has.
What is the alternative?
Authentication APIs and protocols have their benefits and they have their costs. Do these cancel each other out? Should we refuse to implement this functionality?
If you agree with my points here, maybe you think that. But what do you implement instead? There will be a lot of demand for this functionality as it becomes easier and easier (no more screen-scraping!).
Personally, I’m for it. I have reservations now, but the practical benefits of isolating and securing access to my data wins over the hypothetically higher risk of phishing. And on that day when I’m so tired, hungover or ill that I absentmindedly just click through the process and hand over the keys to my kingdom, I hope some small flicker of self-preservation will alert me so that I can correct it in time.
Comments
There are 14 comments on this post.
But Lachlan, the fact that you are entering your Google password on Google or your Yahoo password on Yahoo makes all the difference. Do you have any data to back up your assertion that most users don’t check the URL of the page they are authenticating with? The anecdotal evidence that I’ve heard (albeit from just a smattering of users) is that they feel distinctly uncomfortable entering their username/password from one site on another …but that they over-ride these concerns in order to import their friends’ contact details. A correct authentication process soothes these concerns though, as you said, users still need to check the URL and check for the SSL lock symbol.
I think the main issue you’re pointing to is one that affects every single document on the Web: how can you trust the page currently loaded in your browser? Trustworthy URLs and SSL can help people make up their minds but the issue is fundamentally subjective. For example, one person reads an article and believes it because it is on Wikipedia; another person reads the same article and doesn’t believe it for exactly the same reason.
This isn’t even a new problem. For as long as any kind of recorded media has existed, the trust issue has been there: how can you believe what you read in a newspaper, hear on a radio, or see on TV? Trust cannot be solved by technology. But technology (like API authentication) can go a heck of a long way to helping people make up their own minds.
Another example…
I’m entering my name, email address and URL in the form fields provided here. But how do you really know it’s me? You can’t be 100% sure. A technology like OpenID would go a long way to establishing trust—trust that I am who I’m claiming to be. But even that can theoretically be gamed.
So yes, I agree that there is no perfect way to establish trust on the Web (or IRL, for that matter) but there’s still a huge difference between entering a username/password combo for site X on site X and entering a username/password combo for site X on site Y.
I think that client-side certificates can go a long way to help with this kind of problem, as well as just being really convenient and brain-dead simple! MyOpenID.com already implements this form of authentication, and I hope other issuers will follow suit.
See 70% of users would willingly give up their password for a chocolate bar. I’ve personally discovered that people will open almost any “security” door - including a university cashier booth - if you offer them lollies and look like you’re having fun (see: re-gruntling).
Sub in “have fun with friends” for “get a chocolate bar”. I think a lot of people out there will take the risk because they feel the return is worth it or because they simply don’t realise/believe there’s a risk.
@Chris Messina and @Jeremy Keith nailed it above. This is a big improvement, and Gmail et al should definitely have a “paper trail” equivalent.
Ah, Chris, I wish I were running OpenID! I will be as soon as I finish the db migration script from Simplelog to Enki (which requires OpenID for everything).
I hadn’t considered the paper trail aspect. That has definitely got a lot of potential for giving users more control over their online interactions and data sharing. Very exciting!
Glad to see you’ve retained your skepticism, Ben! Yeah, I still don’t believe most folks care or value their passwords. I have some passwords I value less - if that makes sense. I use them on sites I don’t trust yet.
Cool idea, Alan. Especially if it were implemented on OpenID providing sites such ClaimID and myVidoop etc!
I think openID can reduce the amount of spam on the net. If the only thing was to provide an ID in the comment section then a lot of spammers would simple give up.
I don’t agree, Natalia. It may have that effect in the relatively short time, but as OpenID begins to see ever more uptake, I think that serious spammers, the ones writing bots etc, will build their own OpenID servers that don’t require login and simply authenticate anyone who asks.
That’s not just speculation either, the anonymous OpenID thing has already been done a few times over now - it’s really quite trivial to setup (phpMyID, change a few lines, voila).
@lachlan @xavier
Yes you are right
Its not going to be long before we start seeing block lists a la the ones that we have seen in email.
Q&D use case
Site recieves openid url Site checks against blocked domain list \>if site not in list, move on and authenticate. \>if site in list, tell person to get lost or use better domain.
But is Openid meant to fight spam? I dont think so, the way its set up as you say doesn’t really guarantee that you are who you are. It guarantees that the server asked says that you are who you say you are. Can you trust the server to tell the truth about who you are? No. You can combat this problem with white lists of servers that you trust and accept ids from. That of course means bye bye to the flexibility of openid. And you can’t really still trust it since someone might have taken over your whitelisted server.
Spam I think must be fought at different levels, not in openid. Use the same tools you already use now to decide if you want to trust the person with some functionality on your site. Whatever you deem sufficiant to trust a person. (mail reply, moderation and so on)
You could even set up a whitelist of openid servers that you trust to not be spammers, and allow them more rights off the bat, than non whitelisted domains. It all comes down to you as admin to figure out what constitutes trusted info.
You’re missing one key thing. Technologies like OAuth make it so that the service no longer needs to user the antiquated username/password technology to authenticate you! Proprietary techonolgies like the vidoop image shield, or open standards like client side TLS certificates, or two-factor phone authentication, or OpenID (which in tun can and does use any of these methods) can be used instead.
Phishing only really works when there’s passphrases involved.
@Stephen,
2-Factor-Authentication is not going to stop phishing, nor is a shunt for OpenID. EG of 2 factor phishing below
http://www.theregister.co.uk/2007/04/19/phishing
evadestwo-factor_authentication/
Phishing will always exist. The solution doesn’t exist in any technology, it exists in user education.
–Wade
GMail already does have an activity log/paper trail, although only for sessions using full username/password - I can’t see a log for oAuth based requests yet.
It’s a bit hidden though. If you open Gmail in more than one browser at once, you get a message in the footer like:
“This account is open in 1 other location at this IP (). Last account activity: 48 minutes ago on this computer. Details [which links to a popup containing a full log]”
Frankie
New comments are no longer enabled on this site.