3 ms·

While this may be better for some people, I find it hardly convenient that I have to have my phone with me everywhere I go in order to use this system (rather t

by jetti 14y ago

While this may be better for some people, I find it hardly convenient that I have to have my phone with me everywhere I go in order to use this system (rather than having my password in memory). On top of that, for people who are like my wife who have a knack for letting their phone die, this isn't an answer either. Then you get people like me, who have a Windows 8 phone and there doesn't seem to be any support for this coming soon. I checked one of the sites and it looks like you sign up with Clef which means there may not be any option to set passwords. If you want a separate device for passwords, then I recommend using a Yubikey (https://www.yubico.com/products/yubikey-hardware/yubikey/ https://www.yubico.com/products/yubikey-hardware/yubikey/). You can set a long string in the memory of the yubikey as the base password and then add the site name afterwards. If you make your base password "2435ulkahsgfoiasjeoi25095iuasdfaq3uinwetpq3gtlknfoi465098aydsfaoidsaf" then for logging into facebook you can use "2435ulkahsgfoiasjeoi25095iuasdfaq3uinwetpq3gtlknfoi465098aydsfaoidsaffacebook" and gmail could be "2435ulkahsgfoiasjeoi25095iuasdfaq3uinwetpq3gtlknfoi465098aydsfaoidsafgmail" etc. That way you have a password that is strong and easy to remember. The caveat to this, of course, is that it wouldn't work on mobile and if you lose your yubikey you would have to reset all of your passwords.

brennenHN 14y ago
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.
uvdiv 14y ago
If you make your base password "[X]" then for logging into facebook you can use "[X]facebook" and gmail could be "[X]gmail" etc. If I did this, I would give Paul Graham access to my GMail, Facebook, and online banking accounts -- they'd all be trivially derivable from my HN password, which he has (in principle). No thanks.
- jetti 14y ago
  To be fair, most people already do this anyways by using passwords multiple times. There are also two memory banks in a yubikey so you can set two different keys and alternate them using the schema I put forth above. On top of that, you don't need to use the site name, it is up to you what to chose, you can use something incredibly simple for each site and a simple password turns into a not so simple password.
  - sk5t 14y ago
    Negatory on this approach... one of the good uses for the Yubikey is TOTP[1][2] -- and TOTP must not share any key material across sites, rather, each site has its own seed. [1] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al... [2] http://zetetic.net/software-onetime http://zetetic.net/software-onetime Disclaimer: my employer makes OneTime.
  - uvdiv 14y ago
    To be fair, most people already do this anyways by using passwords multiple times. At least they have no illusion of security. The scheme you showed provides lots of illusion, and zero security. This matters because, for the same effort, users can get much stronger security, even a cryptographic guarantee of password independence. (Leaked site passwords yield zero information about other site passwords, even if they're derived from the same root). But they will not seek out these solutions if they are mislead into using broken schemes instead. There are also two memory banks in a yubikey so you can set two different keys and alternate them using the schema I put forth above. That's still terrible.

by jetti 14y ago

brennenHN 14y ago

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.

uvdiv 14y ago

If you make your base password "[X]" then for logging into facebook you can use "[X]facebook" and gmail could be "[X]gmail" etc. If I did this, I would give Paul Graham access to my GMail, Facebook, and online banking accounts -- they'd all be trivially derivable from my HN password, which he has (in principle). No thanks.

jetti 14y ago
To be fair, most people already do this anyways by using passwords multiple times. There are also two memory banks in a yubikey so you can set two different keys and alternate them using the schema I put forth above. On top of that, you don't need to use the site name, it is up to you what to chose, you can use something incredibly simple for each site and a simple password turns into a not so simple password.
- sk5t 14y ago
  Negatory on this approach... one of the good uses for the Yubikey is TOTP[1][2] -- and TOTP must not share any key material across sites, rather, each site has its own seed. [1] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al... [2] http://zetetic.net/software-onetime http://zetetic.net/software-onetime Disclaimer: my employer makes OneTime.
- uvdiv 14y ago
  To be fair, most people already do this anyways by using passwords multiple times. At least they have no illusion of security. The scheme you showed provides lots of illusion, and zero security. This matters because, for the same effort, users can get much stronger security, even a cryptographic guarantee of password independence. (Leaked site passwords yield zero information about other site passwords, even if they're derived from the same root). But they will not seek out these solutions if they are mislead into using broken schemes instead. There are also two memory banks in a yubikey so you can set two different keys and alternate them using the schema I put forth above. That's still terrible.