A Question For Passpack Users With OpenID

We have linked to a few of the common threats OpenID poses and will talk more about them in the future. Now, I’d like to address one in particular, which has inspired this post and brought up a very important issue regarding Passpack’s support of OpenID.

Let’s have a look at the problem…

Here’s What Should Happen:

You type your OpenID into Passpack. Passpack directs you to a 3rd party – your OpenID provider. Your OpenID provider authenticates that you are who you say you are and then redirects you to the Passpack Anti-Phishing Welcome Message Page. You verify your welcome message, click on the black box and then you are asked to type your Packing Key.

Here’s What Could Happen:

(*For all intents and purposes, we will call the Provider in this example “Malicious Provider”)

You type your OpenID into Passpack. Passpack directs you to a 3rd party – your OpenID “Malicious Provider”. Your OpenID “Malicious Provider” realizes who you are and where you would like to login to – in this case Passpack. The “Malicious Provider” then redirects you to a fraudulent copy of the Passpack Anti-Phishing Welcome Message Page (so you would not see your anti-phishing message). Let’s say you somehow don’t notice that you’re missing your anti-phishing message or perhaps you have’nt set one up yet (set it up!) – so you click on the black box. Then you type in your Packing Key and in doing so you have just unknowingly given it to the “Malicious Provider”.

Always, always, always check your anti-phishing welcome message. It is there to protect you. If you do not see it immediately CHECK THE URL and make sure it is https://www.passpack.com. If either one or both of these do not match up, follow the steps on this page.

How Can This Risk Be Avoided?

First off, it’s important to emphasize that before creating an OpenID account, you should always do your research, check implemented security features, and if all this is not common practice for you – go with the brand you know.

It is probable that a single user will end up with various OpenIDs from multiple providers, some well known and some not.This is where things get tricky. With the growing number of OpenID providers, phishing scams are an immediate concern. It will become more and more difficult to understand the intentions of lesser known providers.

If you want to login to Passpack (or any site for that matter)  with a lesser known OpenID provider and that provider is actually a Phisher, you can find yourself in a difficult situation. (I by no means intend to imply that lesser known providers are Phishers. This is purely an example of a possible security concern and I use the lesser known sites as a prime example only because it is more difficult to verify their credibility.)

Passpack’s Question To You

Passpack has decided to create an OpenID Whitelist (which we are still putting together). This means that we will only be accepting OpenIDs from certain providers. We know this may be an inconvenience to some of you, especially if you are using an alias OpenID, a work administered OpenID or just an OpenID that you have created for yourself.

For example, if Francesco were to try to login to Passpack with his OpenID openid.sullof.com/me, he too would be denied. So the question is:

What Would You As Our Users Prefer?
A. Passpack recommend and accept certain OpenID providers and allow no other providers.
B. Passpack recommend and accept certain OpenID providers and any others should be used at your own risk.
C. Other suggestions?

UPDATE: Some great ideas in the comments. Keep them coming!


