This is a proposed auth mechanism that embeds an URL + nonce in a QR code, which a smartphone signs and posts back to a server to authenticate the user. A single master key in the phone reproducibly generates a private and public key per hostname. The server uses the pubkey as a userID and checks the signature. If the sig validates, that pubkey either already exists as a user on the server, or a new user record is created. Presumably then the server posts back to the desktop browser (websocket? long poll?) to move past login once the phone auths to the server.
Pretty cool, and the article addresses many of the obvious criticisms. The advantage is that it uniquely identifies the user without a password or email verification. But as a downside vs. a competing system like BrowserID is just that it doesn’t have an email attached, so the server may still need to do an email verification if the user wants to tie a global identity to the per-site pubkey.
Originally shared by Abraham Williams
I heard the intro on Security Now the other day. I think the big potential weakness is in verification of the url. You may be looking at a site called “facebock.com” and the app will notify you that you are looking into “facebook.com“. Behind the scenes the portal that presented the QR code has obtained that code from its own session with facebook, and when you verify with your signed response the app is successfully doing a man in the middle attack. Based on that one letter difference (c vs o) you are now compromised.
Even worse, creating a fake page on the same domain, for which this method will offer no protection. Any site with authoring tools is potentially dangerous.
Christopher De Vries Good point. The part I don’t get is why this has to be tied to a smartphone. If implemented as a browser plugin, then the software can guarantee that the QRcode domain matches the site domain. That would make it closer to BrowserID in user workflow (no camera needed).