Skip to content
Naked Security Naked Security

Google takes another stab at killing passwords

Google is testing a way to log into devices with a challenge sent to your Android or iOS phone, rather than a password.

Sayonara, “password,” and fare thee well, “123456”: Google’s testing a new way of logging in with mobile phones instead of flimsy (though depressingly, persistently popular) passwords.

Google last month confirmed to Android Police that it’s testing the feature with a small number of users on both Android and iOS mobile operating systems.

The publication quoted a Google spokesperson who gave this password-menacing statement:

We've invited a small group of users to help test a new way to sign in to their Google accounts, no password required. 'Pizza', 'password' and '123456' - your days are numbered.

Do we really need a new way to sign into our Google accounts?

It’s not a bad idea, given that passwords are often the weakest link in authenticating that users are who they say they are.

As the yearly lists of the top bad passwords show, many don’t use passwords that are complex enough.

Others reuse passwords, setting themselves up for account break-ins when online crooks acquire logins from breaches or third-party sites, such as happened recently to Fitbit.

Two-factor authentication (2FA), also known as two-step verification (2SV), can help, but some users find it a hassle to go through the extra step when logging in.

Android Police first got wind of the potential new password-less feature from a user invited to participate in the test: Rohit Paul, also known as Reddit user rp1226.

The test group, called Sign-in Experiments at Google, can be found on Google Groups.

The link is public, but membership is by invitation only, so you can’t view or participate unless you’ve been tapped for participation.

Based on the screenshots and the emailed invitation Paul posted, it looks like the new feature works by first setting it up on a compatible phone.

Paul’s phone, a Nexus 6P, was approved. It’s not clear what made it acceptable.

Of course, the feature could prove troublesome if the phone were to fall into the wrong hands.

While Google recommends using a lockscreen or Touch ID to avoid other people abusing the feature if they get physical access to a device, it doesn’t appear that such features are mandatory to participate in the test.

On Dec. 22, Paul posted Google’s invitation, along with screenshots showing how the password-less sign-in works.

Here are the authentication steps for users participating in the test, as Paul described them:

  1. Type in your email address on the login screen for Google, at google.com, and hit next.
  2. The next page tells a user to check their phone and enter the challenge.
  3. A notification appears on the phone: “Trying to sign in?”
  4. When he opened the phone notification, Paul was asked if he were trying to sign in from another computer. He answered yes.
  5. Next, a user would enter the challenge, which in Paul’s case was a two-digit number.
  6. That signed him into Google’s page on his computer.

Testers can still opt for typing in passwords whenever they choose – say, when the feature isn’t available or their phone isn’t handy.

Also, Google says it might ask users to enter their password if they spot something phishy about how a user’s logging in.

Readers, would you opt for going through those steps to log in if given the chance? Or do you think, as some commenters suggested, that you could type (your long, strong password) faster and would rather skip the extra step?

Will the people who really need this, the ones who use 123456 as their universal key to everywhere, use it?

And if it proves popular, could widespread use of Google as a single sign-on provider make this just another single point of failure – a bulky, metal and plastic reused password?

Please share your thoughts below.

Image of easy password courtesy of Shutterstock.com

26 Comments

The problem with all of these is that they still require a secret to be sent to someone, somewhere. That’s why I’m so excited about the prospects for SQRL: it’s the only one I’ve seen that doesn’t do that.

Reply

Forgive my ignorance, but SQRL seems to me to be operationally equivalent to – a sort-of reinvention of, if you like – a TLS connection to a new and previously unknown website, where you get confidentiality, identity and integrity without sharing a secret up front.

I must be missing something here…doesnt SQRL’s identity depend on just the same approach as TLS? There’s a domain name that gets decrypted and displayed (more prominently than TLS in a browser, though that is a detail), and you need to validate that it looks right, without accepting bogus-looking domain names or ignoring certificate warnings. Given the propensity of companies to outsource their various websites and even their authentication, won’t SQRL just reinvent the problem of buynow.example.com‘s login page being hosted by s6223-auth-cdn.eg.text, and presenting itself accordingly, to the confusion of the user?

(I’m not saying SQRL is a bad idea. Just trying to understand what currently-exploitable security confusion it might inherit.)

Reply

Learn about SQRL from the source: Steve Gibson of Gibson Research Corporation.

Reply

As you may infer from my comment above, I have read up on SQRL “from the source,” which is what caused me to ask myself the question above…and I couldn’t figure out an answer from the site itself. I figured that because the OP is “so excited about the prospects for it,” he probably knows (or understands) more about it than I, and so I asked the question here.

As I mentioned above, I’m not saying SQRL is a bad idea, but rather wondering aloud what operational issues it might have.

Reply

Even if the “buynow” login page is hosted by some other (authorised) org, the URL will still be shown in the user’s browser as “buynow” (with, e.g., EV certificate indication if applicable). So when the user is asked by the SQRL app to authenticate to “buynow” they will rightly be happy to do so, since behind the scenes their message will only be sent to that domain.

Yes, the user does still have to be careful to make sure the SQRL app is asking them to authenticate to “buynow”, not “boynow”. But that’s all they have to do – there are no certificates etc to worry about.