21 responses to “A Question For Passpack Users With OpenID

  1. I think it should be B; A would be too closed. Perhaps there should also be some sort of reviewing mechanism for unknown sites, where a site can be reviewed (either by the Passpack people, or a peer thing) and either black/whitelisted accordingly.

  2. louisevinciguerra

    Great! Thanks for the quick feedback.

  3. Definitely not A, since people actually setup their own OpenID server so that they are more secure, A’s philosophy kind of goes against that.

    How about an option where if you’re going to use a non-approved OpenID server, you’re require to use a browser that has anti-phishing capabilities? Plus the usual warnings all over the place.

    Maybe an approval process for non-approved servers, something manual or linked only to your account.

    Maybe require a randomly named (passpackjk2k32jk23lkj.html or something) file in your OpenID server’s root directory?

  4. Take a look at what HealthVault.com did. They only allow certain OpenID providers (Verisign is one of them).

    Personally, I think you should let people pick and you should recommend providers.

    I think the best OpenID providers will shake out over the next year or two.

    Verisign has a numer of novel features like Dual Factor auth via any of the Verisin FOBs and supports one time SMS codes in case you don’t have your FOB.

    One question for you, will you support delegation? So that I can use my own domain to sign in if I delegate to Verisign?

    Also you should think about protecting against man in the middle attacks by requiring that the delegation use SSL.

  5. louisevinciguerra

    What about something like this?

    For people who set up their own servers, we could require (as TB suggested) a Passpack selected .html file to be placed in the server’s root directory.

    This would verify the user/server relationship.

    This means that particular OpenID server would be authorized for that account only.

  6. I agree, definitely not A. If a provider is adhering to the standard, then it’s not your place to NOT acknowledge it. That’s why standards exist (whether it is a formal one or not).

    B is ok, but I think the best option is C.

    My suggestion is this. Have an icon/picture that Passpack stores and presents to the user on the anti-phishing page instead of the black box, or on the same page, have the image in the corner.

    Since the image would be one that Passpack stores on it’s servers, the only way a phishing website could get it is if the security on your servers was compromised and the security image leaked.

    This way, you make it MUCH easier for the user to determine if it is a phishing attack or not (having them check the URL and other little things is too much to ask of them).

  7. Regarding your suggestion about requiring a file on the server, that’s just too much to ask. Delegation is a valid part of the OpenID protocol, and appending the protocol to reqire the use of an extra step/file isn’t Passpack’s call to make (I delegate as well, and I don’t want to have to put one file on my server just to accomidate one site).

    It sets a dangerous precedent, because then every provider that uses Open ID could require a file or extra step, and then I have to have separate, possibly disparate steps for EVERY site I want to use Open ID with, which then defeats the purpose of Open ID (which is to provide ONE point of entry with the same steps, not different ones for each service that wants to use the provider).

  8. Not A. Eventually I want to set up my own OpenID service and I don’t want to be shut out by some reviewing service.

    I like the warning for B, but how about a passpack setting that allows me to specify the open id server that is allowed for my account? Something like “I know this is not a ‘certain OpenID provider’ but I want to allow it anyway”

  9. The random file in the root thing has been around for a while, I know Google uses it for their Analytics (or was it Sitemap, I can’t remember) verification. Or maybe best of both worlds, if no file, then warnings everywhere and all the time, if the file exists, then it’ll be just like using a “verified” server.

    I do agree on the fact that it isn’t PassPack’s call to decide which OpenID server is better or not, even if just for security’s sake.

  10. Hmm… I too think that B is the best choice, provided that you make VERY CLEAR that there is a whitelist somewhere and those are the OpenID providers that you strongly suggest.
    Even better would be if you would keep this list dynamic: that would make PassPack a point of reference for security and trusted providers. Ultimately, the decision should still be on the user side.
    Also, I disagree with putting a file on the website:
    1. As Nicholas said, it’s against OpenID philosophy to require you an extra step for each website you want to login to.
    2. I for example run a small openId provider that is actually open to the public (http://id.bzaar.net). In that case the one account per domain solution would fail.

    Finally, let me tell you how proud I am that you’re supporting openID :)

  11. Thor Marius K.H

    option D: Check every site against the PhishTank database using their API, if positive, deny, if negative, accept.

  12. GrrYumYum

    For me option B would be the most appropriate option, since A is way too restrictive.

    As for the welcome message, it is completely useless for me since my IP address changes at regular intervals. An image, as previously suggested by Nicholas Paldino, would serve the purpose much better.

    Yahoo!’s sign-in seal works quite nice by making use of Flash to store the image on the users computer, that way it doesn’t get lost if the user clears their browser cookies, and I’m sure only Yahoo! websites can read and display the stored image, preventing phishing attacks.

  13. Well, looks like the consensus is “definitely not A”. So given that, there’s all the other options and suggestions to look into.

    Some combination of optional file / warning messages / “I know you don’t know me but stop bugging me setting” could work.

    @Nicholas Paldino
    We’ve been testing a bunch of providers, and indeed there are some which appear not to be adhering to the standard. We’ve not completed testing yet, and I would like to approach these providers, but if we’re not wrong in our testing (anything is possible right now) then there would be some providers not on the whitelist because they aren’t adhering to the standard.

    @Thor Marius K.H
    Excellent point.

    @Nicholas Paldino & @GrrYumYum
    RE: Our welcome message. Yup, we’re looking into better solutions. The current technique is hard for folks to understand.

    Thanks everyone! Keep the suggestions coming – it’s incredibly helpful.

  14. @Omar Shahine
    Yes, we will support delegation.

  15. @Thor Marius K.H
    I just tried the PhishTank’s API. We will support them. Thanks.

  16. In general I think creating a whitelist for OpenID providers is a bad thing. It sets a bad precedent and creates lots of problems for people who want to run their own provider, use delegation, or just are not using a provider on the whitelist.

    There are known bad providers out there, and I would suggest using a blacklist and services like PhishTank.

    With that said a list of providers that you can recommend to people who are interested in OpenID, or want to know which one they should use, would definitely be useful.

  17. @Tara

    I’m fine if they don’t adhere to the standard, but in that same spirit, you should adhere to the standard as well. Having some other page that the user is required to put on their site to allow delegation is not in the spirit of the standard.

  18. @Kevin
    Can you point me to the known bad providers? Are they all on PhishTank or are there other resources available? Thanks!

    Touché! I think Francesco is working on delegation support right now.

  19. Pingback: Passpack’s Whitelist…It’s Unanimous « Passpack Blog

  20. Pingback: Passpack And OpenID: Under the Hood « Passpack Blog

  21. Pingback: Passpack Blog » Passpack And OpenID: Under the Hood

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s