The password anti-pattern

Design patterns are useful. They enable us as developers to encapsulate recurring interactions and refine them. From simple pagination right up to Ajax requests, patterns allow us to codify common conventions.

Inevitably, conventions can lead to a mentality. Clients start to request Web 2.0 standards. I have no idea what that means but it usually involves tagging, “friends” and gratuitous use of JavaScript. This kind of copycat development isn’t so bad if you’re ripping off a site like Flickr—the more sites like Flickr, the better. The problems start when web apps start replicating bad design patterns as if they were viruses. I want to call attention to the most egregious of these anti-patterns.

Allowing users to import contact lists from other services is a useful feature. But the means have to justify the ends. Empowering the user to import data through an authentication layer like OAuth is the correct way to export data. On the other hand, asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:

It teaches people how to be .

This issue was raised by Tantek at Fundamentos Web. Rigo Wenningprivacy activity lead at the W3C—was quick to back Tantek’s position. While we can’t protect people from themselves, we have a duty not to deceive them into thinking that throwing passwords around like confetti is acceptable behaviour.

Oh, don’t worry… the terms of service for Google accounts puts the responsibility in the hands of the user:

  • Your passwords and account security
    • 6.1 You agree and understand that you are responsible for maintaining the confidentiality of passwords associated with any account you use to access the Services.
    • 6.2 Accordingly, you agree that you will be solely responsible to Google for all activities that occur under your account.

…but this isn’t a question of legalities.

I was somewhat surprised, even shocked, to see 37 Signals highlight this anti-pattern on Facebook as a smart way to connect members of the site. Simon was quick to point out the problem:

The Facebook thing isn’t a smart way of connecting members, it’s a horrible precedent that teaches users to be phished. Unfortunately that kind of feature is so prevalent now that you’d be foolish to launch a new social network without it, but from an ethical point of view it’s distinctly unpleasant.

He’s right. The issue for us as developers is a moral question. Do we blindly follow the dictates of clients looking to “add value” to their applications even when we know that the long-term effect is corrosive? I don’t think we should. We can collectively make a choice not to erode the long-term stability of our users’ data. Sure, the particular site you’re working on might not have any nefarious plans and the next site might claim to be secure, but over time we’re creating a climate conducive to cultivating honeypots.

Morality (or ethics) is not something that’s usually discussed alongside Web development. But Jeff Veen pointed me towards this great quote from Jamais Cascio’s talk at the Singularity Summity that illustrates the underlying truth:

To put it bluntly, software, like all technologies, is inherently political. Even the most disruptive technologies, the innovations and ideas that can utterly transform society, carry with them the legacies of past decisions, the culture and history of the societies that spawned them. Code inevitably reflects the choices, biases and desires of its creators.

So here’s what I’m going to do: 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. And if you feel equally strongly about this, make your thoughts known: blog about it, talk about it… you might even want to make your position clear in your terms and conditions. As the Naked Yak blog so eloquently puts it:

With the endless possibilities of the social web it is easy to fall into the trap of going for broke, applying everything in life to a particular application or piece of software that seems to enhance it. From now, I will always ask the question “Will this have a positive effect on my world?” rather than “What could I pull into this new tool?”

Update: For all the people saying yeah, but no, but yeah, but we need access to users’ data, please read the post again and this time, pay attention to the part about OAuth. See also:

I don’t know how much clearer I can make this: the end result of exporting data is desirable; teaching users to hand over their passwords to any site that asks for them is not. There is no excuse for asking for a third-party password on your website. You’re doing it wrong. That authentication must happen on the third-party site.

Have you published a response to this? :


Chris Messina

This is great and I’m so happy that you’ve brought it up. This was one of the primary drivers for OAuth (given that we were endeavoring to push for wider adoption of OpenID) and something that I’ve clearly been documenting in my Flickr stream.

I hope that OAuth proliferates and offers a viable alternative to this dangerous trend. Thanks for writing this up. I absolutely support this call.

Jeff Allen

I’ve noticed similar requests from some people in my area. "Ajax this" and "Ajax that" even though they aren’t sure what Ajax is. All they know is they want it. They want it bad! It’s almost like a drug addiction now.

And all of this leads right back to the need for a professional code of ethics for web developers and programmers in general. Molly has spoken in the past about a need for one as have others in the standards community.

Lawyers have them, as do doctors, accountants, even architects. I’ve heard a number of discussions in the past about how in the eyes of the general public web developers aren’t really "professionals" partly because we have not developed a cohesive, comprehensive code of ethics for the profession.

I like the idea of clearly stating them in the Terms Of Services agreement. This is something I am going to take a very serious look at implementing.

However let us not forget that it could be argued that part of our role as their contracted web developer is to educate our clients on what is and is not considered best practices, especially where social networking comes in.

After all even you noted that the kids that grew up on the internet regard everything as public unless it is expressly denoted as private, whereas those folks who didn’t grow up on the internet tend to regard all information as private unless it is expressly denoted as public.

Just my thoughts.

# Posted by Jeff Allen on Friday, October 12th, 2007 at 12:23am


While I agree with the principal I do think there may be exceptions.

Do you feel that this position can be varied depending on the (assumed) knowledge and experience of the target user?

# Posted by Andrew on Friday, October 12th, 2007 at 9:09am

Richard Rutter

It’s a tricky one. The pattern of taking your username and password of one to site and giving it to another site is exactly the pattern that you see in phishing attempts. So this is bad.

But being able to look for people you know based on your Gmail address book is potentially very useful to both the end-user and the social web site.

So what’s the solution? For a start any authorisation should be done on the site to which the authorisation applies. In others you should only be providing your Gmail username and password to

