Security Blog

The latest news and insights from Google on security and safety on the Internet

Advanced sign-in security for your Google account

February 10, 2011
Share on Twitter Share on Facebook
Google

14 comments :

Saqib Ali said...

I would like to take this opportunity to remind Google services users that while padlocking the front using the 2-Step verification, they should not leave the backdoor (3-Legged OAuth) wide-open. Please check and double-check the legitimacy of the 3rd party website before giving it access to your Google data.

If that 3rd party website is malicious and you have granted it access to your Google data using OAuth, 2-Step verification won't help much. That 3rd party site can siphon off your data without ever logging into your Google account and without your knowledge.

Please check all your OAuth Tokens today by going into your Account Settings page and clicking on Authorizing applications & sites

Saqib

February 10, 2011 at 4:30 PM
Jim Manico said...

Also, multi-factor AuthN for Gmail can be circumvented via standard password brute force via IMAP or POP. One time app specific passwords only help so much. Please disable IMAP and/or POP if you only view your GMail via the web!

February 10, 2011 at 7:37 PM
Anonymous said...

So what happens if you check GMail from the same phone you use for your SMS factor? I assume this defeats the whole point of it.

February 11, 2011 at 9:16 AM
Saqib Ali said...

@Larry: If you're syncing (IMAP, ActiveSync or NativeAndroid) your Gmail to your phone, than the 2-Factor verification doesn't help much if your phone is stolen. Hopefully you had a pin or a unlock pattern set on your phone.

However if you are using the Gmail Web UI on your phone, then you will still be prompted for your Gmail password in addition to SMS verification.

In any case if you lose your phone or think it is missing, immediately un-enroll from 2-Step verification. If you find the phone, re-enroll. It only takes couple of mins.

February 11, 2011 at 11:38 AM
Gyenes Gábor said...

I'm courious when it will be available for broader audience (it is not yet available in certain countries). I could add Google to the SMS Key application for real confortable login. If somebody has an SMS and Android, may post a sample to me.

Thanks in advacne.

February 12, 2011 at 4:14 AM
Marcelo Menezes said...

I've setup the 2-steps verification and I am pretty disappointed. It only asked the PIN once on my laptop. It says may laptop is now a recognized device and will not ask the PIN again! What is the point? If someone stolen my laptop (and knows my password, let's say) he/she will be able to logon without any problem!

Gmail should provide an option to "always ask the PIN", regardless any recognized device.

February 21, 2011 at 7:03 PM
Eric said...

How about bringing support for Yubikey? I don't want to deal with text messages or even having my phone with me to gain access to my information.

February 22, 2011 at 10:36 AM
Nishit said...

Hi Marcelo!

When you enter your pin ('verification code'), you can check the "Remember verification for this computer for 30 days" box, to have that computer remembered for 30 days. You will not need to enter another code on that computer for that time -- even if you hit "Sign out".

If you don't check this "Remember verification .." option, you will be prompted for a pin every time you log in -- which is the behaviour you're requesting.

February 22, 2011 at 7:41 PM
Unknown said...

I would like some options like:

1. Never ask for PIN for this computer/device.
2. Ask every 30/60/90 days for this computer.
3. Always ask.

March 6, 2011 at 11:11 AM
GP said...

It sound like a very good feature and unsurprisingly Google is the first company to implement 2 factor authentication. I had a few questions regarding how exactly it works.
1.What about brute force on the verification code? How do you protect against that?
2.Is the code fixed length?
3.How random is the code that is generated? The 'backup codes' looks like a bad idea. If the user can lose his/her password then can also lose the backup code. Ideally the user should be send a new randomly generated code every time he/she enters the correct password.
4.How does the password retrieval process play out if you have two factor authentication setup?

April 1, 2011 at 12:22 PM
Nishit said...

Hi gp@,

1.What about brute force on the verification code? How do you protect against that?
Yes, Google has brute force protection on password and verification code attempts.

