Re: A new type of phishing attack
Guido Witmond <guido-EBfTt96odT/[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
On 09/13/14 01:03, Sandro Magi wrote: > If some authentication step is required to obtain your root cap URL, > this attack could still be successful against enough people to make it > worth the effort. I don't think webkeys alone would suffice, unless caps > are all that a user has, so a login prompt isn't even an option. As long as people provide static credentials (like a password) to a remote end of a socket, the phishing problem stays. Taking the login prompt away from the html page and into the browser is a good thing to do. 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. 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. It's the *user agent* that need to make sure that it is connected to the site for which the capability is valid when it wants to *invoke* the rights. The capability needs to include some information that allows the user agent to verify the identity of the server before it hands over the capability. The server needs to identify itself to the client. When the endpoints' identity doesn't match the identity specified in the capability, the user agent refuses to hand it over. To implement that, each system that creates capabilities has a long living private key, the system adds the hash of the public key to the capability at the time it creates the capability. Whoever has possession of (a copy) of the capability has the option to check the identity. It solves the tabnabbing attack as it is the user agent that verifies if the current endpoint (that looks like gmail) can produce a proof of possession of the private key that matches the identity in a capability before handing it over for invocation. The user may be confused, their deputy isn't. Guido. _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk
signature.asc
(application/pgp-signature, 897 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJUFBHLAAoJEHPd8GglaNRmFCgP/jV1MIfSgr/QWit1KkXzzSi+ WKeUWesKH3/aVPdudqSXA2YgGsBB/ReYLecGd4kXmUB/y38kFT4D1yU8QhCL05a4 w/kzTU1Q9Aqg5dB/Bap/9YJhr+UqaMs83rKbsGLJPN5DNNTIYqeyKj5ltP17NarV +p7zXvgM6jxWo2Sp6oXOvjfADNeB1l1CFUrG8qgksinPtwclRThpdOCneTHwBD3X TZE9qJqWQj4xP50p30wTN7LQ1F3rwWWq8M9103/oiG73oFXqxesweKSu7CZIjbM7 pTuinYum3tLpZqGmhopaXaP6Zu6VEqH1s8w/v21Mp8sCMuQxNJTQ4a01v0TwjYNO JYi/NYR2/DBMAGDAhnBOYEi/xHIxWorxB5yj/wxwdoKQCEhDxYE8nk9GKY+ALPU5 XEENCBFMjxqRVnjIi0e3aEyiEdyE5vs3nEb/vD6KTNshBWXQ42DggQ1jPQLWQUIu ycL5H/T3Eiwb8stQEX5S+cgPeklGUx6bPrbqKjd9k4r/EAOeX3gCs+O9teeaQv4/ xuiZfVV5q1r8/pjo9iiwtSx/JY8eAvgNBwQr0CyLoOEYwl/HVSwEAf9w7jCx+/sf oUWxsG/yjM+RQpcUvEfiimGmu8JaNxc6IrXT1ejels6RZuFfoHPiP1X/8V/Zrf5H U6vzsrSjOr3PI9zVMHuH =wpGj -----END PGP SIGNATURE-----