Security Blog

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

Password strength and account recovery options

15 July 2009
Share on Twitter Share on Facebook
Google

25 comments :

FilterJoe said...

Thanks for opening up a conversation about this subject. One thought I've had recently is that it is in the best interest of Google and all vendors of web apps to have a high level of security. If free Google Apps accounts and/or Google accounts are getting routinely broken into, it is bad for Google in several ways:

* Trust for Google decreases

* Fear of trusting data to the cloud increases

* Spam increases (spam bots get contacts)

* Expense for Google increases (support requests to help users recover compromised accounts)

On the other hand, if Google can enable a user experience which makes data MORE secure than desktop data, then it will help secure more corporate customers.

Given these incentives, I think it is in Google's best interests to trickle down some of the features from Premier Apps down to Free Apps and Google Accounts. Specifically (for free accounts):

* SAML SSO enabling two factor authentication

* Allow administrators to set password length requirements

* Make it possible for a Google Apps administrator to remove administrative rights from any user (including the one that established the Google Apps account - if this ends up as a frequently used account, then it is more likely to get compromised than a rarely used account that is only used to administer Google Apps)

I certainly understand that Google needs to differentiate between Premier and free versions of Google Apps. And I think the free version of Google Apps is an incredible product. But adding just a couple of extra security features to the free version could be of great help to both users and to Google.

15 July 2009 at 16:56
Aniruddh D said...

I thin Google should allow to add up security tokens with the Google apps account so people able to do the check. as you know that ATM cards works only with the combination of pin and card..if both things not matched then nothing gonna happen..

same thing should be here..a Google apps password and a security card like an ATM without the combination no access to Google Apps..and Google should not put security as a feature..all premium level security feature should get in all Google Apps account weather its free or paid..

If possible attach Google apps authentication system with fingerprint reader ...that would be much accurate than the password security..

i think all companies should think beyond passwords..web 2 has come so I think in security it's time to implement new level of protocols..password is old thing now..

15 July 2009 at 18:47
George said...

Security has always been our major concern in this online world. Almost everybody is maintaining accounts online like emails, on purchasing products, online game subscriptions and a lot more. You may also want to check this article about online safety: http://www.articlesbase.com/video-games-articles/safety-in-the-world-of-warcraft-1014729.html

16 July 2009 at 00:52
Nick Owen said...

IMO, most small companies see a net increase in security by outsourcing their IT. It is just too hard to keep up with patches, attacks etc while maintaining valued services for employees.

That being said, if you rely on a basket of web-based apps, you should watch that basket.

Here's a tutorial I wrote on how to use the open-source version of WiKID Strong Authentication with Google Apps Enterprise for those interested in adding two-factor to Google Apps.

16 July 2009 at 09:40
Engrey said...

I do like the idea of having an authenticator that can be used for apps or email.

This way the password could be different every time you log-in.

World of Warcraft does this as someone already posted, and that is for a game.

The app could be made for Pre, Iphone, or other smart phone devices or as a device you buy for say 5-10 dollars.

A pretty low price to pay for more security.

16 July 2009 at 10:51
Carl said...

Protecting my personal gmail account is something I take seriously, I really wish that Google would enable me, a personal free email account user, to purchase and use a 2 factor token. For me there is no problem coming up with 20 bucks for a token like I did for Paypal. The cloud is here to stay and that means much more exposure to risk for everyone. Corporations (like Google) can fend for themselves and protect their assets with 2 factor authentication. It hurts know that Google will not offer their customers a way to protect themselves, even if they are willing to bear the cost. Please make 2 factor authentication available for the all users.

16 July 2009 at 21:52
Unknown said...

Is there a reason you can't adjust the password length requirements on Google Apps standard edition? I know that's the free version, but isn't security just as important, free or not?

Just wondering.

17 July 2009 at 11:38
chrisco said...

One word: Gtoken (2-factor authentication). Where is it? Should be a paid upgrade for Gmail and Google Apps.

17 July 2009 at 19:59
Raman said...

2-3 weeks back my wife's gmail account got compromised and her pwd got changed. She changed it 3-4 times and everytime she changed it should to get hacked or god knows what the next day.

There is no way to get access back to the gmail account. The password recovery form asks questions like date/month and year of account creation, how does google think that an individual will remember such things. It has all these questions with months and dates that it is next to impossible to get your account back.

There is no way to write to google for help, there is just no email or contact form. You just keep going round and round and eventually land at the same place.

Can you pls help us out.

19 July 2009 at 13:12
Anonymous said...

perhaps someone here could help.

I've been a huge gmail/blogger fan for the last five years. i've misplaced my pw and can only read my mobile gmail on my iphone and can no longer log into google to blog - www.fixbuffalo.blogspot.com - and no nolonger have access to my secondary email to do the pw recovery routine.

Any work arounds? Thanks in advance for your help.

david torke @ gmail.com

20 July 2009 at 16:43
Jan Zawadzki (Hapara) said...

The reality is that relative risk is much higher if the account is a corporate one, and a whole lot of information is suddenly exposed.

The reality also is that this is easy to guard against, and that any enterprise users should use two-factor authentication for Google Apps, SFDC or any other cloud platform.