2.Is the code fixed length?
Yes, the code length is fixed, based on what code is used. It is:
6 digits for Google Authenticator or SMS based verification codes
5 digits for Voice based verification codes
8 digits for Backup verification codes

3.How random is the code that is generated? The 'backup codes' looks like a bad idea. If the user can lose his/her password then can also lose the backup code. Ideally the user should be send a new randomly generated code every time he/she enters the correct password.
-The verification codes generated by the Google Authenticator app use the OATH TOTP standard. So the codes aren't random, but are computed as a function of the secret key and the time.
-The SMS/Voice codes are randomly generated

The Backup verification codes are for situations where the user doesn't have access to the phone - e.g. while traveling or if the phone has no network coverage. For normal usage, users wouldn't use Backup verification codes. If the backup codes are lost or stolen, the user is still protected as long as the person accessing the codes doesn't know their password. Lost backup codes can be revoked and replaced by the user at any time.

4.How does the password retrieval process play out if you have two factor authentication setup?
The Account Recovery process is further fortified for 2-step users. The password and the verification codes are treated as independent factors, and having one is not sufficient to gain access to the account using Account Recovery mechanisms.

April 6, 2011 at 7:26 PM
Anonymous said...

@GP -

This is EXACTLY what I want to know as well - what you are talking about in #4 regarding password retrieval process. As someone who has had her ex regularly hack into her accounts, I am particularly concerned about this. I signed up for the two-step authentication, only to realize that if my ex just does what he normally does - which is just to reset my password (maybe doing this brute force cracking Saqib and Jim talk about) - then surely this may not be any help.

Does anyone know if two-step still kicks in after a password change to not let anyone else in? Any other suggestions for how I can stay safe online?

April 16, 2011 at 11:55 AM
Nishit said...

Hi Susanna,

If the account has 2-step verification enabled, a password change requires also providing a verification code. So, someone who doesn't have access to your phone can't lock you out by simply changing the password.

May 9, 2011 at 12:43 PM
Unknown said...

i received an alert saying that my account had been accessed from an ip in CA - this was obviously not me. After looking further into my account i noticed it had stored address and billing information from a purchase long ago - how do i remove this data from my account?

May 16, 2011 at 1:20 PM

Post a Comment

  

Labels


  • #sharethemicincyber
  • #supplychain #security #opensource
  • android
  • android security
  • android tr
  • app security
  • big data
  • biometrics
  • blackhat
  • C++
  • chrome
  • chrome enterprise
  • chrome security
  • connected devices
  • CTF
  • diversity
  • encryption
  • federated learning
  • fuzzing
  • Gboard
  • google play
  • google play protect
  • hacking
  • interoperability
  • iot security
  • kubernetes
  • linux kernel
  • memory safety
  • Open Source
  • pha family highlights
  • pixel
  • privacy
  • private compute core
  • Rowhammer
  • rust
  • Security
  • security rewards program
  • sigstore
  • spyware
  • supply chain
  • targeted spyware
  • tensor
  • Titan M2
  • VDP
  • vulnerabilities
  • workshop


Archive


  •     2025
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2024
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2023
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2022
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2021
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2020
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2019
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2018
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2017
    • Dec
    • Nov
    • Oct
    • Sep
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2016
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2015
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2014
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • Apr
    • Mar
    • Feb
    • Jan
  •     2013
    • Dec
    • Nov
    • Oct
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2012
    • Dec
    • Sep
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2011
    • Dec
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
  •     2010
    • Nov
    • Oct
    • Sep
    • Aug
    • Jul
    • May
    • Apr
    • Mar
  •     2009
    • Nov
    • Oct
    • Aug
    • Jul
    • Jun
    • Mar
  •     2008
    • Dec
    • Nov
    • Oct
    • Aug
    • Jul
    • May
    • Feb
  •     2007
    • Nov
    • Oct
    • Sep
    • Jul
    • Jun
    • May

Feed

Follow
Give us feedback in our Product Forums.
  • Google
  • Privacy
  • Terms