This implies that there needs to be a special authorisation page, a pattern which Flickr has been using for years. Essentially any application (web-based or otherwise) which requires Flickr authentication sends the user to Flickr to authorise that application. It’s a one time interaction which usually sends the user directly whence they came. As a solution, it’s still eminently phishable but using this pattern means that users can still stick with the regular advice that, when entering password, make sure the URL in their browser is of site to which the authentication applies.


Why would a web application vendor want to allow other applications to access their valuable information? By retaining access control to users information, they retain user ‘lock in’. Any company that wishes to remain in business is going to be as obstructive as possible to third parties. The only way another application can reliably access this information is by the user supplying their login information. Open protocols that are recipes for losing business will never be widely adopted.

# Posted by Johnson on Friday, October 12th, 2007 at 10:46am

Frankie Roberto

Presumably we should be promoting the Flickr model of users being able to give and revoke permissions for third-party applications?

The questions is whether the popular e-mail applications have, or ought to have, this functionality.

Incidentally, the e-mail password pattern is particularly harmful when used with GMail, as GMail automatically adds people you’ve e-mailed to your contacts list - so they’re not necessarily even your friends or acuaintances.

Remy Sharp

Thank you for making a stand. There’s no way that one service should ask for passwords for anything other than itself. It’s an outright hack.

What’s worse, as 37 Signals points out (out of context): "No wonder other sites have been racing to implement similar features"

I’ve just noticed that Twitter now offers the same backward-feature!

# Posted by Remy Sharp on Friday, October 12th, 2007 at 11:28am

Alan Wallace

Hi Jeremy,

Good post! What’s your opinion of things like "Verified by Visa"? Do you feel that showing a Visa form in an iframe on, for example, Ebuyer is conditioning users to believe that it is ok if the site looks a bit funny - it’s got a Visa logo so it must be ok?

I’ve raised this issue with friends colleagues and there seems to mixed opinions, most seem to think it is ok but I worry that for the casual user it’s getting harder than ever to spot a phishing attempt.

Victor Engmark

The insecurity of this notwithstanding, how would you create useful third party tools without getting access to the users’ data? I’ve made a web site which implements search functionality for bookmarks which the developers there, upon request, would not implement - What alternative do I have, unless the site owners give me unlimited access (which of course is even more sloppy)?

Not developing a useful tool because users might get sloppier with their passwords elsewhere doesn’t sound like good business…


"There is no excuse for asking for a third-party password on your website. You’re doing it wrong. That authentication must happen on the third-party site."

Doesn’t this largely depend on whether the third-party site in question provides a mechanism to do this?

# Posted by adk on Friday, October 12th, 2007 at 2:34pm

George watson

I am beginning to believe that the best way is for every site to have two passwords. One would be purely for the social functions of a site and could be more freely given out to third party social sites to allow site crossover functions -the social password. The second password would be all things financial and a master password that would allow you to change the first password. The master password would never be given out. That way the more serious problem of single “everything" password carelessness would be rectified because nothing could be charged with the first password. And no site intervention would be needed for users to change their most frequently used social password because they would do it from a financial section only availble with the use of their master password.

The fact is a new beast has evolved from general passwords and it is the “social password”. It should be separate.


Couldn’t agree more. One of my pet hates is the all too common login (username, password) on every single Mom and Pop website with an OScommerce shopping cart. While forcing people to ‘create an account’ when all they want to do is buy is a single $10 item may fool the idiot who owns the site into thinking he’s Amazon, it only pisses off users.

It drives me nuts, and often causes me to leave a site without buying. Why should I need to come up with yet another password for my single purchase from Joe’s Toilet Paper Shop? Just because everyone’s doing it doesn’t mean it’s a good thing.

# Posted by Darren on Friday, October 12th, 2007 at 3:20pm


Completely agree. I did some (unscientific) research on this ( and concluded that very few of the social network sites either have a terms of service page, or even encrypt the page on which they ask for your email password. So any SSL that Google, Yahoo, or MSN might use is defeated when you enter it on someone else’s page.

Interestingly, some of the social network sites still have the "import" page active even though they’ve taken down links to it.

# Posted by Alistair on Friday, October 12th, 2007 at 4:14pm


oAuth is still at the final draft stage. So there is no specification to speak of yet. Your calls to implement oAuth are premature.

# Posted by anil on Friday, October 12th, 2007 at 5:18pm

Jeremy Keith

Anil, I’m pointing to OAuth as just one example of an authentication layer, along with Flickr, AuthSub and BBAuth.

Florian Bailey

I wholeheartedly agree with you, I’m working as a consultant with a lot of clients in the social network area and they all want to implement similar features. I’m not going to do any work on those pages, no chance.

Shaun Hare

Correct Jeremy, services that ask for private details (passwords) you have disclosed to another site just get the brush off from me.

Where does legislation e.g. data protection act stand on this?

# Posted by Shaun Hare on Saturday, October 13th, 2007 at 1:28pm

Kia Kroas

I honestly don’t get it; there is a simple solution to all of this export info vs password security problem: Have the user have two passwords, one is the actual user controls (akin to the root user) and the other for exporting certain data (similar to a guest account). When the login is with the "guest" version, then allow read-only access to specific data. When the login is with the "root" version, then it goes to the actual user access.

I can already think of a way to implement this off my head. There’s a slight overhead difference in having two passwords, but with the server power going around these days it should not be too much of a problem even for sites like yahoo or google. But then again, you know how users are…they just want convenience, not anything that would actually protect them (not to mention some difficulty in having a user with the same root and guest passwords). But meh, that’s my two-cents worth.