Your Android Phone Is a Security Key
blog.google
blog.google
But, apart from that: 1. It's only on Chrome (for now(?)) 2. It's only for Google products (for now (?)) 3. It's only on Android that Google fully controls remotely (and probably it will stay there).
All these give even more power to Google at the expense of convenience and allows a single company to define "how things should be done".
And I should clarify that I am not against this tech specifically. If anything, I think Google has some of the brightest minds, so technically I'm sure that the product will be great.
The problem is that with great power comes something that Google (as a company) seems to be lacking lately.
> “Under the covers, however, the phone and computer are communicating with the FIDO CTAP protocol over Bluetooth and the website and computer are communicating with the WebAuthn protocol and this adds the phishing-resistance. [...] But for now at least, the feature can only be used for 2FA on Google accounts. Google has submitted caBLE to FIDO and it’s under review by the working group.
[0]: https://venturebeat.com/2019/04/10/you-can-now-use-your-andr...
Government websites won't support it, nor most financial services, your gym, school, job, etc. Sensitive records like your SSN will be kept in walled gardens accessible by a simple user and password, and maybe a security question. Most people will still be at significant risk of exposure because the real targets of information theft aren't logged into by end-users.
But your Gmail account will be locked down.
The naive optimist in me wants to think that making security keys accessible to more users, and getting them used to them, will lead to pressure for other services to follow suit. But then I think about how long people have been criticizing banks for ridiculous password policies that are seemingly universal in the industry, and I know better. Or bad security practices at organizations in general. I'd very much like to be proven wrong.
We're in a day and age where people should be using password managers (even my tech illiterate parents use them). So why are character limits set so low? I want my bank password locked down. And we're in an day and age where (1) shouldn't even be an issue. I'm not sure what other issues people face, but I've seen these patterns with multiple banks.
I think banks get lip more because they are a clear case where security should be VERY high. Just like you should protect your email strongly (note google does (1)[0]).
[0] https://screenshots.firefox.com/v9AjmrW7jtr1aGg3/accounts.go...
[0'] If someone is an actual security expert, I'd like to know why (1) is an acceptable practice. (My bank does it, but they pass you to the password page no matter what you type in, which seems safer than what google is doing)
So your issue here is that Google tells you whether it's a valid email address before you enter in a password?
You could validate email addresses yourself by sending out a ton of emails to different permutations of *@gmail.com and seeing which ones come back as undeliverable. An email address on its own isn't inherently private so this doesn't seem to be a security risk to me unless I'm missing something.
AIUI, splitting the entry across two screens like that breaks a lot of password managers, as they can't handle it. This hampers the adoption of password managers, which would largely help the average Joe's security.
Google supports external auth in some cases¹, and to know whether they need to redirect to that auth, they first need your username / email. Then, you're either redirected or you're shown the password entry prompt.
I don't know of any banks that do this, so this might not be applicable to them. (Theirs might just be bad design.)
¹GSuite, not consumer GMail, but I assume the flows are the same
I'm definitely dumb enough to not realize that email login might be a special case because you can check username validity another way (sending emails). And I didn't know that GSuite had external auth.
These split pages don't actually break lastpass, at least for me. One field is still called username and another is called password, so they fill properly.
On the other hand, insecure e-mail has been at the center of massive political upheavals. I think securing e-mail is way more important than even banking information.
For anyone who has or will have people interested in their particular accounts, not just bulk breakin of simple passwords that should be forbidden in most sites, it becomes a much worse risk profile, as you often can't turn off places letting you use that data point as one part of verification.
Here millions are currently checking their pre-filled tax returns, which they have accessed using smartcard authentication, so Gmail ain't that far ahead.
And don't count out governments just yet, U2F got some love: https://www.yubico.com/why-yubico/for-business/authenticatio...
Having a source publicly available is one of the prerequisites for something to be considered open source, but it's far from being the only prerequisite.
You know, it's nice they phrase this as an "option", but in my experience Google has the habit of forcing me to have my phone on me when I login from a new location / new device, something I never asked for and apparently cannot disable.[0] This has locked me out of my Google account more than once which also locks me out of anything that sends 2FA to my Gmail or Gvoice. I guess I'm thankful that I've learned this in non-emergency scenarios, as I'm now prepping to degoogleify myself, but it's a user-hostile in my opinion. Security always has convenience trade-offs, but let the user decide where they want to draw that line.
Remaining options include: 1. give date(month year) of email sign-up, which most don't remember
2. pasword reset over alternate email address, which wasn't set during signup.
The only way for free gmail users to get help is support forum ran by gmail user volunteers, which didn't solve the problem. To me this approach to security, just seem super paranoic.
However i've never encountered a TFA service that let you disable it in certain scenarios so i may be wrong
https://myaccount.google.com/signinoptions/two-step-verifica...
I appreciate your help, though!
[0] https://support.google.com/mail/forum/AAAAK7un8RUP1RC23nwRZ4
[1] https://support.google.com/mail/forum/AAAAK7un8RUZvZQQfsawrE
Dashboard -> select Security -> Basic Settings -> Two-Step Verification setting
Source? I understood that having a HW-backed key store is still entirely optional for the purpose of Android certification.
On top of that, I noticed some ambiguity on whether a TEE like ARM TrustZone qualifies as a hardware-grade protection mechanism in the same way a discrete and dedicated crypto processor is (I think the two technologies provide very different assurance levels).
"When the device implementation supports a secure lock screen it MUST back up the keystore implementation with secure hardware and meet following requirements: MUST have hardware backed implementations of RSA, AES, ECDSA and HMAC cryptographic algorithms and MD5, SHA1, SHA-2 Family hash functions to properly support the Android Keystore system's supported algorithms. MUST perform the lock screen authentication in the secure hardware and only when successful allow the authentication-bound keys to be used. The upstream Android Open Source Project provides the Gatekeeper Hardware Abstraction Layer (HAL) that can be used to satisfy this requirement. "
https://www.blog.google/products/pixel/titan-m-makes-pixel-3...
With that said, I cant find mention of this on the page so it's probably not leveraging this.
As Android 7.0 is available to install on any device and I don't see anything about "certified android devices", I assume they mean ANY Android 7.0 device? Then again it only works with Google services atm, but I know you can sideload google play services so...
Don't get me wrong, it's still better than TOTP in many ways, but having the actual security coprocessor is a big distinction.
Lots of independent websites market this form of 2FA as "Google Authenticator". It's kinda like asking people to enter their gmail address (rather than their email address).
Eitherway, TOTP is a big step away from putting all your 2FA eggs in Google's basket.
A phone is better than nothing. A real token would be much better.
ADDED: I do have other 2FA hardware as well. But I assume I'm not guaranteed to have it with me when I need it.
My phone case has a slot for credit cards, so all I normally carry with me is my phone, a credit card, my work badge, and my transit pass.
TOTP for GMail assures Google that the same person who enrolled the account was given custody of a key.
The physical token only adds value in scenarios where phones aren’t available or you need to assure the identity of the individual.
For most people, it's so far outside what they're familiar with that it feels alien and incomprehensible. It makes absolutely no sense to them. So they're not going to do it or adopt it quickly.
User education will catch up in time, but that will take quite a long time.
The Google Titan Key looks like a car keyfob, so I don't really agree with you on this.
A security key device ought not to be remotely writeable.
A read-only, non-wireless security key like Yubikey would be even more secure, but this is an improvement over TOTP codes, which can be phished.
This is also better than SMS 2FA, which is prone to phone-number theft.
It's also better than Push notifications for 2FA, which relay on third-party servers.
This solution uses Bluetooth between your phone and the Chrome browser, offering a good balance of security and convenience.
But an article from VentureBeat[0] mentioned it's a new transport called 'cloud assisted Bluetooth Low Energy' or caBLE, which they've submitted to FIDO for standardization.
[0]: https://venturebeat.com/2019/04/10/you-can-now-use-your-andr...
To make this work, we made an extension to WebAuthn+FIDO for pairing-free BLE as Rafert points out. We're already in the process of making that open together with these standards bodies, stay tuned!
This is because the browser needs to pass the origin to the device and ensure the webpage can't impersonate another origin.
Who would have thought 5 years ago.
We (the team behind this at Google) work actively with FIDO and the W3C on the open standards behind this so that other browsers can support this as well in the future.
> We (the team behind this at Google) work actively with FIDO and the W3C on the open standards behind this so that other browsers can support this as well in the future.
Super excited to hear this.
Use a damn yubikey; they're practically free and don't monetize their users.
no it's not. it's pretending to be, but without vendors actually maintaining and investing in their forks and the hardware having a known good security enclave, you might as well post your credentials on twitter.
- you post your credentials on Twitter
- I'll store mine using this Android Phone
Let's see who gets hacked first!
It got certified (at level 1[0]) too, in case that changes your mind: https://fidoalliance.org/android-now-fido2-certified-acceler...
[0]: https://fidoalliance.org/certification/authenticator-certifi...
At the same time, WebAuthn is better in itself but still not the silver bullet versus passwords and a password manager. We don't live in an ideal world of course, but if we are going to turn commodity multipurpose devices into soft tokens, we might as well name it as such. (but naming it that way definitely doesn't have the same ring to it: "Your Phone is a Soft Token").
Without a security enclave (which devices are starting to include) I don't see how this is an improvement.
It's the secure enclave and the purpose-built firmware that makes a security key a security key. I'm sure some specific Android devices have a safe implementation, and I'm sure that some SIM cards and perhaps the recent iPhone Secure Elements have properties that allow them to be safely used as a security key, but putting it forward that phones can be seen and used that way in general lacks that important distinction.
Is this new / different?
So the access key the client logging in passes to the server is from the local device you trust.
Sometimes google's announcements really make it hard to understand their products when there is overlap or similarities or what.
Of course their motivation as normal may be to have users have their wifi/bluetooth on all the time so they can reliably collect more location data.
That comes at the cost of needing Bluetooth, which isn't available on all computers. I.e. it's more secure than the prompt you have now, but that will at least work everywhere.
The right tradeoff between the security and the convenience/availability is something that is very context-dependent, and different for each user. Hence the multiple options.
I am trying to develop a security process that I can rely on. It only has to be better than what I have now, it doesn't have to be bulletproof.
I store my printed backup codes for most of my services in an encrypted file in my Dropbox (encrypted with a different password than the password used for Dropbox).
I then also have printed backup codes for my primary email account and for my Dropbox account that I carry with me on an unmarked piece of paper stashed deep in a semi-hidden pocket in one of my bags. I also have printed backup codes for my email and Dropbox stashed in a semi-hidden place in my home, with the thought that in a last case scenario (or I lose my bags or something like that), I can phone my roommate and have him read me the code.
It isn't perfect and I feel like it could be improved, but so far it works fine.
What happens when your first and only Yubikey gets dropped in a puddle? You're also back to paper and backup codes.
It's not magic, there isn't any other way.
Of course it won't work if your battery is dead. :)
The whole thing (except the UI) is isolated from the phone's OS so that even if your phone gets lost or compromised nobody else can auth as you.
For something like this, especially with your phone, putting the private keys out of reach of the CPU/memory and hardened against side channel attacks is table stakes.
We think the most pressing need right now is to protect users against phishing, which is a much larger threat than malware. Thus we think there's a lot of value in enabling this for all phone models where it's possible to run the protocols.
(I'm the TL for this at Google)
Is the only thing new here the UI + that it's open for all Android 7.0 phones now?
The thing you have now communicates that yes click over the internet. This new thing communicates through a local channel (bluetooth).
Communicating over a local channel prevents phishing.
Consider this attack: Attacker hosts googlee.com and you get tricked into going there. The login site looks exactly like the google site. You type in username/password just like normal. In that moment they take your phished credentials and pass it to the actual google server, like a man in the middle. Now you receive a prompt on your phone asking Yes/No. You click yes, okaying the attacker's login.
Now that same attack with the local channel communication - they can't take your signal and pass it on through to google
1. It doesn't seem to be using the Titan M flow on my Pixel 3 currently
2. After reinstalling GMS on my phone to try and get the Titan M working, it stayed registered as a key, but the prompt never shows up on my device.
I guess this is more of a "flag for internal review" vs a "please provide me with answers".
Re 1: The Titan-M specific flow is still rolling out, you should see your phone switch to the volume-down UI soon.
Re 2: I've flagged this and we'll look into it.
As an aside, I'm not sure that I want random JavaScript to be able to do Bluetooth stuff. At the least, I'd want the ability to limit it on a per-website basis.
This is the state of web we are in, and this is coming from Google. [1] I have literally 20% of the screen displaying useful information. The others are all useless navigation or related crap. Just seeing it nearly got me to puke.
It is one those problem in general where the web page is responsive and mobile first.
I know where the navigation bar is, if I want to use it, I'll scroll back up and touch something on it. If I want to read related articles, I'll scroll down past your piece, which is where that kind of nonsense always is.
But it gets better: you know what's almost always sticky? Those hideous share/"post this to a social networking site" badges! As shown in that screenshot, even Google can't resist that one!
Why are you covering my viewport with everything but the content you want me to read? Are you trying to make me leave? You know I only have so many pixels on my five inch mobile screen, right??
javascript:(function () {
var i,elements=document.querySelectorAll('body *');
for (i=0;i<elements.length;i++) {
if (getComputedStyle(elements[i]).position==='fixed'
|| getComputedStyle(elements[i]).position==='sticky') {
elements[i].parentNode.removeChild(elements[i]);
}
}
})();
[1] https://en.wikipedia.org/wiki/Bookmarklet
[2] on Firefox for Android, 'selecting' the bookmark to run on a page entails touching the URL bar, then selecting the bookmark item into which you placed the javascript from the bookmarks list that will appear.
In my case, I didn't opt in to running the site's javascript... so there were no floating bars. :-)
Hide Related Article at the bottom wont go unless I actually click it.
The gigantic three layer navigation bar appears when I scroll up just a little.
On Safari 12.1 macOS
The article after turning off CSS: https://snag.gy/RmXpxl.jpg
To my surprise, without JS the layout stayed the same, only the annoying elements on top and bottom when scrolling are no longer there. That's actually perfect in this case.
It's really weird to notice all the JavaScript still functioning despite just having transformed the site from Google to motherfuckingwebsite-style. The add-on I use: https://addons.mozilla.org/en-US/firefox/addon/css-toggler/
I found it amusing after you mention turning off Javascript, and then that link doesn't work without it.
The actual image is at https://i.snag.gy/RmXpxl.jpg
I don't browse with JS off, I only turn it off for sites that are a pain in the ass when it's on.
The extra wide padding on the sides is still wasteful, but it is not as bad as your experience.
However, none of the javascript on the page is executed, because I also run NoScript in default deny mode, and for the screen shot, all the JS is blocked. It looks like the javascript is partially responsible for part of the extra you are seeing.
Yes, testing with javascript allowed, it is the javascript that is adding the fixed top and bottom banners to the page.