MoreWhite

A typical web user is subscribed to many services, each with its own username and password combination. Remembering them all can be impossible for many, and we end up using the same combination for many services as a result. This means that if one service gets hacked, it’s all hacked, busted, ruined, sobbing, tears, whatever. [wired: 1, 2]

Single sign-on (SSO) services like Passport have failed miserably, now covering only the Microsoft county. However, a need for a distributed SSO service seems to be growing rapidly. Several people have already started developing solutions, including, last but not least, myself.

Two general approaches seem to exist, as with anything on the PC: server and client side. The server side approach as employed by Just1Key stores your usernames and passwords on some super-bullet-proof-invisible-to-hackers server. The problems are obvious:

1. such servers don’t exist
2. getting people to trust you with their usernames and passwords

If we can assume that the secure server is more secure than the user’s PC, then it seems like the most secure option, at least in theory.

The client-side approach is fairly new, and generates a unique password for each service from your master password and service domain using MD5. An excellent flash movie about it is here. This elegant technique seems to be pioneered by Nic Wolff, who has developed a bookmarklet implementation. A browser extension is also made by PasswordMaker that aims to be more secure. Similar stuff is also available as a GreaseMonkey script for Firefox.

However, the client-side approach seems to be very insecure: a brute-force should allow an attacker to crack the master password knowing just one generated password. Of course, SHA v2 algorithms can be used instead, but the solution is still insecure due to low entropy in a typical password (i.e. its just too short and thus brute-forceable). Techniques for increasing password entropy are discussed here (PDF), and boil down to two approaches:

1. making the password longer by adding a password suplement (stored on the server-side)
2. recursively applying the hash function k number of times

Cracking the second approach involves guessing the parameter k. If this parameter is stored securely and is large enough, than a brute-force attack may take much longer, hopefully making it unfeasible. Moreover, if k = f(password), we do not need to store k at all, whilst making the solution increasingly secure. Note: if f is a secret server-side function, the system becomes really secure.

I don’t discuss any client side software apps on purpose, as I don’t see it as a practical solution – installing an application just to access your usernames and passwords on a different machine isn’t practical, what if you want to surf, smoke and fly in a coffee-shop?

Personally, I don’t see what the big issue is with storing passwords on the server-side. If they are encrypted using the master password, then thats secure enough for me: the master password can only be cracked if both the service and password server are cracked.

How about you? How do you manage your passwords?