Slashdot Mirror

← Back to Stories (view on slashdot.org)

Analysis of Passport Flaws

Posted by ryuzaki0 on from the something-to-think-about dept.

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.

1 of 174 comments (clear)

  1. Browser-based security model by Old+Wolf · · Score: 5, Interesting
    I have some experience to draw on here. While developing an internet-based payment system, I had to evaluate various security scenarios. The payment system is a server (Apache+PHP :) with connections to a transaction switch which is connected to a bank; a Merchant shopping site will redirect a customer to the payment page, who will make their payment there, and return a success or failure flag to the Merchant. The Merchant will tally up cash with us or with the banks in their regular settlement.

    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.