20
Sep 10

Google Adds 2-Factor Security to Gmail, Apps

facebooktwittergoogle_plusredditpinterestlinkedinmail

Google said today that it will begin offering users greater security protections for signing in to Gmail and other Google Apps offerings. This “two-step verification” process — which requires participating users to input a user ID, password and six-digit code sent to their mobile phones — effectively means Google will be offering more secure authentication than many U.S. financial institutions currently provide for their online banking customers.

The search giant will be making the technology available to its enterprise (paying) customers immediately, and it will be free to consumers within the next few months.  Users who choose to take advantage of the technology can have the codes sent via text message or a special Google mobile app. All devices that are successfully authenticated can then be set to not require the two-step process for the next 30 days.

Travis McCoy, product manager of Google Security, said the company was looking for a way to prevent Google account takeovers made possible by weak or stolen passwords.

“We wanted to look and see what single area could we work on that would have the greatest impact on user security,” McCoy said. “We found user names and passwords often end up being the weak link in the chain in terms of how accounts are being compromised.”

Companies that have moved to require hardware-based two-factor authentication often build in backup or failsafe systems in case customers choose to use the added security but don’t have access to the device that provides that second factor. PayPal, for example, lets users require the input of a one-time password generated from a battery-operated key fob supplied by the online payment provider; customers who need access to their account but don’t have the key fob with them can still get at their money by correctly answering a series of challenge questions.

Similarly, Google also offers an alternative failsafe by providing each user a set of five one-time access codes that are specific to an account. Google enterprise users can simply have their administrator temporarily disable the secondary authentication layer if they can’t access their phones (for example, if the phone is lost, stolen, or has a dead battery).

I find it remarkable that Google will soon be offering for free a level of security authentication that many banks don’t yet afford their customers for online banking, even when those customers are willing to pay extra for it. While cyber thieves increasingly are defeating multi-factor authentication approaches like the one Google is offering — and this offering also will do nothing to stop “phishing” attacks that trick users into entering credentials at fake Google online properties — it is more robust than requiring a simple user name and password, which is more or less what many commercial banks rely on right now.

I was reminded of this last night, when I was contacted by a businessman who owns a dining establishment less than two miles from my home. His business recently lost almost $50,000 when cyber thieves broke into an employee’s computer and stole the user name and password for the company’s online banking account. I’ve agreed not to name the company or its bank because the bank may be willing to offer a partial settlement if the businessman agrees not to publicize the case or file a lawsuit. But the only thing separating the thieves from this victim’s cash was a user name and a password.

Google’s new offering may actually be able to help to avoid this pitfall. McCoy said the company’s mobile app will run on an open standard designed to integrate with third-party authentication technologies. While many banks have shied away from moving to requiring security tokens and one-time passwords due to the high cost of purchasing, distributing and maintaining these devices, a solution that lives on the customer’s mobile phone could be a no-cost, little-hassle way to address those concerns.

Tags: , ,

