Your Android Phone Is a Security Key

https://blog.google/technology/safety-security/your-android-phone-is-a-security-key/

by arusahni • 7 years ago

198 139 7 years ago

blog.google

Hamuko2• 7 years ago

I don't know how I feel about making a device so endlessly hackable a "security key".

lostmsu• 7 years ago

Aren't you already using Authenticator running on an Android device?

dsfyu404ed• 7 years ago

That doesn't mean I think it's a good idea.

A phone is better than nothing. A real token would be much better.

oarsinsync• 7 years ago

Google Authenticator is just Google's front end to an open standard (TOTP). Authy, 1Password, various CLI apps, they all implement this same standard.

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.

Animats• 7 years ago

Um, yes. Plus it uses "Google Cloud".

A security key device ought not to be remotely writeable.

guelo3• 7 years ago

All Android devices certified by Google will have a hardware security module which should keep the keys secure. Some cheap non-certified devices (mostly Chinese) might not have hardware backed keystores, but I doubt those devices would be able to run this Google app.

JohnFen• 7 years ago

If a Google app is required for this, we've already entered the "can't be trusted" category.

penagwin2• 7 years ago

Not doubting you, but were did you find that information? The only thing I see is "it’s built into devices running Android 7.0+" and I found that on multiple pages.

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...

https://support.google.com/accounts/answer/6103523

zimmerfrei• 7 years ago

> All Android devices certified by Google will have a hardware security module which should keep the keys secure.

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).

duxup2• 7 years ago

My phone already prompts me when I login to a google account on another device.

Is this new / different?

sofaofthedamned• 7 years ago

I thought that. AFAICT it's local via Bluetooth, as opposed to through Google servers and push messaging. Good idea, but better if it's open.

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.

cosinetau• 7 years ago

I think the difference is that the prompt you describe still travels over the wire to get to your device, while this new thing used Bluetooth based on FIDO standards.

So the access key the client logging in passes to the server is from the local device you trust.

duxup2• 7 years ago

Ah thank you!

Sometimes google's announcements really make it hard to understand their products when there is overlap or similarities or what.

arnarbi7• 7 years ago

As others pointed out, the difference is that the local connection to the phone, together with the Webauthn+FIDO protocols make this resistant to phishing.

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.

godelski5• 7 years ago

This is great. Hopefully it'll get more people using 2FA. I don't think this is the best security practice, as others are nothing how insecure Android is. But it's better than nothing. It also pushes more people to use FIDO and 2FA. This is for the average person. If you want more get an yubi key or something.

godelski5• 7 years ago

Edit after trying: It is a little disappointing that it is Chrome only.

arnarbi7• 7 years ago

Implementing and maintaining the code in the browser that manages the local BLE channel to a FIDO authenticator is unfortunately a significant undertaking.

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.

mattjack2• 7 years ago

They don't make this very obvious but this only works in Chrome. So you'll have to use SMS codes, the Authenticator app, or backup codes everywhere else. (edit: they explicitly say so when activating it but not as clearly in the docs)

michaelmior• 7 years ago

all you need is an Android 7.0+ phone and a Bluetooth-enabled Chrome OS, macOS X or Windows 10 computer with a Chrome browser

eitland2• 7 years ago

Heh, Microsoft seems better than Google to support Linux in new products now. VS Vode is amazing, as is dotnet core.

Who would have thought 5 years ago.

codemac• 7 years ago

