Slashdot Mirror
Analysis of Passport Flaws
An anonymous reader sent us an excellent (and technical) paper describing problems with Passport its not lame anti ms rhetoric, its actually a well written technical assesment of security problems with the unified login that passport aims to achieve. This is a good read.
It might "be nice," but for whom?
Why does this info need to be on an external machine at all (other than helping Microsoft or government bureaucrats)? A browser (or an add-on) could do all that with a locally encrypted database (which can be copied or synchronized with, say, your laptop) and you don't have to expose your personal info and browsing habits to some central agency to collect, track and correlate. It need not essentially be any different than the list of bookmarks bookmarks or email addresses we already use. If you have multiple machines, you copy your bookmarks or email address book to other machines.
The commonly parroted "Passport rationale" could be equally applied to browser bookmarks or email address book and, if it had any merit, we would already have our bookmark lists and email address books on the Microsoft servers to use as they wish. We don't keep them there. And the same will apply to the Passport scam.
So, could you explain, where is the gain for the user (not Microsoft or government bureaucrats) in keeping personal info on Microsoft servers, and how does that same reasoning fail to apply to your bookmarks or email address books.
And that was the point.
Now you can't discuss the weaknesses you find in an open forum so they can be addressed. You can only discuss it illegally through encrypted e-mail with others who will exploit them.
The DMCA was NOT an improvement.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
..if the proper privacy and security issues can be addressed.
The inherant problem with this technology, however, is that in order to have a secure, single sign on, somewhere there has to be a database, accessable to the internet in some fashion, which has the username, password, and private information of whoever wishes to use it. There's just no way to get around that. And no matter what platform this system is running, there will be never ending attempts to bring it down or r00t it.
Plus, i don't like the idea of my private information being the property of a corporation.
~z
sig?
There's nothing particularly wrong with single-signon, just so as long it is done securely and the data of everyone on the planet isn't stored in one bank. Users are going to like the convience that Passport provides. Thus, we need a good alternative.
I found this, which discusses a way of doing a Passport-like identification over Jabber, dubbed "Jident". Maybe this, or something like it, could be implemented as a proper open-source/distributed counter to Passport.
Jabber is definitely what the world should be using instead of this new "Windows Messenger". Perhaps an alternative to Passport could be added/layered to it as well? Definitely check out that Jident page, especially the bottom where it lays out the pros and cons (and a neat scenario).
Maybe something like this will be discussed at JabberCon.
-Justin
Many people agree that this is the start of Microsoft's goal of "collecting a toll on every transaction on the internet". As others have suggested, upcoming versions of MS server software will make it easier and easier to use Passport when building web services. At the same time, they will make it harder not to use it... Adding more hoops to go through to set up something else... Like how they are removing Java from XP: one more hoop to to through to run Java.
As you can see, any security flaws in Passport could become a huge problem. Couple this with things like Sircam and CodeRed worm, and you have something that could drain bank accounts and do stock trades for you.
-- these are only opinions and they might not be mine.
How would this be used for authentication? I generate an instance of a hard problem, P, along with a claim, C, which I only I can prove. I publish (P,C) as a type of public key. If I want to prove to slashdot or Hotmail that I am me, I use a ZKP to prove C thus authenticating myself. Since I used a ZKP, even though slashdot now knows C is true, slashdot doesn't know how to prove C itself. So slashdot can't pretend to be me when talking to Hotmail (unless slashdot can factor or solve my chosen hard problem).
Some benefits of using a ZKP include:
So my question is why doesn't MS use a zero-knowledeg protocol to implement passport? Is this type of idea patented, or are there are other issues such as security, speed, etc.? I'm not trying to bash MS since I know that they have some pretty smart people there I'm just trying to find out why they didn't use ZKP.
I suspect the answer is because a ZKP based system would probably be easy to clone by open source people or other companies. On the other hand, passport seems to give them significant business advantages at the cost of security, interoperability, elegance, etc.
its = possesive (i.e., belong to it)
...it's not lame anti ms rhetoric, it's
it's = contraction, for "it is".
So:
actually a well written...
Geez. Hire a high school student to proofread or something.
Probably not, but a secure single sign on would be nice, if the proper privacy and security issues can be addressed. I think that XNS has a chance of doing this type of thing better than any of the closed source alternatively like Passport.
Well, my first question is really "Does anyone outside of Microsoft actually use passport for authentication?" Microsoft uses it a lot for MSN Messenger, Hotmail and all its other stuff, which isn't really bad (for Microsoft products that is). However, I have yet to see Passport used _outside_ of Microsoft.
Then, assuming that other companies do begin to use Passport at a significant level (despite no one using it after months of its deployment), there then becomes the question "What happens when Microsoft denies companies access to passport authentication?" For example, what happens if a Hotmail competitor wishes to use Passport authentication for its web mail login? Clearly, Microsoft would be helping their competitor if they allowed it, and acting monopolistically if they don't. That does provide a small problem for Microsoft.
Third is something that the article points out very early on about the very reason people need something like passport. To paraphrase, the article states that people dislike the idea of their online grocery store having access to their online stock trading when they use the same password. This problem doesn't go away with Passport, it is just enhanced. Now, instead of your grocery store having access to your stocks, Microsoft has access to both your grocery store and your stocks, without doing anything but being a middle man authenticator.
But what am I saying? Microsoft is the good guy, who would never abuse its power. That's why its okay for Microsoft to use its powers to "innovate," just like its okay for the US to develop defensive systems that give it the power to launch nuclear weapons without fear of retaliation.
It sounds to me like it means: "This is not the same punditry you've seen before bemoaning MS being the holder of all keys, it is a technical discussion of the protocol/service".
There was no mention of other Slashdot stories. I think it's assumed that Slashdot readers also consult various other sources of news and information (being that most of the stories are from reader submissions and all)
Slashdot has never been about the editing. It's about geeks swapping info/opinions/war stories/etc about the news of the day.
If you want good editing, visit Linux Weekly News at http://www.lwn.net/. Or if you want to bash other people's editing, you can do that, and have the power to rate the story itself down, so it won't get posted, over at Kuro5hin - http://www.kuro5hin.org/
The article mentions the possibility of one registering pasport.com (note the missing 's') to fool users into giving their username/password to the wrong site. A much easier way would be to redirect the user to a URL like this:
r .com
https://www.passport.com/very/long/path@evilhacke
Crafted to look like a legitimate Passport login URL before the '@'. Then, put a passport spoof site at evilhacker.com. Everything before the '@' is ignored, and the user will simply see a long passport.com URL in the address bar. The browser actually connects to evilhacker.com.
So it's much easier than the article describes to trick a user into providing credentials to the wrong site; all that is needed is an SSL cert, a copy of the Passport login screen, and a clever URL...
As the article notes, users won't check the cert (as long as it's valid and doesn't give a warning). They'll just type in their username and password. Even if they glance at the address bar, most users won't have any clue about the '@' trick, and if the URL is long enough they won't even see it.
Over all, I think the article makes a very good analisys of the problems in Passport (or really any central login system).
- Jman
NGWave - Fast Sound Editor for Windows
The first scenario I decided on and implemented was the similar as what Passport is using, but with the 3DES-key optional (so that Merchants with poor web coders could still participate). For the rest of this discussion, I'll only refer to the version with the DES protection.
Also, being a payment system,there was only one ever call and one return with results -- not a login and logout process.
We found that by using various SSL, cookie methods, and so on, we could get around all security flaws, but the downside is that the Merchant has an awful lot of responsibilities, including:
- Verifying, encrypting and decrypting the 3DES keys
- Keeping its 3DES key secure...
- ...which entails keeping its system totally secure from hacking
- Implementing the rest of the protocol to communicate with the Passport etc. server via cookies
- Generating cookies that work correctly in any version of any browser (even getting them to work correctly in one browser is a hassle!)
- Detecting duplicate transactions (for example, J.Hacker does a valid purchase for $1; and records the connection, then comes back later, begins a purchase for $10000, and intercepts the connection and responds with the $1 packet)
and the list goes on. In the end I decided that while it was a security model that held together, and if I were coding for the Merchant I could do it correctly, but there are many Merchants that would simply fail to do it right, and either have it work buggily or insecurely, or not at all, and then blame the system (or the customers would blame the system).It's easy to say "Well, they should do it right," but when you've been in the commercial world a while, you realise just how incompetent many companies are.
In the end, tired of patching up small hole after small hole and writing merchant integration documents, I changed my mind and chose an alternative scheme which may seem harder for Merchants at first, but in fact leaves them as little room for going wrong, even if the transactions run a little slower.
Conclusion? Hack just one of the merchants involved in Passport, grab their 3DES key, and you're in and untraceable (bar the merchant actually keeping valid authentication logs and being able to follow them; in which case the worst that could happen is that they change their 3DES key). The security will deter script kiddies but a hacker with serious skills will have a field day.
The situation without passport is even more insecure because:
- it relies on individual vendors to provide security for communication
- consumers trust these vendors to do so in most cases
- any vendor protocol is subject to the same security risks as passport
- most vendors are script kiddies rather than security experts (i.e. they are quite clueless about implementing proper security)
Any solution that improves the current situation is a step forward. That being said, the real issue is trust and I am a bit hesitant to trust a commercial company with privacy sensitive information (this is not anti MS, I wouldn't trust Red Hat with it either). The only way I could trust a passport server would be if it were protected by laws making every kind of abuse (including using the information for marketing purposes) illegal AND if it were maintained by an organization (preferably governmental) that has no interest in abusing this information. MS fails both requirements.
Interestingly, laws for the first requirement exist in some countries. It wouldn't surprise me if MS would run into legal trouble at some point for violating such privacy protecting laws.
Jilles
Actually, as an abbreviation for "it is" it does.
(In desperate search for a cool