4 ms·

Apple has done a great job walking users through this process. Setting up "trusted devices" (iPhone, iPad, etc.) works really well: Apple already knows which d

by masnick 14y ago

Apple has done a great job walking users through this process. Setting up "trusted devices" (iPhone, iPad, etc.) works really well: Apple already knows which devices you own, so all you have to do is select the device and you get an instant push notification to unlock to see the verification code. Apple gives you a backup recovery code with very clear instructions to print/write it somewhere safe. They require you to re-enter it as part of the setup process to make sure you got it right. When you need a code, you pick the device you want it sent to and Apple pushes it out instantly via some feature baked into iOS. You can also set up any phone to have a code delivered via SMS, but presumably this is less secure because it could be read even if your phone is locked. Overall this is a great experience for the user -- much more friendly than Google Authenticator. In fact I wish this process was open a la Google Authenticator so that other applications could use it (this will happen when hell freezes over).

cbsmith 14y ago
I actually found Google Authenticator just as good on the user experience side, with the added benefit of being far more effective.
- r00fus 14y ago
  Google's approach is more unix-y - it lets you shoot yourself in the foot. Requiring you to put your recovery code back in at least forces people to memorize or write it down. Now, Google does have a good seemingly automated recovery service (you need to share a lot about your account to prove you're you but it works) - I'd rather not have reason to use it, though.
  - cbsmith 14y ago
    Does nobody get the benefits of TOPA?
- akandiah 14y ago
  I haven't used Apple's system, so I can't comment on it. However, Google's system has a few gaping holes that make it far from effective from a usability standpoint. First: A large number of Google's web applications still rely on application specific passwords. This was understandable a year or so ago, but still? It's getting very tiring generating an application specific password for some Google applications. This brings me to my next point: the use of application specific passwords has been made complicated than what's required. When confronted with a page that asks me for an application specific password, it takes too long to navigate to the correct page so that I can generate an application specific password. Thirdly, I can't change the name that I give to an application specific password. Discovered that you have a new installation of Chrome on a VM and want to create a password for that? Too bad: you can't rename the existing password so that you can distinguish the two easily. Lastly: Have you checked out the mess that's the management page for it? It's extremely confronting. It takes a bit of getting used to. In-fact, until very recently it was rather buggy. For instance: the page used to have a date which showed when an application specific password was last used. This date always had the year 1970. Who lets these kind of bugs through??
  - cbsmith 14y ago
    1) Yes, Google should move more of their apps to supporting this, but looking at only Google services is missing the point. Google Authenticator's TOPA is based on an open standard, so any third party can work with it too (and many do,Dropbox, Lastpass, Drupal, App.net, Dreamhost..."
  - cbsmith 14y ago
    2) I agree the UI could be much better. On the plus side, you only have to navigate it once per application.
  - cbsmith 14y ago
    3) I haven't run in to this problem, but as you can imagine, NOT being able to change it provides a number of benefits from a security standpoint, and if you do want to change it, it is just a matter of creating a new one and deleting the old one. I should think that'd be good enough for anyone.
natem345 14y ago
Why do you find this more friendly than Google Authenticator? Just because it pushes rather than requiring the user to open an app? Can you still manually get a code, in case you lack network (& don't want to break out the backup code)? What if you're actually logging in with the iDevice, does it just automatically allow it without asking?
- masnick 14y ago
  > Why do you find this more friendly than Google Authenticator? Just because it pushes rather than requiring the user to open an app? Exactly. I have so many things in Google Authenticator that I have to scroll. The timer is also annoying -- sometimes you have to wait for a few seconds for the codes to refresh so you have enough time to type in the code. > Can you still manually get a code, in case you lack network (& don't want to break out the backup code)? No, but for Apple you don't need to do this because you only need the code if you're accessing their website so you have to have internet access. I don't think I ever use the Google Authenticator without internet access. > What if you're actually logging in with the iDevice, does it just automatically allow it without asking? No idea.
  - natem345 14y ago
    Fair enough. > No, but for Apple you don't need to do this because you only need the code if you're accessing their website so you have to have internet access. I don't think I ever use the Google Authenticator without internet access. At work, I have no cell service but can still use my laptop. I don't want to use their wifi with my phone due to proxy server setup hassles. So I think it's still a valid use case.

by masnick 14y ago

cbsmith 14y ago

I actually found Google Authenticator just as good on the user experience side, with the added benefit of being far more effective.

r00fus 14y ago
Google's approach is more unix-y - it lets you shoot yourself in the foot. Requiring you to put your recovery code back in at least forces people to memorize or write it down. Now, Google does have a good seemingly automated recovery service (you need to share a lot about your account to prove you're you but it works) - I'd rather not have reason to use it, though.
- cbsmith 14y ago
  Does nobody get the benefits of TOPA?
akandiah 14y ago
I haven't used Apple's system, so I can't comment on it. However, Google's system has a few gaping holes that make it far from effective from a usability standpoint. First: A large number of Google's web applications still rely on application specific passwords. This was understandable a year or so ago, but still? It's getting very tiring generating an application specific password for some Google applications. This brings me to my next point: the use of application specific passwords has been made complicated than what's required. When confronted with a page that asks me for an application specific password, it takes too long to navigate to the correct page so that I can generate an application specific password. Thirdly, I can't change the name that I give to an application specific password. Discovered that you have a new installation of Chrome on a VM and want to create a password for that? Too bad: you can't rename the existing password so that you can distinguish the two easily. Lastly: Have you checked out the mess that's the management page for it? It's extremely confronting. It takes a bit of getting used to. In-fact, until very recently it was rather buggy. For instance: the page used to have a date which showed when an application specific password was last used. This date always had the year 1970. Who lets these kind of bugs through??
- cbsmith 14y ago
  1) Yes, Google should move more of their apps to supporting this, but looking at only Google services is missing the point. Google Authenticator's TOPA is based on an open standard, so any third party can work with it too (and many do,Dropbox, Lastpass, Drupal, App.net, Dreamhost..."
- cbsmith 14y ago
  2) I agree the UI could be much better. On the plus side, you only have to navigate it once per application.
- cbsmith 14y ago
  3) I haven't run in to this problem, but as you can imagine, NOT being able to change it provides a number of benefits from a security standpoint, and if you do want to change it, it is just a matter of creating a new one and deleting the old one. I should think that'd be good enough for anyone.

natem345 14y ago

Why do you find this more friendly than Google Authenticator? Just because it pushes rather than requiring the user to open an app? Can you still manually get a code, in case you lack network (& don't want to break out the backup code)? What if you're actually logging in with the iDevice, does it just automatically allow it without asking?

masnick 14y ago
> Why do you find this more friendly than Google Authenticator? Just because it pushes rather than requiring the user to open an app? Exactly. I have so many things in Google Authenticator that I have to scroll. The timer is also annoying -- sometimes you have to wait for a few seconds for the codes to refresh so you have enough time to type in the code. > Can you still manually get a code, in case you lack network (& don't want to break out the backup code)? No, but for Apple you don't need to do this because you only need the code if you're accessing their website so you have to have internet access. I don't think I ever use the Google Authenticator without internet access. > What if you're actually logging in with the iDevice, does it just automatically allow it without asking? No idea.
- natem345 14y ago
  Fair enough. > No, but for Apple you don't need to do this because you only need the code if you're accessing their website so you have to have internet access. I don't think I ever use the Google Authenticator without internet access. At work, I have no cell service but can still use my laptop. I don't want to use their wifi with my phone due to proxy server setup hassles. So I think it's still a valid use case.