Is there any way to get this working in Firefox? :(

mjg59• 7 years ago

As far as I know, Firefox doesn't support BTLE U2F devices yet (I work at Google, but not on this project)

correct_horse• 7 years ago

It probably depends on Web Bluetooth, which Firefox doesn't yet support, see https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...

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.

sakisv• 7 years ago

I like the idea behind it in principle, since it will simplify 2FA for the masses and may lead more people to adopt it.

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.

peterwwillis• 7 years ago

The problem isn't even Google, it's just lack of actual support for services that need it. You have to have the right client, the right device, and every website has to implement it.

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.

icebraining2• 7 years ago

Well, that depends where you live. Google is available for everyone, not just technologically-backward places.

Here millions are currently checking their pre-filled tax returns, which they have accessed using smartcard authentication, so Gmail ain't that far ahead.

Bluestrike2• 7 years ago

Admittedly, that's not a minor benefit. If someone has access to your Gmail account, there's all sorts of information there they can use to engineer access to other services.

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.

Rafert5• 7 years ago

Browser support is pretty good: https://caniuse.com/#feat=webauthn - and Google submitted the caBLE transport to the WebAuthn working group. Give it some time.

And don't count out governments just yet, U2F got some love: https://www.yubico.com/why-yubico/for-business/authenticatio...

creato• 7 years ago

I'm not sure this is the right perspective. Is it really such a big deal if SSNs get leaked?

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.

zavi2• 7 years ago

This is 2FA for Google accounts so of course it's on Google products?

jdietrich• 7 years ago

Google Authenticator works with any service that uses the TOTP or HOTP standards.

https://en.wikipedia.org/wiki/Google_Authenticator

Rafert5• 7 years ago

Before the announcement I've seen references to a 'caBLE'/ 'cloud assisted Bluetooth Low Energy' transport on the Web Authentication mailing list and W3C spec GitHub issues, this is exactly that. The VentureBeat article[0] confirms:

“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...

Ajedi32• 7 years ago

In principle I don't see any reason why this couldn't be made to work with any browser/site through the WebAuthn standard. In fact, it wouldn't surprise me if that's exactly what Google's doing under the hood.

daphneokeefe2• 7 years ago

Can someone explain how TFA (or any security feature that relies on my phone) works when the phone is unresponsive -- dead battery, no cell or internet reception, hardware failure.

mattjack2• 7 years ago

It won't--so you'd have to use the backup methods they made you set up, like SMS codes, Authenticator, printable backup codes, etc.

krzyk• 7 years ago

SMS and authenticator won't work on a dead phone either, so you are left with keeping a paper with backup codes.

wetpaws• 7 years ago

U2F fits into this scheme nicely

Rafert5• 7 years ago

WebAuthn is the successor to U2F. This is just another transport (caBLE/"cloud assisted Bluetooth") for this standard in addition to NFC, USB and a direct connection to a Bluetooth authenticator (e.g. Feitian and Google Titan key).

daphneokeefe2• 7 years ago

I am interested in how frequent travelers manage these security measures (especially abroad). For SMS: quickly obtain a burner phone, log in to Chrome, something something SMS or Authenticator? For Authenticator: log in to Chrome on any machine you can locate that you can trust? For the printed backup codes, you carry them with you as you travel, and through security?

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.

txcwpalpha• 7 years ago

When possible, I completely avoid services that use SMS 2FA. If given the option, I always opt for authenticator apps or codes-via-email 2FA, in that order. I use SMS 2FA so infrequently that I've never encountered a situation where I needed to get a code SMSed to me while abroad.

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.

macspoofing2• 7 years ago

Yes. You need an alternate backup mechanism, like pre-generated one-time codes, or (shudder) SMS.

arnarbi7• 7 years ago

The feature described in the article will work when your phone is offline. We'll publish instructions soon on how, but it will e.g. involve manually waking the screen to trigger the local communication.

Of course it won't work if your battery is dead. :)

doughj34• 7 years ago

Now, you have one more option—and it’s already in your pocket. Starting today in beta, your phone can be your security key—it’s built into devices running Android 7.0+.

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.

[0] https://pbs.twimg.com/media/D3WJ0UdXkAASs_O.png

icebraining2• 7 years ago

Google has always given me other options, does it really enforce having a phone now?

doughj34• 7 years ago

I don't know how they determine what options to offer, but using my phone was the only one given, despite entering a correct password. The only other option, which I either found from the "Learn more" link or after exhausting the "login with your phone" attempts, was to create a support ticket for my G-suite account which, in this case, would have been slower than returning to home a few hours later where I had left my phone.

kkarakk• 7 years ago

I think it makes sense to me, security that only works part of the time can be bypassed when it doesn't work.

However i've never encountered a TFA service that let you disable it in certain scenarios so i may be wrong

helloindia• 7 years ago

This happened with some of my friends, and locked them out of their gmail accounts(2FA disabled accounts). Google won't let them login to their accounts after providing correct password & SMS OTP.

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.

munchbunny2• 7 years ago

Is this based on a hardware security module in the phone? I don't see this written anywhere in the blog post.

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.

arnarbi7• 7 years ago

For phones that have a dedicated hardware module, such as the Pixel 3, yes the key material is generated and stored there. Using it requires a physical action that is hardwired to the hardware module.

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)