I’ve been following SQRL and Steve Gibson’s explanations for some time, so I hope I got this right. But if not then I’m sure Steve could explain it better – he reads tweets on @SGgrc, apparently, and may well respond to such a well-respected security person as yourself, Paul (I listen to your podcasts, as well as his!).

I’d urge any other readers to look at the source, as SQRL looks to me like the best solution for the problems it addresses.

Reply

No, SQRL runs over TLS and replaces usernames and passwords with a single, deterministically-generated public key. The identity is confirmed by the SQRL client signing a random and unique challenge, proving it can generate the public key.

Reply

Am I missing something here, or is this just 1FA?

(Some UK banks already use a very similar process, though you also need a password that is the same for each login too, as in regular 2FA. The browser shows a number and you enter the number on your phone. Instead of using SMS, however, the bank’s automated system makes a voice call and you enter the code at the phone keypad. Same thing in the end. Both systems are man-in-the-middleable or man-in-the-browserable in a similar way to SMSes that arrive on your phone and are typed into the browser instead. A system that requires both the challenge and the response to be out of band on your phone would IMO be better. Some South African banks do this. You pretty much need to crack the lock code on the phone or do a SIM-swap to bypass the system, or you need to man-in-the-middle the phone instead.)

Reply

I think you are correct: it’s single factor authentication. Looks to me like the factor is changing from ‘something you know’ (your password) to ‘something you have (your cell phone). One might argue that it is a separation of risk (i.e., less likely that I have your cell phone compared to the possibility I saw the post-it note on your keyboard) but it is not defense in depth. I still prefer two factor authentication.

Reply

Well it could count as 2FA, I guess… You need a phone and a connection. The two don’t always go together here in rural England.
Not only is it a single factor – but it’s an easily nicked one. And it seems to effectively replace your (nice, complicated, of course) password with the pin on your phone.

Reply

I think the primary motivation is enhanced tracking, not enhanced security. All these use-your-mobile-as-the-key schemes tie a neat little bow around your various desktop and tablet identities and add in geo-location from installed apps as frosting. All the better to suck more money out of advertiser’s wallets (and ultimately yours), of course…

Reply

“Testers can still opt for typing in passwords whenever they choose – say, when the feature isn’t available or their phone isn’t handy.”
Is this only while the feature is being tested or is that the intended implementation? As long as you can access the account with a password, the problems with passwords still exist.

Reply

I’ve been using the very similar Microsoft sign-in app on my phone for a while. Anytime I sign in on an “un-trusted” device my phone displays the attempt immediately and asks if I want to approve or deny the request. It works quite well.

Reply

Anything that uses SMS is not really 2 factor in some circumstances. I have an Android phone and an Exchange account. There are either default setups, or a choice I made, that results in SMS message that I receive being copied to my email account, and thus I see them on my PC (but not the phone) in my email inbox.
Thus a compromised email account is not protected at all by having SMS for authentication. I have not looked into where and how the SMS is added to the inbox to see what opportunities exist for interception. I just assume that anything sent by SMS is no safer than anything sent by email.

Reply

Its not SMS, is push notification through CGM or APN.

Reply

That doesn’t, ipso facto, make it safer than SMS, does it? (If your mobile provider offers an SMS-to-email service, presumably they could offer an any-sort-of-message-to-email service. if the forwarding is done on your phone, you’d need to make sure its turned off if you want messages to your phone to be “a different communications channel.”)

Of course, if your phone/phablet is also a stand-in for your laptop, the browser and the message may very well be the same channel of communications :-)

Reply

Two-factor authentication (2FA) is not only a huge hassle, it is exceptionally overrated. Once you lose your droid phone, and you try to log on to google to locate it, how are you even going to be able to do that? See the catch 22 situation here? Same goes for any other account where you use 2FA. If you are using Google Authenticator, and you format your phone, you will lose all settings and good luck trying to get back into your account.

Reply

Sounds to involved to be taken seriously. If it’s not Immediate and easy it will not be adopted. It’s also to dependent on multiple services. Out of cell range, or service is down, no access to your device at all. It becomes a Grick – (google brick – I make this new word public domain)

Reply

No thankyou I don’t subscribe to a cellular service I just have an android phone that I use on wifi with my google hangouts. If I am in a place where I can’t connect my phone to an available network I will not be able to access my email. My password is strong and more than sufficient to protect my google services. Not to mention I have tried 2 step verification and it was a huge hassle due to the fact that the place I worked at the time did not have cellular reception when I did pay for service. I believe that this is a pipedream for now as it is simply too inconvenient for the average user.

Reply

I think, depending on where you are in the world, “Your mileage may vary.” In many countries, at least in major metro areas, you will never be out of mobile phone range. LTE or 3G may not be available, but mobile phone and SMS services, as good as never.

In the developing world, for example, it’s as good as impossible to get a landline in many places, especially if you don’t have a proper address, and even if you do have a landline it will be disrupted on a regular basis because crooks come and steal the local-loop copper cable to melt it down and sell it off. So mobile services are “the only way” – it’s unlikely you would have Wi-Fi coverage via fibre-to-the-premises or via ADSL/VDSL but not a mobile phone signal…

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!