DropBox + PasswordSafe = Good ??

When I read Joel Spolsky’s post about DropBox combined with PasswordSafe I kind of fell from my chair. Apparently he was looking for a way to store his passwords in a safe way and be able to access them on any computer he uses. This is what he proposes:

1. Install DropBox on all your computers. DropBox is a simple tool to synchronize a local folder to an Internet site. It will synchronize the contents of the folders so you’ll have your data, latest version, available on all your computers. Note that DropBox is secured by a username and password send over the Internet (using SSL of course, at least I hope it is).
2. Install PasswordSafe on all your computers. This is an application that creates a database to store and generate passwords. It uses a password to encrypt the database. The usual algorithm is deployed: the password is used as input for a derived key function which is then used to encrypt the database. PasswordSafe can generate long and random passwords for you and helps you enter them into login forms.
3. Store the PasswordSafe database in the DropBox folder.
4. …
5. Password Nirvana!

Joel even suggests to go all the way and change your bank account password to something really hard (like 16 random characters) and store it in PasswordSafe.

Joel seems to think that this is really all safe since he is using long and hard passwords on websites (those 16 random PasswordSafe passwords) and the “derived key function” used to encrypt his PasswordSafe database. Well Joel … I don’t think so. This is a clear case of “security dependencies” or “weakest link” …

Let’s see what I need to do to get at Joel’s really long and hard to guess 16 character password for his bank account.

1. I need to hack into his PasswordSafe database. In order to do that, I first need access to it …
2. I need to hack into his DropBox account. Doing that requires the usual hacking of a username and password on a Internet site. With the DNS flaws and various Phishing techniques that is not even that hard these days. Not to mention that this is worth the effort, after all it will give me access to his bank account!
3. Now that I have his PasswordSafe database, I need to decrypt it. I don’t care a single moment about the strength of the encryption algoritm nor do I care about the valueness of the derived key function. The only thing I need to know is his password. Since I have the database offline and there is no mechanism whatsoever to discourage a brute force guessing attack, this is purely a matter of time. The attack is even undetectable since it happens on my local infrastructure.

Whatever cool encryption and synchronisation mechanism this setup uses, eventually the entire security depends on just a username and password. Since he wanted to protect a password login in the first place (his bank account) I wonder what he actually achieved in terms of increased security.

My first idea would be to say that he has replaced password based security with … password based security. The only that has changed are some extra, but minor, hurdles to hack it all. But I would even go further. He ends up less secure since cracking his PasswordSafe opens up all his accounts for me, not just his bank account, and the overall attack is less detectable then if I would hack his bank account directly.

Addendum … this article discusses the same topic but using different examples:

To use an analogy (certain to spike my readership, even if only till the US political process spits out some other triviality to focus on) you can put lipstick on a pig, but all you’ll end up with is a cosmetically enhanced porker.

Similarly, you can plaster on the lipstick of strong authentication like Tammy Faye but, if you are smearing it onto a pig of an identity proofing procesess, you’ll still be eating the bacon of low assurance …

Ben Laurie’s Capabilities

The blog of Ben Laurie is on my blog roll since ages (well, Internet ages). He often has great and refreshing views on topics like identity, privacy or security. On top of that, the quality of the post has always been excellent. If you don’t have his feed in your reader, now would be a good time to include it.

One of the recent posts was about a paper he wrote on capability based security systems. I knew from university that depending on how you read a matrix mapping users, resources and access rights, it would be an access control list or a capability list. Therefore it looks at first sight as if access control lists and capability lists are semantically the same. You either store the rights on the resource itself and it becomes an access control list (most common example is a filesystem). You can store all the rights associated with a particular user and it becomes a capability list. Perhaps this was a simplification done in the textbook we had but it certainly has a degree of logic to it. As Ben explains there is a subtle difference between the two concepts and although they have a lot in common, they are not entirely identical in terms of protecting access to resources.