46 comments

  1. Nice one Brian. I’ve tried and played a little with Google’s enterprise version together with Yubikey! Works really cool.
    In my opinion the only difference between Google and banks deploying 2-factor is that Google has state-of-the-art OS, etc. whilst the banks are mostly likely ALL still putting up ‘portals’ to access accounts hosted on antiquated kit (and OS).
    Also, banks have a different econmic model than Google: they balance risk [of account break-in and subsequent theft] against the cost of implementing those systems.
    They could certainly take a page out of Google’s book: just add it: people will just use it – no need for months of planning, umpteen letters, etc, etc. Get the drift?

  2. Two comments:

    1. It is getting increasingly difficult to do commerce unless you have a cell phone – believe it or not, not everyone has one.

    2. The cell phone is the last bastion of unlisted number. It is getting increasingly difficult to do commerce unless you give up your unlisted number to a commercial database that is free to do anything it wants with it.

    • @nophone — this will be voluntary. that is, at least for now, you don’t have to use this 2nd factor if you don’t want to.

    • @No phone;

      Soon all land-line phones will be digital/IP phones anyway. My phone company is switching to fiber optic digital phones at this moment, and I will have fiber DSL all the way up to the modem soon.

      Fortunately they will simply swap out the phone I already rent from them.

  3. I think it’s worth noting, even with one-time password authentication enabled, one could steal your username and password and gain access to your email, that is, if you have IMAP or POP enabled. For this to be truly effective, you should turn off IMAP and POP access.

    Now if you choose to retrieve email through IMAP or POP, this doesn’t mean you should turn off one time passwords. This still prevents people crawling through your Google Documents or changing account settings.

    • How is enabling POP or IMAP on a Google e-mail account a security risk if you use encrypted SSL connections? Or are you referring to non-encrypted connections whether via POP/IMAP or in a browser just via HTTP? That is an issue either way as your credentials are not encrypted and passed over the Internet in plain text.

      Or are you saying that enabling POP/IMAP on a gmail account opens up a way for bad guys to scan that account and possible break into it? I would think Google has protections against that.

      I hate webmail for numerous reasons, primarily because you’re reading e-mail in a browser which by its very nature executes active content and could do so with malicious content in an e-mail message. I prefer to use an e-mail client (ex. Outlook 2003) that can be configured to read all e-mail as plain text (no active content) and that also blocks automatic downloading of content in the e-mail itself.

      Example: How to configure encrypted POP/IMAP for Outlook 2003
      http://mail.google.com/support/bin/answer.py?answer=75291

      • @xAdmin;

        I suppose that would depend.

        Does Gmail permanently turn off all HTTP web access ability when you use Outlook to access your account? In other words, couldn’t they still potentially crack your account from web access?

        Also, for those that communicate using web-based Gmail’s SSL; the data transfer for that is not SSL all the way to the target, even if that user has SSL enabled on the target email account. So even between two web-based SSL Gmail customers, you have open web data gaps between Gmail servers out on the internet. So this isn’t exactly like having VPN.

        • I can still access my Gmail accounts via a browser when they’re enabled for POP/IMAP access. The only time I do though is to empty deleted items a couple times a month (unlike many e-mail providers when accessing via POP, Gmail doesn’t permanently delete the e-mail, just moves it to deleted items). When I do this though, it’s always via https during login and during the entire session until log out. I don’t use any other Google services or access the gmail accounts via any other device, so there is little chance of my credentials being stolen.

          Also, as general practice when accessing any sensitive website that requires credentials, I first clear the browser cache (history and cookies) and once logged in, NEVER browse to another website (to prevent cross site scripting attacks). I always use the log out function when done and immediately close the browser and again clear the browser cache (history and cookies) to minimize security issues. Clean slate before, clean slate after. :)

      • Lets say I just stole your username and password by what ever means possible. Even though you may have OTP enabled for Gmail through the browser, as long as you have IMAP or POP enabled, I can completely bypass the OTP authentication by accessing your mail through IMAP or POP.

        • Saints –

          I was actually pleasantly surprised to find that Google has somewhat of a control to address this. Services like POP/IMAP that do not support the 2-factor authentication cannot be used with your regular password. They allow you to setup an “application password” that is a nice long, strong, password, that you use only with that one service. Obviously it could still be compromised, but it is less likely to be compromised if you never type it in (safe from keyloggers) and you use it only for one service (less likely to escalate a compromise across services). Google lets you have as many of these as you want.

          -Dave

  4. It’s definitely good for Google to offer this level of protection for enterprise apps. Of course, as has been noted on this blog numerous times, OTP soft-tokens or SMS OTP don’t protect against the malware-based attacks against online banking. There are plenty of cases where accounts were drained despite OTP being in use. I do worry that FI’s and their customers get a false sense of security when OTP is in place.

  5. It sounds nice, but I can’t help also seeing this is a trick to give up your mobile’s number to Google! LOL

  6. Isn’t there a problem if the two factor-authentication doesn’t use independent channels? My bank offers two-factor authentication via various means, including cell phone. But they also heavily promote mobile banking via SmartPhone apps. Does getting a text message with an OTP to the same device used to conduct online banking increase security?

    And what happens if you use your GoogleVoice number for dual-factor authentication of Google Apps or is that not possible?

    • I think there definitely is an issue with having those channels in the same device. Banks in general are hoping that mobile malware doesn’t happen, or are hoping it doesn’t happen for a long time. I don’t think that is too realistic though…

      • I agree Helly;

        Out of band is the only way to go with this second factor to authentication; but even out of band has been comprimised, by malware that infects the phone when it is connected to the PC that is being used for services.

        Most folks I know like to download updates, applications, and music into their cell phones through the same PC they use for the internet and banking.

        Hence, the second factor is pwned.

        • A smartphone can get malware on its own other than just via a potentially infected computer.

          There’s a false assumption that smart phones are safe and malware free and it’s perfectly ok to use them and/or apps on them to access online banking or to even use them as a second channel in authentication. But, do you really know if your smart phone is malware free? How would you determine that?

          Sans had an interesting discussion and voting on this here:

          Thoughts on Malware for Mobile Devices – Part 2
          http://isc.sans.edu/diary.html?storyid=9160

          • Very true xAdmin;

            And it probably doesn’t take long for the hijackers to figure out the connection between the owner of the smart phone and the bank account in question, that is the target of the attack.

            I would assume this could easily be self synchronizing from all the data the crooks gather from millions of users. I wouldn’t doubt the bot net is now a supercomputer used to crack both passwords and weaker encryption schemes also!

            I wonder if any of the smart phones use a hardwired operating system, that can’t be flashed from the internet?

  7. “I find it remarkable that Google will soon be offering for free a level of security authentication that many banks don’t yet afford their customers for online banking, even when those customers are willing to pay extra for it.”

    What? You mean our beloved leaders forgot to make this a regulation in the 200o pages of FinReg that was recently passed…say it ain’t so! LOL.

  8. You said this two-factor authentication is more secure that many banking sites. My banking site shows me a “site key” web page after I enter my user ID. If the picture displayed (via https) is not what I expect, then I DON’T enter my password. My banking password is complex and is not the same as any other password I use.

    Is this as secure as two-factor authentication? Should I use an online banking system that uses cellphone two-factor authentication or are there other alternatives that are not as onerous?

    • the sitekey thing is basically a joke that exists to make it look like the institution is doing something.

    • Hi Kent. Sitekey is better than nothing, I suppose (just barely), but it doesn’t address the issue of having your credentials stolen.

      Consider the following scenario: Crooks get a keystroke logger or form grabber on your system, something like ZeuS. They now have your online banking user name and password, right? Well, what’s to stop them from using that to log in as you? A picture of a blue vase? I don’t think so.

      If your bank requires an out-of-band authentication, like via a code sent to your phone, the crooks then need to inject themselves further into this process, by forcing you to visit a fake bank site they control, and getting you to enter that code there as well. Now, I have written probably a half dozen stories of crooks doing just that with the help of ZeuS, but generally speaking they are going after high-dollar accounts, and mainly commercial accounts at that.

      • I interpret your reply to say that if the bad guys are on your system (eg, with Zeus) then they are going to get your money, even if you use two-factor authentication. It’s just a little bit harder for them.

        The banking “site key” webpage is more a protection against man-in-the-middle attacks from the web as when a certificate has been compromised or substituted from a shady CA, but there is no malware on my computer.

        It’s difficult to keep the various scenarios straight — am I thinking about this particular technique to protect against spoofing, social engineering, or malicious software on my computer? What’s real and what’s fake? It’s very hard.

        I do like your blog. Your research into actual incidents is unparalleled — and I read as many security blogs as I can find. Thanks for picking up the baton, and for being so responsive to your readers.

        • “The banking “site key” webpage is more a protection against man-in-the-middle attacks from the web as when a certificate has been compromised or substituted from a shady CA, but there is no malware on my computer.”

          I am at a loss to think how “site key” would help against a man-in-the-middle with a cert from a shady CA. Any information the crook gets from you they can send on to the real bank, pretending to be you, and get anything (including the picture) they want to send on back to you to make you feel secure.

          • The concept is that you don’t enter your password unless you see the picture showing you that you’re on the right site. The picture is associated with a cookie on your machine, and if you go to a new machine you need to answer extra questions before you get the picture. So a man in the middle attack spoofing the bank’s web server in theory can’t show you the right picture, and you should get suspicious. If the bad guy prompts for the answers to the questions, though, most people will just answer without seeing that as a red flag. So in practice there’s not that much difference between a password and a password plus answers to questions. (It’s multiple single factors, not a 2-factor mechanism.) And if there’s a zeus trojan controlling your computer, the bad guy can just log in from there and ignore the whole secret question issue (because your browser already has the cookie and won’t be prompted to answer the questions). So the whole sitekey solution addresses only a small part of the problem, and does it in a way that requires an exceptionally alert customer to know when a sometimes-normal transaction is actually a red flag — it’s just window dressing to make it look like the institution cares about security. If they really cared about security they’d implement an out-of-band transaction authentication which depends on something physical (not stored on the computer).

      • Two banks that I visit online require previously-set cookies on my computer to get into my accounts. (They also have site keys.) If there are no cookies (e.g., when I use a different computer), then a message appears, saying that my computer isn’t recognized; then one has to answer three very difficult challenge questions before the account can be accessed.

        • @JBV:

          From what I understand about Zeus and its many variants; the attacker doesn’t even need passwords or other authentication, they simply hijack the SSL session from the browser after you authenticate. Then they can empty the account at will. Providing the bank doesn’t at least have some behavioral protections set into their data base.

          Perhaps Brian will correct me, but in the many discussions I’ve held with experts on other sites, this indeed seems to be the case. The only protection against this, that is simple for the user, are hardware virtual browsers, or a browser “bubble” like Rapport or Prevx.

          Many banks are switching to Rapport as a server side protection as well as the free version that is a client side utility. I can’t attest to the efficacy of either that one, nor Prevx; as it is difficult to test without actually being attacked; but that is all I have.

          One can always go to a LiveCD or dedicated banking PC environment to reduce the risk.

          • “From what I understand about Zeus and its many variants; the attacker doesn’t even need passwords or other authentication, they simply hijack the SSL session from the browser after you authenticate. Then they can empty the account at will. Providing the bank doesn’t at least have some behavioral protections set into their data base.”

            Yes, that’s correct, although for whatever reason I’m not hearing much about attacks like this against US banking customers: It appears this type of “session riding” or “session hijacking” type attack is more common against banks in Europe, esp. the U.K.

          • @Brian;

            Thank you very much for your response! Me being the paranoid type; I always assume I’m compromised with the latest a greatest malware available. :(

            I just can’t help it – I guess that is my OCD kicking in!

    • SiteKey is worthless.
      How would a crook try to get into your account?
      1. If you mistype your banks name (or use a wrong link, or are a subject of DNS poisoning, or have a bot on your computer or… ), and the crook owns the replacement domain, using it as a “man-in-the-middle proxy”. Could the crook have an SSL certificate, issued from a trusted root? yes. Does sitekey protect you? No. The crook will get each page you request from the True site, using rewrite rules on links as necessary to keep you pointed at his site. The bad guys will be using your input/username to request your Your image will be sent to the bad guys and sent right along to you, making you think you are at the right spot.

      I have to Work to think of a scenario where sitekey WOULD help at all, and the only thing that comes to mind are really lazy crooks who “file|save as” a page on the bank’s site, and try to pass that off as the real thing. If the crooks are trying to make your login look like the bank, they will incorporate this just as easily as the corporate letterhead gif.

      The problem with sitekey is that it pretends to be a second factor, but it is just another instance of “secret” (and not a very good or closely held one; your bank will give it away to whoever asks) delivered through the same channel (which is only partly trustworthy).

      Here’s fun for you: MY bank has gone sitekey one better, and has a “secret question” lock before you can get to the image. THIS STILL DOESN’T HELP AGAINST MAN-IN THE MIDDLE SCHEMES (mentioned above), but irritates the TAR out of me, because I’ve got a LOT more hassle logging in.

      *”Security” that doesn’t keep the bad guys out, and makes more work for me, is the worst kind.*

  9. Here’s another reason for Google to offer improved password services, via the worthwhile article ‘Google Confronts China’s “Three Warfares”‘ in Parameters:

    In early January 2010, Google announced that a computer attack originating from China had penetrated its corporate infrastructure (in mid- December) and stolen information from its computers … “A person with direct knowledge of the investigation now says that the losses included one of Google’s crown jewels, a password system that controls access by millions of users worldwide to almost all of the company’s Web services, including e-mail and business applications. The program, code named Gaia for the Greek goddess of the earth, was attacked in a lightning raid taking less than two days last December, the person said.”

  10. I posted this already in a response to another comment, but wanted to put it in the main thread for better visibility. :)

    There’s a false assumption that mobile devices are safe and malware free and it’s perfectly ok to use them and/or apps on them to access online banking or to even use them as a second channel in authentication. But, do you really know if your mobile device is malware free? How would you determine that?

    Sans had an interesting discussion on this:

    Thoughts on Malware for Mobile Devices – Part 2
    http://isc.sans.edu/diary.html?storyid=9160

    Bottomline: the real solution is not to get infected with malware on any device if you want to avoid getting an account hacked! Smartphone security is no where near the level of computer security. I mean how do you setup a layered defense for your smart phone? How do you verify it’s not infected? At least right now, I can confidently operate and verify my computer systems are clean. I don’t have that same confidence with smart phones which is one reason I don’t own one yet (primary reason is I really don’t have a use for one and can’t justify the associated costs).

    • Mikko Hyponnen had a really interesting talk at RSA this year regarding malware on mobile phones. The name of the talk/link isn’t coming to mind, but its worth a trip to google if you can find a recording.

      Standardization of mobile phone operating systems, while neat in a tech way, is making it easier for malware writers all the time. Mobile phones seem to be following nearly the same course PCs did early on. It took some major worms to wake people up then… it looks like it might now too.

      • I’m not trying to discount the potential threat to mobile phones, because it’s certainly there. I would just add a voice of calm here, noting that there really hasn’t been much malware to speak of that targets mobile devices (at least malware that tries to steal or intercept financial data).

        The whole mobile security debate is a lot like to the Mac security debate: It’s not as if malware writers can’t attack Mac users; the reality is that they so far haven’t chosen to.

    • From a practical standpoint, there’s a fairly great hurdle for a single bad guy to gain access to both a particular consumer’s compromised phone and computer. So if a bank requires both of those, and you’re not high-profile enough to actually be worth spending effort targeting, you’re safe enough. (Now, if you do your banking from your phone, and the phone is the second factor, you’re in a much riskier place.)

  11. It would add some additional complexity for the bad guys if Google would let users text back a response and have that evaluated on the server side. This prevents the user going back through the same channel and thus keeps more information away from the person or group monitoring your session.

    There is still a vulnerability but it will be tougher to exploit.

  12. Regarding strong passwords, do you recommend any password managers similar to Roboform? There is a Roboform extension for Firefox…what about that?

    EB

    • The best password manager is the human brain! Seriously.

      While password managers use some type of encryption, the information is a: stored on the computer and b: is software that can be hacked on that computer. If your computer is compromised or stolen, that password information is included with it for the bad guys to hack into and use at will. That’s also why I always turn off the browsers built-in autocomplete function that stores usernames and passwords and don’t like password managers.

      I know it’s difficult to remember multiple passwords, but it is easier if you use passphrases of something you’ll easily remember, but at the same time are complex enough to be difficult to hack. I use a few different ones and will use them randomly across a few non-critical accounts while anything critical such as online banking gets its own unique one for maximum security.

      Besides, using your brain this way gives it exercise and helps your memory retention. :)

    • Although xAdmin has the best advice on smart practices, my clients refuse to comply. Therefor I felt forced to find what I though had the best idea for password management.

      Bear in mind I have no axe to grind and there may be better free managers out there. I picked LastPass because it was free, open source, stored all passwords and sensitive information in the cloud, came highly recommended by the IT community, communicated over SSL (of course) and stored no information on the client side hard drive. You only need one password to gain access to the console, so that one should be authored like xAdmin’s guidelines. Changing it every three months or earlier isn’t a bad idea either.

      I read an article by Michael Kassner on TechRepublic where he worked with the developers at LastPass; and he did a remote session into his account and couldn’t see any of the information himself without using his console! LastPass claims even local technicians have no access to the data. I must admit I don’t understand their special host intrusion system, so I defer making comments on it.

      All cautions about keyloggers and screen capture apply here, using a utility that works at the kernel level while you are infected is the best practice in preventing such attacks.

  13. Brian-
    My continuing struggle to get my local, small Town government to adopt a dedicated Linux OS for these delicate, high value data exchanges has brought me to a web service that seems to fill a void for those 2 groups (banks and clients) who can’t get institution offered, dual bandwidth transaction verification.
    Called “PhoneFactor”, it appears to have many security elements and features much needed by average home users who likewise insist on using Windows to bank.
    It’s worth looking at for those who aren’t security experts, and it’s free for some users.
    http://www.phonefactor.com/how-it-works/overview

    • I don’t really know – phones are getting pwned now too; but at least this should work on dumb cell phones, which is at least some protection. On a smart phone the malware could record the voice snippet and keylog the rest of it. I’m not sure their are very many phones now, that are totally invulnerable to malware. Especially since people always want to connect them to the PC anyway – Oops! There goes the PC bank session too!

      I was sure I read of a second factor phone jacking session on web security somewhere recently. However this is definitely better than 99.9999% of what most banks are doing, which is nearly nothing! Add a third factor, and you got a pretty tight system. Cell cameras should be a good source for something along this line!

  14. it is laudable that the big boys like Google have finally woken up to the fragility of the user name / password paradigm. However there a few problems with the mobile phone route :

    1. Cost – who carries the cost of the text messages ( especially cross border )
    2. Reliability – SMS is a store and forward protocol. Fire and forget. There are a number of reasons why it may not be delivered. a) Network congestion; b) Bad network coverage ( in building ) c) Good old security – who is monitoring those text messages to make sure that no one from the network isn’t actually ‘skimming’ them?

    All is not lost. There is a solution that addresses all of the above. Check out http://www.liveensure.com. This is a multi-factor authentication solution that is orders of magnitude stronger than this proposed solution.

  15. Re: Ross Macdonald – CEO of Liveensure

    Device Fingerprinting is not multi factor authentication, no matter how much vendors like yourselves want to call it that. It is generally considered a part of any authentication solution, usually as a mechanism for profiling a user’s session to identify when it is necessary to request a higher level of authentication. To claim that it is “orders of magnitude” stronger than a proper 2 factor system is laughable.

    • AD

      You are right to be circumspect to be dubious about such claims. However ours are not made lightly.

      If you take a bit of time to investigate the solution ( lots of information on the website ) – you will find that :

      It’s not just the device, it’s the session/user context for that factor, and we support third party factors as well – creating our “N-Factor” synthesis ( as opposed to a sequential exchange of credentials over the browser – used by most solutions today ) which generates a one time signature at the device and at our stack – which are then compared over a separate communication path ( not the browser).

      So yes – it is not just the device and no a device on its own is not multi-factor authentication.

      Please test it for yourself. Download the code / mash it up and use it on your own site. You will be surprised. It has been through pen tests with some of the biggest names in the industry.