rheerani• 7 years ago

So, can the button used be changed or does it have to be standardized across devices and which is why it's the volume down button? Because the squeeze function on Pixels or assistant buttons on other devices could be used instead, though that's just me wondering out loud for an alternative user-facing implementation because the use of volume button seems strange to me.

ksec2• 7 years ago

Off topic:

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.

[1] https://ibb.co/fCfmW6h

NikolaNovak• 7 years ago

I fully 101% agree with you in principle, but in this particular case my experience is wildly different. As soon as I scrolled, the navigation got out of the way, and all I have is text - with author's decision to keep large wide white margins. (Vanilla Chrome on Windows - no extensions/plugins/blockers, no reader mode, etc)

https://imgur.com/5DOqvj1

ksec2• 7 years ago

Well in my case.

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

phyzome• 7 years ago

What happens when you scroll up a tiny amount? Do the floating dickbars come back?

In my case, I didn't opt in to running the site's javascript... so there were no floating bars. :-)

modwilliam• 7 years ago

Looks like you're zoomed in or have a larger default font size, so it's not fair to say this is the state of the web

theDoug• 7 years ago

But looking at a web page nearly made his body vomit!

rrix2• 7 years ago

so the state of the web is fine as long as you don't have accessibility needs? neato.

pwg2• 7 years ago

I see this: https://ibb.co/ZJQ7Z2h

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.

aerotwelve• 7 years ago

Sticky elements that follow you around while scrolling a web page should be banned like the blink tag. Especially in a mobile browser.

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??

pwg2• 7 years ago

Put this javascript into the URL field of a bookmark (thereby making it a "bookmarklet" [1]) and then select the bookmark [2] on any page that has those sticky elements. Once run, the sticky elements will be gone. Note multi-lines below, but it will all be one line in the URL field.:

    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]);
        }
      }
    })();

uBlock Origin's custom filters can also be used to delete those sticky elements as well.

