← On Comment Spam ↑ Bayesian filter for blog comments →
Here’s a proposal for a low tech, de-centralized, remote authentication system with profile management. It’s aimed at all those low security situations where you need to login to a website but don’t want to go through the hassle of creating an
Original article: Simple External Authentication or Single Sign-on for the rest of us
Amen, I’ve been looking for something similar as well. It doesn’t have to be Fort Knox, but ideally would be easily implemented into an existing site with requiring an advanced degree in PHP.
Posted by: Darren on September 23, 2003 05:16 PMThere’s a way to do (roughly) this that would be pretty simple. You would implement it as a browser plugin.
The plugin would look at each page after it has rendered, and search for input type=”password” fields. Whenever one of those fields receives focus, it would override whatever the user enters (either on entry or on submission — it doesn’t really matter). Instead of sending the site the password as the user entered it, instead the plugin would hash the user’s password against the site domain name, and send that instead.
Why does this work? It allows the user to remember only one password, but it changes the password for every web site. For instance, if I enter my password ‘secret’ for Amazon, eBay, and Wells Fargo, those three sites would receive three *different* passwords for me (‘secret’ hashed against www.amazon.com, ‘secret’ hashed against www.ebay.com, etc.), and a compromised password from Amazon would not work at eBay. Using a well-known hash algorithm (MD5, whatever) would mean that the same password would work through different browsers, on different platforms, and on different machines.
For the user, it would mean that they could enter the password once in the morning, and the plugin could automatically fill in every input type=”password” field for them. No central server, no changes to the web sites for which this can be used, nothing but a browser plugin. Easy adoption cycle, and it leaves the user in control of their own ‘passport’.
(There are some problems with this idea: making sure the user can match www.amazon.com to amazon.com; dealing with passwords where the site implements a length limit and does not reveal the length limit in the input field, but instead only after submission; coping with sites where more than one authority resides under a single server name; etc. I think, however, that these are all solvable one way or another.)
Anyway, I’d love to see this done. I thought about doing it as a shareware-type download but I don’t have the time.
Marc
Posted by: Marc Hedlund on September 25, 2003 10:32 PMThe one problem I see with this, is that every site which claims to support it will have a chance to see your username and password. Then the operator of that site can log in on any of the huge number of sites pretending to be you, and flub with your profile, or post a message as you, etc.
I know the security is not meant to be super-duper, in essence you just want a unique-id that is shared across websites to allow people to have their own profiles easily. You want one site to ask another site, “is this guy logged in at your site?”, and if the answer is yes you act as if they’re logged in at your site.
A better way to do it I think would include using cookies and redirects, and using the client browser as a relay for some of the information that needs to be exchanged.
Instead of site A asking site B “is this username and password correct” it would go like this:
Client enters “user@sea.B.com” to log in at “A.com”, without including a password.
Site A tells site B that user@sea.B.com wants to log in, from IP address blah. This is all via rest/xml-rpc/mime-rpc/soap pre-defined or discoverable interface. B tells A “ok, redirect to this URL C (on site B), and here’s a cookie X”.
Site A saves the cookie, and redirects the client to C, including a new token Y from site A in the parameters. B can easily check if the client is logged in (via cookies) or ask them to log in.
Then Site B tells site A directly that the user at IP address blah with token Y, username and profile is valid, and the cookie i sent you originally was X.
Site A tells site B, ok redirect the client to this URL Z.
B redirects client to Z on site A, where the client is auto logged in, and the profile automatically generated.
The benefit is that all of the “login” stuff is handled by the authority site, and the user’s password is never passed through a third party. And it could happen seamlessly if the user already has a login cookie from the authority site. The auth mechanism on the authority site can stay exactly the same, and use the same cookies as they have right now.
You could also do this purely with redirects, and no server-2-server communication, though it would be spoofable. Again it depends on how much security you want. But even then, the “attacker” would have to spoof every site he wants to log in as you, and he would never be able to log in to the authority site. I guess if you do it this way, then you might have a 404 or other error on the redirect to the site B, and have no way of knowing (on site A) that there was an error.
Posted by: gws on September 26, 2003 09:11 PMSlashdot and related sites (OSDN) have been doing this for a long time. Kuro5in also is linked in. e.g. I am ‘agentk’ on /. so i can log in to Kuro5in or freshmeat as ‘agentk@slashdot.org’ etc.
Browser plugin? Ewww
Posted by: reed on October 2, 2003 01:58 AM