0

Is a Google login actually any more secure than a username and password login?

Assuming the username + password uses encrypted passwords in the DB and a 1 week access token, I don't really see how it would be more secure.

1 Answer 1

1

As with many things within the broader spectrum of security, there are multiple points of view to approach this issue.

For example, a user may not know how well the developers of an application understand security. They may store passwords hashed with argon2, sufficiently chosen parameters and a uniquely generated salt. They may store passwords hashed as unsalted md5. They may store passwords encrypted with AES, and have the password be the hash of the user's email address. Or they may store the passwords in plain text in addition to storing them as a salted hash, so they can send the password to users in case they forgot it.

Before you laugh, I have seen each one of these in the wild. These aren't contrived scenarios - this happens in real life.

So for a user, they have no idea how well their credentials are going to be protected. So a third-party login, from a company that is way more likely to know how to write secure applications, may actually increase security. After all, the developers can't lose what they never have.


Another set of users may think of a "login with Google" button as a mere convenience. Chrome and derivatives are ~70% of the desktop browser marketshare, and quite a significant amount of Chrome users will have Google accounts as well. Therefore, a "login with Google" button will be very convenient for a lot of users, thus driving up engagement.

While this is no security perspective, it is one of the driving factors behind third-party login.


For a developer, third-party logins are also quite nice, because they shift the burden of keeping everything secure to the third-party. Especially, if that third-party has features such as multi-factor authentication (based on TOTP, FIDO2, etc.) or anomaly detection, which are non-trivial to implement.

Thus, a developer can reap all the rewards of Google's work, without putting in any of the work themselves.


However, authentication with third-parties isn't all sunshine and rainbows. For example, if a user has registered with an application using Google login, and later decides to stop using Google for whatever reason, there may not be an easy way to migrate accounts in every service, without "registering again", which may have undesired side effects, depending on the application (e.g. loss of progress in an online game).

This has another variant, where the service itself terminates a user's account, such as Twitter suspending a user for "violating community guidelines". In such an event, that user would not also lose access to their twitter account, but also to any application, which uses Twitter as third-party authentication provider.


Which one is more secure?

Both can be made secure, but it's likely that large tech companies like Google have thrown more engineers of higher caliber at the issue than a small-to-medium company likely can afford to do.

The fact that you speak of "encrypted passwords", rather than "password hashes", even if you mean the right thing, indicates that you are not an expect in the field and are more likely to make grave mistakes. Mistakes, which ultimately your users have to pay for.

So to summarize: Both can be made secure, but one has a much higher likelihood of actually being secure.

1
  • Other things to add: using a Google login means that Google will receive information about which services you log into, even if they do not use Google analytics. Finally using Google login for everything means that in the (unlikely) event that someone gets access to your Google credentials they can use them to access everything you have instead of just the Google services.
    – GACy20
    Jul 14 at 7:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.