A good example of the difference between a system based on access control lists or a system based on capabilities is given by Ben in the paper. In a typical application, when a user needs to safe a file, the user is presented with a Select File dialog. Based on this selection the application will ask the operating system to open the file. Based on the access control list on that file, the operation will be allowed or not. In a capability based system, the Select File dialog could be a trusted component presented by the operating system, similar to the card selector of Infocards in Windows. The selection of a file would result in a capability to open that particular file. The application can then use the capability to access the file. In an access control list based system, the file selected by the user is not necessarily the file being accessed by the application. If the applications intentions are not good, it might decide to open a different file. In the capability based system, this would not be possible.

Ben also states that there is room for both systems: access control lists and capability based systems. Depending on the environment and the specific requirements, one system will be better suited then the other. In particular Ben sees capability based systems as very promising in the context of securing various (semi) executable content in web pages. Examples include HTML and scripted content from foreign sources in a web page. A technique more and more used in social networking sites or personal portals as iGoogle.

Although I agree with Ben’s reasoning (who am I to question his experience and knowledge) there are some points in the whitepaper that I don’t fully agree with. In some of the later examples of the whitepaper, Ben starts to play with capabilities. By wrapping them in security containers (for instance signing) they can be passed over untrusted third parties. Capabilities can also be wrapped inside other capabilities to accomplish further control over the right granted.

In most of the paper, the definition of a capability can be fairly strict: it’s represents a capability, something the bearer can do with a resources (or a set of resources, whatever the capability points at). In the examples later in the paper, this definition does not hold anymore and suddenly widens to mean a lot of things. In section 6.3 (“Proving User Choice”) of the white paper a trusted component needs to pass a user action to a second trusted component. It does however use an untrusted intermediate for this. In order to prevent the untrusted intermediate to play with this, the performed user action is represented as a capability. It depends on the definition of a capability of course, but I have a hard time thinking of “the user clicked on the second image” as being a capability. This is more like a claim issued by a trusted component (the trusted renderer in the example). To me a claim is not a capability.

It is probably a matter of defining “claim” and “capability” of course. Perhaps Ben can shed some light on this?

Single Account without OpenID or Carspace!

In the country I live, Belgium, the various utility providers have discovered the Internet as a place to interact with their customers. Over the last two years I received letters from all of my utility providers (electricity, gas, internet, telecommunication …) that I now can manage my account on their website.

Great! 24/7 I can login to their site and check my current balance, buy more features or do whatever that needs to be done.

Today however, I am running away from them. Each and every one of those sites requires me to register, including creating a new account with user name and password. Not to mention how difficult it often was to correlate my existing products with that new online account.

Almost every time I have to login to those sites, I forgot the user name or password I picked at registration. I do try to keep a single user name for that kind of accounts but that is not always possible due to conflicting rules or my default user name already taken.

Today I realized that I am not even bothering anymore to remember the user names or passwords. Somehow I found a way to use my Google Account on all of them. Instead of supplying my user name and password to that site, I use the following procedure:

1. Surf to the site
2. Immediately pick the “Forgot user name or password” link, I don’t even bother trying to log in
3. Enter my Google email address somewhere (all those sites offer to mail you your existing or new credentials, either based on email address or based on user name)
4. Wait for the mail to arrive in Google
5. Open it, click on the link inside
6. Create a one time password and log in with it
7. Use the site

The only account I have to remember is my Google Account. Now I just wait for someone to write a Firefox add on that automates most of the above.

So if the following companies would be so kind to read up on OpenID so I don’t have to act like a fool with the above procedure: Electrabel, Telenet, Belgacom, Nuon, Proximus, Luminus … and probably others I forgot.

Plaxo and OpenID (Problem 2)

Plaxo upgraded their OpenID libraries a while ago and this gave some issues. Those are fixed now, thank you Plaxo.

Now that I am blogging about Plaxo’s OpenID support, let me start the second problem I have. Each time I receive an invitation to connect to someone I know at Plaxo, Plaxo shows a different URL to identify itself at my OpenID provider (MyOpenID). We are talking long and complex URL’s containing numerous GET parameters.

The result is that the list of known URL’s at my OpenID provider is getting longer and longer every day and Plaxo is already taking up over 60% of that list. The screenshot below shows a subset of this list:

