4 ms·

Our goal is to get rid of passwords entirely. It is becoming more and more obvious that our memories are no match for raw computational power and clever social

Our goal is to get rid of passwords entirely. It is becoming more and more obvious that our memories are no match for raw computational power and clever social engineering, and that we need to be securing our identities with a much better mechanism. With the passwords you're talking about, a malicious site would gain access to all of your accounts as soon as you created an account with them, which is one of the major problems with password reuse today. As to Windows Phone support, it is definitely behind Android on our priority list, but it's something we are working on and planning on releasing as soon as possible.

jetti 14y ago
"With the passwords you're talking about, a malicious site would gain access to all of your accounts as soon as you created an account with them, which is one of the major problems with password reuse today." First they would need to know the scheme. Second, one wouldn't haven't to follow that schema at all, you could use something simple and easy to remember for each site. Also, as I don't know the implementation behind this, but couldn't a malicious site do the same with clef with a man in the middle attack (as stated elsewhere in the comments)? Another question: how would mobile browsing work? If I wanted to log into one of these sites on my mobile device, how would I do that?
- brennenHN 14y ago
  This is a feature which will be out with our next release. When we detect the visit from a smartphone, we change the QR to a button, and when it is pressed we redirect you through the app, where you verify your PIN, then redirect you back to your browser where you are logged in.
  - jetti 14y ago
    Pretty spiffy. Good luck with your product!
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.

jetti 14y ago

"With the passwords you're talking about, a malicious site would gain access to all of your accounts as soon as you created an account with them, which is one of the major problems with password reuse today." First they would need to know the scheme. Second, one wouldn't haven't to follow that schema at all, you could use something simple and easy to remember for each site. Also, as I don't know the implementation behind this, but couldn't a malicious site do the same with clef with a man in the middle attack (as stated elsewhere in the comments)? Another question: how would mobile browsing work? If I wanted to log into one of these sites on my mobile device, how would I do that?

brennenHN 14y ago
This is a feature which will be out with our next release. When we detect the visit from a smartphone, we change the QR to a button, and when it is pressed we redirect you through the app, where you verify your PIN, then redirect you back to your browser where you are logged in.
- jetti 14y ago
  Pretty spiffy. Good luck with your product!

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.