Re: A new type of phishing attack
"Stiegler, Marc" <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <63601DC9100AAC48812C1985727F34485C93BED0@G9W0727.americas.hpqcorp.net> |
"As long as people provide static credentials (like a password) to a remote end of a socket, the phishing problem stays." False on both counts. A static credential embodied in the webkey defeats phishing (uh, you actually have to define phishing more carefully than, "all possible ways to get a credential"). The implication in focusing on static credentials as above suggests that one-time-only tokens supply protection from phishing. Already proven to be false. The real problem is that the credentials, however static or unstatic, are loosely coupled to the site where they are meaningful in such a fashion that the work flow in surrendering the credential to the attacker is humanly indistinguishable from the work flow in getting your work done. "Taking the login prompt away from the html page and into the browser is a good thing to do." Yes. Login prompts are losers from both usability and security perspectives. "A capability is a static token that can be copied. Once copied by someone who you don't intend to have it, it is game over." True, but the major problem we have today is, we have convinced ourselves because of numerous other bad architectural errors that it must necessarily forever be trivially easy to snatch someone's token. If we grant this assumption, nonstatic tokens still don't fix the problem, they still get stolen. We have some fundamental work to do here. "What we need is a way to make sure who is at the other end of the socket before handing over the capability. So far, we have delegated the task of identifying the endpoint to the user. And those humans have done a lousy job." Also true. The webkey approach uses https to ensure we know the endpoint. --marcs