I don’t know if this is by (OpenID) design or not. What I do know is that when I have to accept a site, identified by a long and complex url, requesting my information, I don’t really know if I should accept or not. This makes phishing a little easier to do, just throw a complex URL at the user, he can’t validate it anyway. To make matters worse, MyOpenID layout does not even show the entire URL to me, it clips of in the initial screen where I can “Allow Always”, “Allow Once” or “Deny” and in the list of sites I took action on.

Plaxo and OpenID … fixed!

This morning I tried again to log in with my OpenID. It seems like whatever issues there were, they were fixed. I don’t know what went wrong: was it me, Plaxo or MyOpenID?

Plaxo and OpenID

Since a few days Plaxo has issues with my OpenID from MyOpenID.com. I tried everything but Plaxo always comes back with the error “Unable to verify the specified OpenID: failed to check_authentication().“.

The same OpenID url works without a problem on other sites. The error message:

Is there anyone who knows what is going wrong?

OpenSSO Identity Services

OpenSSO (Sun’s attempt at open sourcing some of there access management solutions) has published a first draft of some Identity Services. It’s a four part article with the first two parts already published: authentication and authorization.

When I first saw this announcement, I was very interested and almost rushed over to those articles. After a first read however I was somehow disappointed. The interface definitions are very simple, a little too simple. The authentication API merely allows you to send over a username and password and it’ll return you some kind of subject identifier. The authorization API suffers from the same faith: feed it a URI, an action and a subject identifier and it will tell you if that subject is allowed in or not.

Everyone who knows something about the specifications and standards surrounding Identity Services, know that there is more to it. A lot more. You can leave stuff out to make things simpler, but I have this feeling OpenSSO has left out too much. Some of the things I feel are missing or not that good:

• Abstraction from authentication methods, it’s just username and password now. Aren’t we all working very hard to get rid of those? What about SAML, WS-Trust tokens …
• Proper countermeasures for obvious threats like replay, message insertion, message modification, message deletion … Please, don’t answer “oh, we’ll just apply SSL to the transport”, that gives you only part of the solution. You do need controls at the message and API level as well.
• The ability to tie authentication to a certain context (just returning a subject identifier leaves that aspect to the calling party). What if I would like to bind a positive authentication to a particular resource? The subject identifier might contain that information, but their specification is very silent on that aspect. For the moment, that identifier is an opaque handler.
• The returned subject identifier is currently used to bind all services together, but the specification doesn’t say how it is protected and how I can verify it’s validity. If these services are placed on the Internet, I see a lot of security holes.
• What about time windows for the validity of the authentication?

And finally, I wonder why these Identity Services from OpenSSO don’t attempt to place a higher level API around what we already have from OASIS (SAML, WS-Security, WS-Trust, WS-SecureConversation …) and Liberty Alliance (ID-FF, ID-WSF …).

Driver’s License to be the Next Debit Card

I just came across this article on Business Week “Use Your Driver’s License as a Debit Card“.

The intent is to use your drivers license for payment transactions. By coupling your license number to your bank account, they make your drivers license suitable for payments. Just swipe it, enter your personal code and the money is transfered. This way the shop owner doesn’t have to pay credit card companies those exorbitant fees and can carry less plastic around in your wallet.

Sounds like a good idea? Yes and no. Yes, since you don’t have to carry yet another card for doing payments. No, because they are overloading the drivers license to do stuff that it wasn’t made for.

We all know the the verification process for the US drivers license is shaky yo say the least on most states. The REAL ID act tries to improve this situation by introducing extra measures. But in the end, the verification process remains faulty. It is just less faulty but still faulty enough. Piggy backing a payment authorization is not such a good idea. You could couple the bank account of John to the drivers license of Jeff. And what happens if your drivers license is revoked? No payments anymore?

Their aim, reducing the number of plastic in your wallet, is worthy. Their modus operandi isn’t. Piggy backing one type of identification and authorization on to another type is often dangerous. Not always bad, but often questionable.

Why not introduce a blank card that can store multiple virtual ID cards like your credit card, drivers license … You just pick and unlock the one you would like to use. That reduces the plastic weight while still separating identities and authorization when needed and when you wish. Sounds like user centric identity in your wallet.