This sounds very, very interesting. I think it would work very nicely. It's easy both for users as for programmers to implement. In fact I think I could implement it in something I'm currently working on. :D The only thing I was wondering, the username looks like an e-mailaddress (I presume it isn't), won't this be confusing for some users?
Manuzhai
· 4 years ago
First: there are already other more simple solutions out there, for example openid.net. Your proposal is interesting to consider from a comparative research point of view, but that's about it.
Second: I think an important part of having single sign-on is not having to give out my password to every single service I sign up to. In your proposal, my password is travelling through their service. Now, if I also use this account at any other service, the first service has both the username and the password, so anyone from any of the services I am subscribed to can impersonate me at any of the other services.
Great idea! If I ever complete the forums from your other idea, this will be part of it :)
Zef Hemel
· 4 years ago
Manuzhai, about the travelling password, that's very true. I hadn't thought of that...
Cow
· 4 years ago
Sounds very similar to Drupal's distributed login.
David
· 4 years ago
Have you looked at OpenID and Lid yet?
Bas Westerbaan
· 4 years ago
It can be done way easier and way more secure:
Everyone should have their own RSA-like keypair. The only thing that has to be done to authenticate you is to challenge you to prove that you got the private key alongside the public one.
Lewis
· 4 years ago
What happens with clashing usernames? Surely people could just change data and get any username they want?
Bas Westerbaan
· 4 years ago
I guess that every user has their own username on the final application like a message board. But their identity would be a public key; and best would be combined with an username@keyserver, which is easier to work with.
Sam Gamyi
· 4 years ago
Interesting idea. For the travelling password problem, maybe it would be good that the system generates a unique -random- password for every signup. So if forum "A" is unsecure and some script kiddie is able to know my password in this forum, that would be useless for gaining access to forum "B", since the password would be different for that other forum. (Sorry for my bad english).
Shane Bauer
· 4 years ago
Not a bad idea, I don't think this would ever work, especially with the password problem.
The only way I could imagine this would work is that each "login" site only asked for a username (i.e shane@zefhemel.com). That single site could then parse out the server and redirect them to the profile host where the user then types in the password. If successful, the profile host sends a response back to the original site containing a confirmation ID and username. Then some sort of verification code would need to be executed to ensure the confirmation ID was legit.
Basically, it would work almost exactly like Passport, as login sites don't actually work with the username/password, but without a centralized server.
Then you have to worry about login box cloaking and all sorts of other fraud activities.
Bas Westerbaan
· 4 years ago
You don't have that problem, when - as i suggested already - use public/private RSA-like keypairs and you just challenge someone with a random string that can only be decrypted by you (the owner of the private key). There wouldn't be any login box required - as we know it.
Shane Bauer
· 4 years ago
Ok. Well, fine. Just make it reliable enough so that people don't have to ever worry about public and private keys.
Bas Westerbaan
· 4 years ago
The problem is how to implement it with HTTP and HTML when a client-side RSA computation is required. Javascript isn't really an ideal language to do a RSA computation in. It would require activeX, flash or Java.. which isn't really 'complient'.
All Comments
The only thing I was wondering, the username looks like an e-mailaddress (I presume it isn't), won't this be confusing for some users?
Second: I think an important part of having single sign-on is not having to give out my password to every single service I sign up to. In your proposal, my password is travelling through their service. Now, if I also use this account at any other service, the first service has both the username and the password, so anyone from any of the services I am subscribed to can impersonate me at any of the other services.
Not good.
Everyone should have their own RSA-like keypair.
The only thing that has to be done to authenticate you is to challenge you to prove that you got the private key alongside the public one.
The only way I could imagine this would work is that each "login" site only asked for a username (i.e shane@zefhemel.com). That single site could then parse out the server and redirect them to the profile host where the user then types in the password. If successful, the profile host sends a response back to the original site containing a confirmation ID and username. Then some sort of verification code would need to be executed to ensure the confirmation ID was legit.
Basically, it would work almost exactly like Passport, as login sites don't actually work with the username/password, but without a centralized server.
Then you have to worry about login box cloaking and all sorts of other fraud activities.