For heavy users of Google services, the gmail account has over the years evolved into a "Google account" and holds the key to an increasing amount of our online activities and presence. Judging from a random sampling of the gmail support forum or some reports in the press (E.g. this recent article from the Atlantic Magazine) - gmail account hijacking is an increasingly widespread and serious problem.
Stolen account IDs from major web-mail providers (gmail, hotmail, yahoo mail etc.) seem to be collected and used at industrial scale for spam generation and fishing for 419 style advance fee fraud schemes like the infamous "mugged in London" scam described in the article above.
The mechanics of some common threats used to steel account passwords is described in this blog post in some detail, but in short it boils down to weak passwords, password re-use and password sniffing malware. Given how prevalent malware infestations are on major OS platforms, even users who are careful in their password policies cannot reasonably ensure that their account is not being hijacked.
Fortunately, Google has recently introduced a 2-factor authentication option for its gmail/Google accounts. Two-factor authentication is typically based on a secret the user knows (the traditional password) plus something the user owns - in this case their cell-phone or a paper with some pre-generated one-time use validation codes. Even if the password is compromised, the second factor would have to be stolen at the same time for the attack to be successful.
Multi-factor authentication has long been used for online-banking as well as for security conscious applications in corporate or government IT services, but the additional security comes at the cost of reduced usability and increased risk of lock-out (e.g. by forgetting, loosing or breaking the security token/device).
In the case of gmail 2-step verification, the usability nuisance is relatively minor: the security token is the user's cellphone - a device which most of us carry around religiously anyway by now and one verification can be extended for 30 days on trusted computers as an option on the login screen - e.g. on my computer at home, but not on a public computer in a library or internet cafe. For users of Android or iPhone smart-phones, there is even an Authenticator app, which turns the phone into a security token without the need for network connectivity and the ability to receive SMS messages with the login verification code. The authenticator app is easily seeded/configured to the account by scanning a bar-code with the phone camera during setup of the 2-step verification (may need additional barcode scanner app).
My biggest concern is the increased risk of lock-out from this more complex setup. Specially since the practical absence of support from Google for the free consumer gmail accounts (for supported accounts with SLA, see here), a lock-out which the user can't recover from is likely a permanent loss of the account - but so might be a malicious case of hijacking.
For existing accounts, the activation of 2-step verification is fairly hidden on the account settings page. However the setup is fairly easy and self-guided once the setup page is reached.
Before enabling 2-step verification, make sure that recovery/verification email and phone settings are correct and reachable, just in case. During activation of the 2-step verification, generate a set of backup codes and store in a safe location accessible without the cellphone or gmail account (E.g. print out or use a password safe for this) - before trying to re-login with the new account settings.
Enabling 2-step verification on an existing account will also lead to failure of any existing programmatic login setups, e.g. for Android/iPhone mail/calendar sync, POP/IMAP access, chrome sync, cloud print etc. Some of these now use oAuth delegation which can be re-authorized with 2-step verification after enabling it or may require generating an application specific password to get working again. Since application specific passwords are long random strings and thus hard to guess or crack and are not typed in other than during setup, they are not as much at risk for hijacking - unless the computer where they are stored is compromised (e.g. laptop stolen) or transmitted in clear over an insecure network (e.g. airport wifi - make sure to enable SSL in mail clients!) - and their usage is limited on a few programatic login interfaces and not for general web login.
Stolen account IDs from major web-mail providers (gmail, hotmail, yahoo mail etc.) seem to be collected and used at industrial scale for spam generation and fishing for 419 style advance fee fraud schemes like the infamous "mugged in London" scam described in the article above.
The mechanics of some common threats used to steel account passwords is described in this blog post in some detail, but in short it boils down to weak passwords, password re-use and password sniffing malware. Given how prevalent malware infestations are on major OS platforms, even users who are careful in their password policies cannot reasonably ensure that their account is not being hijacked.
Fortunately, Google has recently introduced a 2-factor authentication option for its gmail/Google accounts. Two-factor authentication is typically based on a secret the user knows (the traditional password) plus something the user owns - in this case their cell-phone or a paper with some pre-generated one-time use validation codes. Even if the password is compromised, the second factor would have to be stolen at the same time for the attack to be successful.
Multi-factor authentication has long been used for online-banking as well as for security conscious applications in corporate or government IT services, but the additional security comes at the cost of reduced usability and increased risk of lock-out (e.g. by forgetting, loosing or breaking the security token/device).
In the case of gmail 2-step verification, the usability nuisance is relatively minor: the security token is the user's cellphone - a device which most of us carry around religiously anyway by now and one verification can be extended for 30 days on trusted computers as an option on the login screen - e.g. on my computer at home, but not on a public computer in a library or internet cafe. For users of Android or iPhone smart-phones, there is even an Authenticator app, which turns the phone into a security token without the need for network connectivity and the ability to receive SMS messages with the login verification code. The authenticator app is easily seeded/configured to the account by scanning a bar-code with the phone camera during setup of the 2-step verification (may need additional barcode scanner app).
My biggest concern is the increased risk of lock-out from this more complex setup. Specially since the practical absence of support from Google for the free consumer gmail accounts (for supported accounts with SLA, see here), a lock-out which the user can't recover from is likely a permanent loss of the account - but so might be a malicious case of hijacking.
For existing accounts, the activation of 2-step verification is fairly hidden on the account settings page. However the setup is fairly easy and self-guided once the setup page is reached.
Before enabling 2-step verification, make sure that recovery/verification email and phone settings are correct and reachable, just in case. During activation of the 2-step verification, generate a set of backup codes and store in a safe location accessible without the cellphone or gmail account (E.g. print out or use a password safe for this) - before trying to re-login with the new account settings.
Enabling 2-step verification on an existing account will also lead to failure of any existing programmatic login setups, e.g. for Android/iPhone mail/calendar sync, POP/IMAP access, chrome sync, cloud print etc. Some of these now use oAuth delegation which can be re-authorized with 2-step verification after enabling it or may require generating an application specific password to get working again. Since application specific passwords are long random strings and thus hard to guess or crack and are not typed in other than during setup, they are not as much at risk for hijacking - unless the computer where they are stored is compromised (e.g. laptop stolen) or transmitted in clear over an insecure network (e.g. airport wifi - make sure to enable SSL in mail clients!) - and their usage is limited on a few programatic login interfaces and not for general web login.