Martin Atkins (mart) wrote in apparentlymart,
Martin Atkins
mart
apparentlymart

Passpack: Web-based Password Manager

I've been taking a look at a service called Passpack, which is an online password manager product currently in beta.

Passpack allows you to store your passwords for online services on their servers so that you can access them from anywhere. OpenID is supported as a login mechanism, or you can use a traditional local username and password or another one of those ill-advised "enter your Google/Microsoft password into a third-party site" things. I kinda forgive them for the latter because they support OpenID; presumably if Google and Microsoft offered OpenID Provider service they'd switch to using that instead.

I'm sure I'm not alone in being immediately sceptical about any online service that wants to store my passwords. How can I trust them? Passpack's solution is what they call host-proof hosting; in a nutshell, they do crypto in the browser and their servers only ever see encrypted blobs. You're required to create a passphrase, or a "packing key" as they've cunningly named it, which is in theory only ever in memory. Once you've signed in (with OpenID, perhaps) you need to enter your passphrase to decrypt all of the data. You will of course still need to trust that Passpack isn't going to alter their client-side code to send them your passwords on login at some point in the future; this is certainly technically possible.

Passpack ran into an interesting quandry with their OpenID RP support: turning the tables on the usual OpenID phishing concerns, Passpack's model is vulnerable to an OP doing a phishing attack. Essentially, a malicious OP can detect that the user is logging in to Passpack and present a lookalike page to capture the user's passphrase, thus obtaining access to all of their passwords. Passpack can be commended for going to great lengths to mitigate this without hindering the flexibility of OpenID; after some consultation with users, they went with a whitelist of "trusted" OpenID providers and a warning — which the user can dismiss and continue if desired — if an untrusted provider is used. As a nice addition, rather than simply doing pattern matching on the claimed identifier, they do discovery and then base the trust decision on the discovered endpoing URL. This means that the common approach of delegating to hosted services like MyOpenID works with no warnings..

Some might argue that if a user can't trust his OpenID provider then he has bigger problems than it gaining access to one RP, but when that RP effectively holds the keys to much of the user's kingdom I can understand the extra caution. It is ultimately up to the user rather than each RP to make this trust decision, though; it is unfortunate that this approach considers a provider endpoint run by the user himself to be less trustworthy than a third party, when clearly the user would have the opposite opinion.

Their OpenID login form is similar to the "choose a popular provider"-type ID selectors appearing on many RPs, though they've gone for a very slightly different flow where the user enters their username and then clicks a service button to transform that username into an identifier URL for the selected service. The difference is subtle, but I think it has the advantage that the full OpenID identifier is right in the user's face rather than in a separate box. I would however suggest that the URL be presented in abbreviated form rather than normal form, so that for example users will see "blah.identity.net" rather than "http://blah.identity.net/"; I think the former will look a lot less scary to end-users and will hopefully be more memorable. The transform from the abbreviated form to the canonical form is spelled out in the OpenID specification, so all decent RPs should accept the short format. The providers listed in the selector are apparently those which are on Passpack's provider whitelist, so users of these providers should get a good user experience.

My one closing observation is that it seems strange for a product that is useful only because users have far too many passwords to support a technology whose goal is to reduce the number of passwords each user has. I hope they know what they're doing! ;)

Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments