4 ms·

The article reads like a straw man argument in favor of begrudgingly accepting password auth for the time being. It's disappointing that he has omitted mention

by yock 12y ago

The article reads like a straw man argument in favor of begrudgingly accepting password auth for the time being. It's disappointing that he has omitted mention of things like Persona, browser certificates, or even the Google Authenticator app (which completely solves his problem with 2FA).

freehunter 12y ago
I actually have a problem with things like Google Authenticator. I use it to secure the login for my Digital Ocean account. Worked great, until my phone broke. When I signed into Digital Ocean with a new phone... well, of course Google Authenticator doesn't know how to generate a new compatible code. That part is controlled by a QR code when you enable 2FA, and you can't get back to it without logging in. Same thing with securing the admin login to a site I run. When I switched phones, I lost my login. Sure, there's a way around it. Digital Ocean lets you disable 2FA with an SMS code. Then I can just log in, set up 2FA again, and have it working on my new phone. But then I fixed my old phone and switched back. So I had to do it all over again. Clef worked great, until someone with a Windows Phone joined the team and needed to log into the site. Suddenly our authentication method of choice, one we were really happy with, wasn't an option because Clef doesn't make a Windows Phone app. These are the problems the author seems to try to point out. Passwords at least work every time you type them in, from any platform. Passwords aren't tied to Google or Apple, passwords don't shun Microsoft platforms simply because there aren't enough users. If your users have to buy an iPhone just to be able to log in, or if they lose the ability to log in because they replaced their phone (something that happens all the time), it isn't a solution at all. They're going to end up going back to passwords (like we did) because nothing else works as well as passwords. And that's not a high bar to get over!
- bad_user 12y ago
  Any method of authentication that's more secure that simple passwords is going to be more inconvenient. 2FA is no exception.
  - freehunter 12y ago
    It doesn't have to be though. Clef is 100x easier than using a password, and dead simple to implement. Nothing to remember but your phone, and nothing to change at regular intervals. Google Authenticator is a little more inconvenient, but not by much. Of course, as my first comment pointed out, both of those became very inconvenient for me. But they don't have to be. What if Clef, instead of being proprietary, was a public property? Anyone can write a Google Authenticator application, which is why one exists on Windows Phone. Google has written zero software for Windows Phone, yet Authenticator works. 2FA doesn't have to be more inconvenient. In fact, it should be more convenient than passwords, because passwords need to be remembered and changed. There's no excuse.
    - dragonwriter 12y ago
      > 2FA doesn't have to be more inconvenient. In fact, it should be more convenient than passwords, because passwords need to be remembered and changed. The second factor (the "thing you have") in 2FA doesn't need to be remembered or changed. The first factor (the "thing you know"), which usually is a password, has to be remembered. (It may be somewhat less important to change it than in a single-factor password-only scheme.)
      - freehunter 12y ago
        With a good 2FA system, you can use a junk password because the chances of someone having both factors is next to zero. Using hunter2 as a password instead of gEtRAn8s_dr6Spepe doesn't matter because guessing the password is impossible unless they have your other factor, and even then it's going to slow them down quite a bit. Especially if your other factor is stored on your phone, which itself requires a password or fingerprint or both to get into.
        dragonwriter 12y ago
        > With a good 2FA system, you can use a junk password because the chances of someone having both factors is next to zero. If you use a junk password, then the chance of them being able to secure both factors is essentially equal to the chance of them being able to secure the other factor. Whether slowing them down matters really depends on context -- for most applications that may be an acceptable risk (if either the value of the access goes down with a delay or you will be able to report the loss in a way which prevents a slowed attacker from gaining access -- and its unlikely that an attacker will be motivated enough to prevent you from doing so -- this makes sense. This is not always the case.)

by yock 12y ago

freehunter 12y ago

I actually have a problem with things like Google Authenticator. I use it to secure the login for my Digital Ocean account. Worked great, until my phone broke. When I signed into Digital Ocean with a new phone... well, of course Google Authenticator doesn't know how to generate a new compatible code. That part is controlled by a QR code when you enable 2FA, and you can't get back to it without logging in. Same thing with securing the admin login to a site I run. When I switched phones, I lost my login. Sure, there's a way around it. Digital Ocean lets you disable 2FA with an SMS code. Then I can just log in, set up 2FA again, and have it working on my new phone. But then I fixed my old phone and switched back. So I had to do it all over again. Clef worked great, until someone with a Windows Phone joined the team and needed to log into the site. Suddenly our authentication method of choice, one we were really happy with, wasn't an option because Clef doesn't make a Windows Phone app. These are the problems the author seems to try to point out. Passwords at least work every time you type them in, from any platform. Passwords aren't tied to Google or Apple, passwords don't shun Microsoft platforms simply because there aren't enough users. If your users have to buy an iPhone just to be able to log in, or if they lose the ability to log in because they replaced their phone (something that happens all the time), it isn't a solution at all. They're going to end up going back to passwords (like we did) because nothing else works as well as passwords. And that's not a high bar to get over!

bad_user 12y ago
Any method of authentication that's more secure that simple passwords is going to be more inconvenient. 2FA is no exception.
- freehunter 12y ago
  It doesn't have to be though. Clef is 100x easier than using a password, and dead simple to implement. Nothing to remember but your phone, and nothing to change at regular intervals. Google Authenticator is a little more inconvenient, but not by much. Of course, as my first comment pointed out, both of those became very inconvenient for me. But they don't have to be. What if Clef, instead of being proprietary, was a public property? Anyone can write a Google Authenticator application, which is why one exists on Windows Phone. Google has written zero software for Windows Phone, yet Authenticator works. 2FA doesn't have to be more inconvenient. In fact, it should be more convenient than passwords, because passwords need to be remembered and changed. There's no excuse.
  - dragonwriter 12y ago
    > 2FA doesn't have to be more inconvenient. In fact, it should be more convenient than passwords, because passwords need to be remembered and changed. The second factor (the "thing you have") in 2FA doesn't need to be remembered or changed. The first factor (the "thing you know"), which usually is a password, has to be remembered. (It may be somewhat less important to change it than in a single-factor password-only scheme.)
    - freehunter 12y ago
      With a good 2FA system, you can use a junk password because the chances of someone having both factors is next to zero. Using hunter2 as a password instead of gEtRAn8s_dr6Spepe doesn't matter because guessing the password is impossible unless they have your other factor, and even then it's going to slow them down quite a bit. Especially if your other factor is stored on your phone, which itself requires a password or fingerprint or both to get into.
      - dragonwriter 12y ago
        > With a good 2FA system, you can use a junk password because the chances of someone having both factors is next to zero. If you use a junk password, then the chance of them being able to secure both factors is essentially equal to the chance of them being able to secure the other factor. Whether slowing them down matters really depends on context -- for most applications that may be an acceptable risk (if either the value of the access goes down with a delay or you will be able to report the loss in a way which prevents a slowed attacker from gaining access -- and its unlikely that an attacker will be motivated enough to prevent you from doing so -- this makes sense. This is not always the case.)