5 ms·

If this works anything like the QR Code login that Google did a while back[1], you aren't replacing passwords, you're just hiding them (scan code containing tar

by cheald 14y ago

If this works anything like the QR Code login that Google did a while back[1], you aren't replacing passwords, you're just hiding them (scan code containing target site info, send login request with some device identifier from app to Clef servers, perform OAuth OOB on the phone, once authorized, send user credentials to browser via polling JS or whatnot -- in this scenario, the device identifier from the app is your username+password). Worse yet, you're shifting all the login credentials to the mobile device, reducing 2FA to 1FA, with the single factor being the phone. If the phone is compromised, then the credentials are compromised, and this is a HUGE concern, since it's much easier to pick up a phone and walk off with it than it is to pick up a whole computer and walk off with it. The whole point of 2FA is that you have two physically disconnected pieces of input required to log in (user+password on the computer, TOTP code from a mobile device), so compromising one or the other doesn't mean a compromise of the given account. I get and like the concept, but the marketing copy of "replacing passwords" and "bringing 2FA" to everyone seems ill-conceived. [1] http://www.zdnet.com/blog/igeneration/googles-qr-code-log-in-experiment-concluded/14679 http://www.zdnet.com/blog/igeneration/googles-qr-code-log-in...

brennenHN 14y ago
We do not use usernames or passwords at all. A session key is passed in the QR code. An asymmetric key pair is generated on the phone when you create an account, and the private key never leaves the phone. When you scan in the session key, the phone creates a signature using the private key which can be tested using the public key stored on the server. As to the question of two-factor authentication. The first factor is ownership of the device, the second is knowledge of the PIN, which are two different and very real factors. We really are replacing passwords and using two factor authentication, it's not just marketing.
- cheald 14y ago
  First off, I want to commend you guys for taking on the problem. It's an extremely hard one, and I don't intend to be disparaging. Passwords are an incredibly difficult problem to solve, and trying to solve it takes gumption. I love getting individual websites out of the authentication game; delegated auth is a much better solution when it works right, IMO. That said, what makes this quantitatively different from just using challenge-response authentication directly in the browser via a browser extension? Private keys may be password ("PIN") protected, and must be possessed by the authenticating user. In both cases, any compromise of the private key means you're owned. Exploits like the Defcon "charging station" proof-of-concept and the recently-discussed Galaxy S3 DMA hole should make people extremely wary of putting all their authentication eggs in their mobile phone's basket. People will plug anything into their charging-port-that-also-transmits-data if it gives them enough juice to get throughout the day; this is a MASSIVE social engineering problem waiting to happen if something like Clef were to become commonplace. This solves at least some of the problems of passwords (too short, often re-used), but comes with new ones (4-digit PINs are hilariously easy to crack, and can often be guessed manually if a touchscreen is involved; private key theft via malware leaves you in big trouble and you may never know it happened), and I worry that marketing it as a solution to all your password woes is a bit ambitious.
  - brennenHN 14y ago
    Keeping it on the phone means that we don't need to re-generate a new one or transmit your old one when you change computers. You're absolutely right that keeping the data safe on the phone is an important challenge and it's something we're working hard on. PIN-based encryption is the solution for now, but an invisible attack could be dangerous (though the attack's you mention through the USB key require a rooted phone with permissions allowed, which is not common- privilege escalation attacks are one vector which we still have to work against) We think what we have right now is a big improvement over the status quo, and that we still have a lot of room to keep getting better. Thanks for the feedback.

by cheald 14y ago

brennenHN 14y ago

We do not use usernames or passwords at all. A session key is passed in the QR code. An asymmetric key pair is generated on the phone when you create an account, and the private key never leaves the phone. When you scan in the session key, the phone creates a signature using the private key which can be tested using the public key stored on the server. As to the question of two-factor authentication. The first factor is ownership of the device, the second is knowledge of the PIN, which are two different and very real factors. We really are replacing passwords and using two factor authentication, it's not just marketing.

cheald 14y ago
First off, I want to commend you guys for taking on the problem. It's an extremely hard one, and I don't intend to be disparaging. Passwords are an incredibly difficult problem to solve, and trying to solve it takes gumption. I love getting individual websites out of the authentication game; delegated auth is a much better solution when it works right, IMO. That said, what makes this quantitatively different from just using challenge-response authentication directly in the browser via a browser extension? Private keys may be password ("PIN") protected, and must be possessed by the authenticating user. In both cases, any compromise of the private key means you're owned. Exploits like the Defcon "charging station" proof-of-concept and the recently-discussed Galaxy S3 DMA hole should make people extremely wary of putting all their authentication eggs in their mobile phone's basket. People will plug anything into their charging-port-that-also-transmits-data if it gives them enough juice to get throughout the day; this is a MASSIVE social engineering problem waiting to happen if something like Clef were to become commonplace. This solves at least some of the problems of passwords (too short, often re-used), but comes with new ones (4-digit PINs are hilariously easy to crack, and can often be guessed manually if a touchscreen is involved; private key theft via malware leaves you in big trouble and you may never know it happened), and I worry that marketing it as a solution to all your password woes is a bit ambitious.
- brennenHN 14y ago
  Keeping it on the phone means that we don't need to re-generate a new one or transmit your old one when you change computers. You're absolutely right that keeping the data safe on the phone is an important challenge and it's something we're working hard on. PIN-based encryption is the solution for now, but an invisible attack could be dangerous (though the attack's you mention through the USB key require a rooted phone with permissions allowed, which is not common- privilege escalation attacks are one vector which we still have to work against) We think what we have right now is a big improvement over the status quo, and that we still have a lot of room to keep getting better. Thanks for the feedback.