[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.

lucb1e2• 7 years ago

Turning off JavaScript sometimes helps, but often just breaks the site. However, I also have a button to turn off CSS, which just flips a setting (dead simple addon, no security risk, can't break anything, and doesn't need a page refresh). I use it about once a week for articles with too low contrast, annoying fonts (this is getting better over the past year or so), or crappy sites like this.

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/

556B19BB• 7 years ago

The article after turning off CSS: https://snag.gy/RmXpxl.jpg

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

oneplane4• 7 years ago

Your Android Phone Is a Security Key

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.

penagwin2• 7 years ago

Yeah I don't see how this is any different from the standard Google Authenticator style affair.

Without a security enclave (which devices are starting to include) I don't see how this is an improvement.

oneplane4• 7 years ago

I think that using a soft token or push notifications are better than nothing, but a company putting a (often known vulnerable) phone at the same level as a security key seems like setting a bad precedent. Then again, at least it's not SMS-verification. Perhaps in future leaks and scrapes of end-user deviced we don't just get data dumps and passwords, but also internal key seeds and tokens...

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.

verdverm• 7 years ago

Connects via Bluetooth to the device you wish to sign into.

lern_too_spel3• 7 years ago

Android 7 added support for key attestation, making it possible to verify that a key came from a secure enclave. That's presumably why the blog post says Android 7 and above. https://source.android.com/security/keystore

christiaanbrand2• 7 years ago

It’s resistant against phishing. That’s solving the problem. OTPs are not.

Rafert5• 7 years ago

That's a bit snarky. As other commenters mentioned, it can leverage TEEs using the Android Keystore for secure storage. And the way WebAuthn works means users are protected in case of a database breach (it contains only public keys) and the protocol protects against phishing. Both are ways better than usernames and passwords.

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...

oneplane4• 7 years ago

I was intended to be a bit snarky indeed. I know TEE's and remote attestation are supposed to help out here, but I also know that even a purpose-designed chip couldn't get it right the first few times (think MIFARE NFC, TPMs and YubiKeys with Infineon cores). It's a very hard problem, and making light of it by having marketing (big assumption) play it as if a phone is now a security key seems a bit of a leap here.

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").

vbezhenar• 7 years ago

I don't see how it's less secure than storing passwords in ~/Documents/Passwords.txt. And it's a second factor, so combined with first factor the result is pretty secure. You can't browse other people phones, even without security enclave.

oneplane4• 7 years ago

Websites running javascript weren't supposed to browse other people's computers either, but we all know how that assumption went. Yes, it has gotten better the past few years, but the whole point of a security key is that it takes a purpose-designed piece of hardware and software, with a minimal attack surface. A phone is far from it.

rrdharan• 7 years ago

We could test this claim pretty easily:

- you post your credentials on Twitter

- I'll store mine using this Android Phone

Let's see who gets hacked first!

foobiekr• 7 years ago

Most security keys don’t have app stores full of malware.

jayd16• 7 years ago

Now they do.

markstos• 7 years ago

Looks like Google has used the open Web Bluetooth specification (that only Chrome currently supports) along with the open FIDO Bluetooth spec ( https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid... ).

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.

scarejunba2• 7 years ago

You can already use a Yubikey with Google. I have mine set up.

BillinghamJ• 7 years ago

I don't believe Web Bluetooth should be used with security keys (in fact, I believe communication with those is specifically blocked as a part of Web Bluetooth).

This is because the browser needs to pass the origin to the device and ensure the webpage can't impersonate another origin.

Rafert5• 7 years ago

FWIW that is a really old spec. The FIDO 2.0 Bluetooth transport is described at: https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-cl...

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...

arnarbi7• 7 years ago

This does not use Web Bluetooth, but rather an implementation directly in the browser through WebAuthn. A critical part of the phishing resistance of WebAuthn is that websites do not get to talk directly to the authenticator.

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!

drexlspivey• 7 years ago

Or you can just use https://krypt.co/ which uses the same FIDO standard, is open source, works on both android and iOS (where it actually uses the secure enclave) and both in Chrome and Firefox

amanzi• 7 years ago

I've been using this for the last month or so and have no complaints. Works well.

trulyrandom• 7 years ago

An important caveat with Krypton is that while it is open source, the published source is essentially useless because it is not licensed under a free license.

int_19h3• 7 years ago

That should be sufficient to audit the code, and verify that the binaries distributed via app stores are actually compiled from it, no? For a security app, it's pretty useful.

r3bl• 7 years ago

You can see the code, but can't do anything with it? That'd be source-available, not open source.

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.

wavefunction• 7 years ago

This is great other than the fact Google is involved. Now I will admit it's unlikely (effectively impossible) that this would come to Android without Google being involved but I am not interested in adding Google to more of my life. I'm looking to cut them out more and more wherever I can.

tjbiddle• 7 years ago

My Pixel 2 already does this. When I sign into Google I get a notification that asks if I'm signing in, I click yes, done-zo.

Is the only thing new here the UI + that it's open for all Android 7.0 phones now?

gretch• 7 years ago

disclosure: I work at google

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

plttn2• 7 years ago

As there's very little documentation on this right now: couple of related questions (feel free to ignore them I don't want to guilt you into it)

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".

scottlocklin3• 7 years ago

Your yubikey isn't owned by an evil megacorp.

Use a damn yubikey; they're practically free and don't monetize their users.

acct17713• 7 years ago

As someone who can't currently afford the two Yubikeys needed to finish securing their internal startup services...please think for just a second before you say things.

scottlocklin3• 7 years ago

I'd have sent you one if you weren't such a dick. Even though your statement is not remotely believable.

kd5bjo• 7 years ago

Here in Iceland, there's a security key embedded in your SIM card that everybody uses as their 2FA solution. It's triggered via a GSM message to your phone, identifies what the authorization is for, and lets you enter the key's PIN code to accept.

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.

acct17713• 7 years ago

This is why that's not great: https://www.schneier.com/blog/archives/2015/02/nsagchq_hacks...

Your Android Phone Is a Security Key

Related Stories