eBay Retires MS Passport Sign-In 304
fihzy writes "eBay have announced they will retire Microsoft Passport Sign-In and .NET alerts. The Microsoft Passport Directory of Sites has been discontinued, too. Is Microsoft's Single Sign-On vision edging towards oblivion?"
Re:well (Score:5, Interesting)
Yahoo's going strong (Score:4, Interesting)
I actually used it (Score:5, Interesting)
Eventually, I got a new login and walked away from one with 20 favourable reviews on it thanks to that damned system. Hope it fries in hell.
Is the only paid use going away? (Score:2, Interesting)
Those are currently being transfered to the developers in-house system.
In a couple months that use will be gone too.
What does that leaving using it? Hotmail?
I never even linked my ebay to one of my
Nice idea but only handy if it filled out everything for you on lots of sites, which i dont think i'd like the idea of anyway.
No one trusted Microsoft on this (Score:4, Interesting)
When it arrives, single sign-on is going to have to come with some bill of rights for users...I don't see MS providing any level of transparency.
Re:well (Score:2, Interesting)
Re:well (Score:3, Interesting)
you wouldn't like to look/be responsible for a system you don't have the keys to, it's quite hard to fix things that you can't access even.
Re:I actually used it (Score:5, Interesting)
On top of that I used their hotmail account to register for the Passport, since that's their recommended option. I never use Hotmail for my daily webmail, in fact, the only message I have there is a thank-you for signing up. The bozos from hotmail kept threatening me with turning off the account, and they did execute their threats every 90 days. So unless I remember to log in to the Hotmail account, which I never use, I lose my passport, and have to go through easy but still frustrating retrival system at hotmail.
The guys who designed this system are probably competing with Clippy team on who builds the most annoying product.
It never worked anyways, and eBay didn't care. (Score:3, Interesting)
I tried to use it multiple times. I'd be logged into MSN, MSN Messenger, reading hotmail, and in some new window (using IE, even) I'd try to log into eBay and, nope, same page, repeatedly, asking for the username and password.
I'd have liked for it to work, but I don't think anyone at eBay ever actually cared whether it worked.
lol $10,000. a ROFLMAO Year? (Score:4, Interesting)
What they were asking is like holding the door open for someone then asking for a hundred spot.
Passport not only had security flaws, but would be the biggest target ever imagined for phishing scams. Its funny too because the passport URL was so long that you didn't even see the www.microsoft part. You could have sent them to any site to login, and just kept their login and passport.
Microsoft failures are great for jokes.
Re:Bad idea, implementation irrelevant. (Score:4, Interesting)
That is what I call bad implementation, if done right this whole thing would have worked via smartcards. Have a key stored on that card and encrypt the login information on the card itself, don't store any information on the computer itself. Would have even allowed to move to another computer and login there without risking to get the password spyed away. Good smartcard are ever protected by a pin which you can enter on the card itself, so you don't even need an extra numpad. On the server side all that would be needed would be some standard protocoll to comminucate with the client/smartcard.
Downside is of course that such smartcard reader would have cost a little bit of money, but given that now basically every PC comes with Flash-, SD-, XD- and whatever they are called slots, such a reader shouldn't have ben all that expensive, especially if Microsoft would have backed it up with a little 'force'.
Sadly all dreams, and we are stuck for the coming years with passwords and password managers which basically store everything in almost plain-text on the client...
Re:Bad idea, implementation irrelevant. (Score:2, Interesting)
Now, it's true that Windows is not exactly the most secure system. Indeed, in recent security tests, it was passed by an unlocked door, and a large neon sign displaying the sensitive data.
On the other hand, this is definitely the problem with the OS, and not the idea. If you run Kerberos on OpenBSD or a reasonably secure Linux box, the odds of anyone being able to break the system and obtain access to all sites that acknowledge the same Kerberos domain that you are logged into are pretty remote.
Personally, I think Kerberos is not the best system. It uses DES and CBC for encoding, for a start, and MIT's implementation appears to be hard to modify to support other encryption systems and other chaining modes. I'd prefer a system that is capable of a moderate to high degree of flexibility, as you can't decrypt something if you don't know the encryption algorithm used.
An alternative system would be to log into some sort of server, which generated seed information for a pseudo one-time pad, which could be generated independently on the client and server.
When logging into another server, the previous server passes the pad generating information, plus current position in the one-time pad to the new server. Any other tokens are passed as usual. By passing the pad position, you ensure that ONLY your computer can connect to the new server - no other computer, even if the user has your password, tokens, etc, can do so, because it doesn't have either the pad or the position in it.
Even grabbing the information for generating the pad isn't good enough, because you still don't have the position. The pad isn't re-used, when you connect somewhere else, the pad is always used from where you left off. If N bytes are sent, then the cursor is on the N+1th position of the pad, always. Since the hostile computer cannot prevent the real user's computer from transmitting, the hostile computer cannot ever be certain what N is, and therefore cannot encrypt data in a way the target server will understand.
This means that you cannot transmit to two servers using this system at the same time, and any switch between server has to be explicit to both the old and new servers. Otherwise, the necessary state information can't be relayed properly.
However, it's very rare that you ever are interested in being connected to two servers at the same time, except on LANs or point-to-point multi-user software. You wouldn't use these sorts of schemes to protect LANs anyway, and multi-machine multi-user software should use multicasting, not point-to-point.
Re:nope (Score:5, Interesting)
The only system I know of that fits the bill is the nascent Identity Commons [identitycommons.net] system that is just starting to come online [2idi.com]. (Disclaimer: I am 2idi's CTO)
MSDN subscribers required to use Passport (Score:3, Interesting)
I've got a Passport because of my MSDN subscripton, and it's the only reason why I've got Microsoft Instant Messenger running on my system. But, it NEVER WORKS-- IE is supposed to realize you're signed in with your passport, and let you right on through to subscriber downloads, but that never happens. Everytime, I'm forced to sign in, and then hit the "I Agree" button to the MSDN Subscriber Agreement each time, as if I'm signing in for the very first time, every time.
Sure, that might be lazy to not want to be hassled by those few key/mouse clicks, but if you're going to implement a feature and then require your subscribers to use that feature, at least make the feature work. After all, that was supposed to be the reason for Passport integration into XP, right? Just sign into Messenger, and then you'll be recognized at any
Re:Edging into oblivion? (Score:5, Interesting)
The worst thing about Passport and the related
In retrospect, Microsoft made a bunch of mistakes:
1) The whole thing got muddled in the general confusion of
2) Most other web companies actually valued control of their user data more than ease of development.
3) No user demand for single sign-on, either because users don't care, or because they actually value their privacy and don't want different websites to share user data.
It's finally gone. Good riddance.
Re:I actually used it (Score:1, Interesting)
Does anyone understand Passport? (Score:4, Interesting)
Once you understand how Passport works and would work in the future, it is so clearly a horrible idea that it is not funny. People often only think of it as a central repository for storing their passwords. Some like this idea for its convenience but the Passport model is so half-baked it is not even funny.
If you want to understand how a truly well-designed system will work, take a look at the Liberty Alliance. Instead of the central repository method, it uses a federated approach to the problem.
For example, if you have a bank account, a utility provider, and your employer, there is no need for those three entities to share all information about you. It should be up to you to define which information is shared, but you should only have to maintain it in one place.
If your employer knows your home address, why not allow this data to be shared automatically to the other entities? Don't want to? Then you don't have to. You employer may know your bank account number to deposit your salary. Your utility provider may know your bank account number to deduct your monthly bill. Why not tell your bank to share this information with your employer and utility provider? If you change your bank, then your new bank will automatically update this information.
Of course all of this has to be done in a secure way. But it is more likely that your bank will have secure connections to other entities than the layer where you inform those entities yourself.
Best of all, the approach from the Liberty Alliance does not leave one vendor with the master key. The keys are still with you, you just might give certain keys to some of your vendors.
Re:Does anyone understand Passport? (Score:3, Interesting)
I did not say that Passport sent passwords to the third party sites. I said that people think of Passport as a central repository for storing their passwords. By implication, I was pointing out that this is incorrect.
Yes, Passport authenticates you by sending a secure token to the third party and the third party trusts Passport.
My point was that the Passport architecture is inherently flawed because it allows an independent source (the Passport system) to authenticate you to the third party. The third party then assumes whoever Passport just authenticated is the full user. That is a flawed architecture because it uses a centralized trusted source for authentication to all third parties (at least, that was Microsoft's goal). The third party no longer has any restrictions on accessing it once Passport has authenticated. The problem gets exponentially worse as more systems use Passport.
Take the scenario where Passport is breached. Any system that uses Passport is therefore breached FULLY at the user level. A federated system, on the other hand, still has restriction about what can be supplied and shared between systems. In addition, there is no central system to breach. There is no master key. It is only a web of systems sharing information as defined.
So technically Passport does not store passwords, but it might as well. The result is the same.