Analysis of Passport Flaws 174
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.
Re:Spoofing Passport Login (Score:2, Interesting)
Using %-encoding would work for hovering over the link, but not what's shown in the address bar of the browser after the link is clicked.
On another note, something else the article mentioned was DNS spoofing. One quick way to do that would be to sign up at some large ISP to host "passport.com", and hope that the signup process is automated. Then, for users of that ISP (or rather for users of their name servers), passport.com would resolve to your webserver, assuming that ISP uses the same DNS servers for both authoritive and non-authoritive requests.
Of course, this would be difficult to pull off, but I'm sure with some creative thinking it could be done. I've seen domains resolve to the wrong host many times due to similar tricks (intentional or otherwise). We once had "firefly.com" (coincidently an MS-owned domain) in our DNS thanks to automated signups for domain hosting; luckily, we only served authoritive requests (we were a webhost, not an ISP).
- Jman
Why not local machine database? (Score:3, Interesting)
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.
kerberos authentication (Score:1, Interesting)
Comment removed (Score:2, Interesting)
Hailstorm. (Score:3, Interesting)
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.
why not just use a Zero-Knowledge protocol (Score:3, Interesting)
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.
Security Flaws (Score:2, Interesting)
This is a bit unusual; most of Microsoft's various 'innovations' are renowned for their user interface, and here we have the interface acting as a potential security flaw.
Who wants to place bets on how long it will take before somebody starts harvesting ID's from the local libraries?
Re: Do we really *need* Passport? (Score:4, Interesting)
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 [xns.org] has a chance of doing this type of thing better than any of the closed source alternatively like Passport.
Not that I was ever going to use it anyway... (Score:2, Interesting)
It seems likely that some if not a lot of people are going to use the passport service outside of hotmail. It seems likely that some or a lot of them are going to regret it. While I don't wish those people any harm, they could be well the ones who bring this latest Microsoft ruse to a speedy end.
Spoofing Passport Login (Score:3, Interesting)
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
Browser-based security model (Score:5, Interesting)
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.
Re:Spoofing Passport Login (Score:3, Interesting)
Oh, and some browsers have already patched this "semantic attack [ebiz.co.za]."
Re: Do we really *need* Passport? (Score:3, Interesting)
- 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.