Two-factor btw means that in addition to the username and password the system requires another unique bit of information. We normally use a phone-based app for this: when coming in from the "outside" you get asked for your username, password, and the magic number displayed by our app on your phone. Most people have their phone within reach at most times, so it's easy.

Adding this level of control to your Google domain takes a day. There is no excuse not to, if your information is valuable enough. This isn't rocket science.

J

21 July 2009 at 06:00
K800 said...

Has there been any thought to supporting the use of client digital certicates to strengthen authentication to google apps / gmail?

ie as available from entrust, verisign, thawte etc

Craig Leppan.
leppan.craig@gmail.com

23 July 2009 at 16:14
Anonymous said...

nice blog. i liked it!
Web Design India

28 July 2009 at 04:56
Abdelrahman Ellithy said...

I really use a lot of ways to make my pass stronger
1- using numbers
2- using alternating capital and small letters
3- using symbols : & * $

this password would never be guesed by any program in million years

29 July 2009 at 16:44
Abdelrahman Ellithy said...

I really use a lot of ways to make my pass stronger
1- using numbers
2- using alternating capital and small letters
3- using symbols : & * $

this password would never be guesed by any program in million years

29 July 2009 at 16:45
Andika Triwidada said...

I've been getting some wrong email notification, due to new user mistakenly put my email address as his/her secondary. Then I can takeover that account by sending a 'password forgotten' request.

I believe GMail must add extra steps to verify secondary account ownership, to prevent this kind of attack.

13 August 2009 at 04:00
RayTMercer said...

Macduff: I am the admin of a Google Apps Education domain (student.columbustech.edu). I spend more time resetting forgotten passwords than any other job I do. Is there a way to add the password recovery feature to a domain? My LMS and SIS have that feature, but we do not have a SSO system.

19 August 2009 at 14:56
Anonymous said...

I have developed a way to address this issue and on my way to setting up a business around it.

founder, easysecured.com

18 September 2009 at 17:58
vijay said...

Here's a way to add strong authentication including Free Verisign VIP mobile tokens (yes, the same you use for accessing Paypal, etc) to your Google Apps.
You do need to be a Google Apps Premier customer. Offered by www.myonelogin.com in partnership with Verisign.
To signup go to: http://www.myonelogin.com/googleapps/

1 October 2009 at 18:15
Anonymous said...

The way to go is password less user authentication which my company has developed.

Here the user does not require to define or enter a password or remember it. The password is generated by the unique identity of the users computer or device and is not stored anywhere thus making it inherently more secured.

Imagine an online database on a server such as google's where there is no password field.

you can head to easysecured.com to know more about this technology.

3 October 2009 at 15:18
MakeSafePassword said...

To automatically generate a password that will fit with google (and other's) password strength requirements, use the tool at http://makesafepassword.com

(tip: set it to also use punctuation for sites that allow it, for extra security.)

18 November 2009 at 15:21
Unknown said...

There should be a simple way, when creating a new Google account, to simply turn the whole darn password recovery thing off. Not the default, but there in a tiny checkbox for those who really need it.

Password recovery is a CONVENIENCE that compromises SECURITY. Some of us would rather be inconvenienced by having to actually create a rock solid way of remembering our passwords than have the extra complexity and risk of the password recovery apparatus.

Problems with password recovery:

o The recovery email is sent unencrypted; a sophisticated attacker
could read it in transit.
o If the secondary email is hacked,
your ENTIRE Google account is hacked (doubles the attack surface)
o You have to make sure the recovery
email is always active (some emails will be deactivated if unused for a period of time)
o I have to think about all these various scenarios, rather than just remembering the darn password!

PLEASE GIVE US THE ABILITY TO OPT OUT OF PASSWORD RECOVERY AT ACCOUNT CREATION TIME!!!

25 December 2009 at 21:46
Ali Hamdar said...

A security policy includes different requirements: password length, complexity, age, sharing, disclosure etc...

This article describes in details about password policies.

3 March 2010 at 16:57
Anonymous said...

I would happily pay for a Google security token, similar to the Paypal security key. I keep my whole life on your server so I'd like to keep access secured!

26 March 2010 at 18:04
Anonymous said...

I like this.. it is like added security and allows you to see if someone has changed your password

Gmail Technical Support

16 January 2014 at 14:25

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
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2023
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2022
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2021
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2020
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2019
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2018
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2017
    • Dec
    • Nov
    • Oct
    • Sept
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2016
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2015
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2014
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • Apr
    • Mar
    • Feb
    • Jan
  •     2013
    • Dec
    • Nov
    • Oct
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2012
    • Dec
    • Sept
    • Aug
    • Jun
    • May
    • Apr
    • Mar
    • Feb
    • Jan
  •     2011
    • Dec
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • Jun
    • May
    • Apr
    • Mar
    • Feb
  •     2010
    • Nov
    • Oct
    • Sept
    • Aug
    • Jul
    • May
    • Apr
    • Mar
  •     2009
    • Nov
    • Oct
    • Aug
    • Jul
    • Jun
    • Mar
  •     2008
    • Dec
    • Nov
    • Oct
    • Aug
    • Jul
    • May
    • Feb
  •     2007
    • Nov
    • Oct
    • Sept
    • Jul
    • Jun
    • May

Feed

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