Google is rolling out comprehensive mobile phone based two factor authentication to regular Google accounts ...
Official Google Blog: Advanced sign-in security for your Google account
... If you like, you can always choose a 'Remember verification for this computer for 30 days' option, and you won't need to re-enter a code for another 30 days. You can also set up one-time application-specific passwords to sign in to your account from non-browser based applications that are designed to only ask for a password, and cannot prompt for the code....
Some notes from the help page (emphases mine, square parens my comments)
... Soon after you turn on 2-step verification, non-browser applications and devices that use your Google Account (such as Gmail on your phone or Outlook), will stop working. You'll then have to sign in using your username and a special password you generate for this application...
... If you have an iPhone, iPod or iPad, [3G or later, needs iOS 4] we recommend you use the Google Authenticator application to generate verification codes. The application doesn't require an Internet connection or mobile service to generate verification codes. If you would prefer to receive your verification codes by text message or phone call, follow the directions for Text or voice message below....
... Adding a backup number ensures you can receive a verification code to sign in even if your primary phone isn't available or working. ...
... After you set up your phone to receive verification codes, you will be given 10 backup codes. These backup codes can each be used once each to substitute for a verification code. These could be useful whenever you don’t have access to your phone (for example, while you are traveling)...
... If you've lost access to your phones, you can always sign in using one of your printed backup codes [and then turn off two factor authentication?], which you generated when you first turned on 2-step verification. If you've lost your phones and don't have your backup codes, you'll need to fill out an account recovery form...
... An application-specific password [revocable] is similar to a verification code in that you don't have to memorize it. However, application-specific passwords are longer than verification codes and you do not enter them into web browsers. In addition, you do not get application-specific passwords from your phone -- instead, to generate an application-specific password...
Visit the Authorizing applications & sites page (pictured below) under your Google Account settings...
Soon it will be safe to use my Google services on untrusted (keystroke logger possible) machines -- like my office XP box. I'll configure my trusted machines to remember verification. My iPhone will run an RSA-token like authentication code generator. I will keep at least one backup code in my wallet - albeit in a permuted form.
Of course I will wait several weeks before I switch over. I'm no fool. I'll let the brave and inexperienced take the arrows of early adoption.
The traditional password isn't quite dead yet, but it has one (rotted) foot in the grave.
Thanks Google. Special credit for making Google-authenticator open source and standards based ...
The Google Authenticator project includes implementations of one-time passcode generators for several mobile platforms, as well as a pluggable authentication module (PAM). One-time passcodes are generated using open standards developed by the Initiative for Open Authentication (OATH) (which is unrelated to OAuth).
These implementations support the HMAC-Based One-time Password (HOTP) algorithm specified in RFC 4226 and the Time-based One-time Password (TOTP) algorithm currently in draft.
See also:
- Gordon's Tech: After the Gmail hack - passwords and security
- Gordon's Notes: Thunder in the Cloud: Lessons from my hacked Google Account
- Gordon's Tech: Google hack lessons - where the geek risks are
- Common issues - Accounts Help - managing a lost phone, sign in after losing phone access, multiple accounts, Google Apps admins have special powers, and so on.
- Implementing two factor (4/2011)
12 comments:
Of course I will wait several weeks before I switch over. I'm no fool. I'll let the brave and inexperienced take the arrows of early adoption.
Don't worry, as a paying Google Apps user I've used two-factor authentication for a few months now without any problems. For direct access I use Google Authenticator on my iPhone, for applications such as Apple Mail and Spanning Sync I use application-specific passwords generated by Google.
I should have written "Brave and inexperienced and natively lucky like Martin and Andrew ...".
I swear it's a curse. I attract bugs the way Goldman Sachs attracts money. So I always have to wait.
I'm impressed by how thorough they seem to have been with this. In their FAQ they also make clear this is for geeks and security types -- which is just right. It is the future, but it will take time to percolate.
Google is doing good.
Waiting is fine, I learnt a few lessons too, i.e., I'm no longer buy first-generation Apple products, my gadgets last longer than just a year, etc. With age comes wisdom I guess! ;)
I don't consider two-factor authentication geeky, at least in Switzerland it's standard for many websites with higher security requirements (e.g. online banking, health insurance accounts, VPN access in commercial environments, digital legal signatures, etc.). The main difference is that Google offers a smartphone app and not only SMS or a dedicated token generator/card reader.
I understand that's also true in India. The US is a late adopter of most security measures.
"Soon it will be safe to use my Google services on untrusted (keystroke logger possible) machines -- like my office XP box. I'll configure my trusted machines to remember verification."
You really think the keylogger machines will honor your request not to remember verification?
The keystroke loggers will get both my password and the Google provided code, but the code is only good for a short time.
I assume the combination of a keystroke logger and "man in the middle" attack could still steal credentials, but that's currently an expensive attack.
I still don't understand the application-specific passwords though. They seem to have the same access so what's to stop someone for stealing one of them instead?
Application specific passwords are fully vulnerable, they should only be used on trusted devices. They're mostly for iPhone use or desktop email clients; these should only be used on trusted machines.
Take it from an expert with over 15 years of experience in online security... This is the wrong direction. Google chose the worst form of two-factor authentication available ("out-of-band").
Google is perpetuating the misconception that a hacker cannot compromise the process since the hacker is not in possession of the user's phone. However, the hacker does not need to be in possession of the user's phone to compromise an "out-of-band" process. The hacker simply needs to trick the user into divulging the received phone code. This is the method typically used by hackers to compromise out-of-band authentication. The hacker constructs a counterfeit webpage to solicit the user's credentials (a relatively easy task for a hacker). Then, using scripting on the counterfeit webpage, they transmit the solicited credentials to the legitimate google website. Google sends the user's phone a code, and the user, believing they are communicating with the legitimate google website, enters the received code on to the counterfeit webpage. The counterfeit webpage then sends this additional information to the genuine google website and...presto... they are logged into the victim's account.
All google has done is add more complexity to their login process but they have not added any real additional security. Companies who have toyed with this method in the past (google is by no means the first) typically abandon it after several months due to high user complaints, great losses of users, and little security benefits realized.
Great comment - thanks! A recent bank technology news had details about an attack on "Out-of-Band Authentication".
http://www.americanbanker.com/btn_issues/22_12/security-out-of-band-authentication-gets-outfoxed-1004394-1.html
A wikipedia article on two factor authentication confirms my suspicion about man-in-the-middle attack vulnerability --
http://en.wikipedia.org/wiki/Two-factor_authentication
Still, it seems like Google's approach increased the cost of an attack. My understanding is that's the best security can do. Nothing will stop a sufficiently determined attacker, the goal is to make attacks so expensive that they're no longer profitable.
What do you think they should do instead of two factor authentication?
I think the PAM combined with the mobile app is particuarly useful. The PAM is fairly simple to compile and configure for use on a Linux system. Should be usable on OS X too (full disclosure, I've had no joy compiling the module for OS X). Quick and easy two-factor authentication on Linux at least.
Google's open source move for PAM is very agreeable.
Post a Comment