Live data from Hacker News

Strengthening 2-Step Verification with Security Key

googleonlinesecurity.blogspot.com

131–140 of 150 posts

Re: Strengthening 2-Step Verification with Security Key

#131
post #118

Earlier quoted context omitted.

Maybe the UI is nicer, but the permissions on Android are unnecessarily intrusive, which—to me—is a dealbreaker with a 2FA manager . Device & app history read sensitive log data Identity find accounts on the device Camera/Microphone take pictures and videos Wi-Fi connection information view Wi-Fi connections Other receive data from Internet access Bluetooth settings pair with Bluetooth devices full network access vie…

Well, each of those permissions they request ties to a very obvious and useful feature. Camera/Photo for QR code-based 2FA, Bluetooth permissions and Internet Data to handle local connection to trusted machines and callbacks from sites like Coinbase (when I log into coinbase, I get a handy 2fa notification from authy that leads me right to the code) Log data is the most questionable, but it really makes debugging so…

Wait, Google Authenticator lets you provision accounts by scanning a barcode, how does it not list "take pictures and videos" in its permissions manifest ?

Re: Strengthening 2-Step Verification with Security Key

#132
post #118

Earlier quoted context omitted.

Well, each of those permissions they request ties to a very obvious and useful feature. Camera/Photo for QR code-based 2FA, Bluetooth permissions and Internet Data to handle local connection to trusted machines and callbacks from sites like Coinbase (when I log into coinbase, I get a handy 2fa notification from authy that leads me right to the code) Log data is the most questionable, but it really makes debugging so…

Wait, Google Authenticator lets you provision accounts by scanning a barcode, how does it not list "take pictures and videos" in its permissions manifest ?

IIRC Google Authenticator uses a third-party barcode scanner via an intent.

Re: Strengthening 2-Step Verification with Security Key

#133
post #77

Earlier quoted context omitted.

IMHO the Authy app is nicer than Google Authenticator. https://play.google.com/store/apps/details?id=com.authy.auth... http://itunes.apple.com/us/app/authy/id494168017?mt=8

redhat also makes a prettier version ( https://play.google.com/store/apps/details?id=org.fedorahost... ). not as pretty as authy, but less sketchy w/ the pointless permissions. Also, authy cloud syncs your accounts which seems like a bad idea.

It enables http://blog.authy.com/multi-device , which is either very handy or stupid depending on how paranoid you are.

Re: Strengthening 2-Step Verification with Security Key

#134
post #19

Earlier quoted context omitted.

Wearables with BTLE.

Bluetooth has too long range. That's why it was never a good idea for Apple to adopt it for payments either, despite all the cheering for it when BLE came to the iPhone. I'd rather these only work with NFC (you know, like Apple Pay). Although I wouldn't mind the BLE option too for things like opening the garage door. But for anything else where you're at close range anyway, it should be NFC by default.

BLE is a superior radio protocol compared to NFC on almost every axis, with the only exception of battery; having a higher range is a feature, since you can estimate the range with a decent precision.

It's safe to assume that Apple was forced to add NFC for compatibility with the existent contactless POS (especially in Europe, where they've got a widespread adoption already). The same applies for the Secure Element, which is a functional duplicate of the Secure Enclave, but runs Java Card and was probably required by CC networks to reuse existing infrastructure.

Re: Strengthening 2-Step Verification with Security Key

#135

Interesting. I've hacked something together for my personal usage with my OpenGPG smartcard for use on my Windows desktop and developer-mode chromebook. In the end I had to work with "chrome native messaging" which basically calls native binaries on the host OS and is a nightmare to set up. This doesn't look like they're planning to start supporting existing smartcards, but hopefully it's a first step? My idea was to…

Is there more info on GPG smart cards? I use a SafeNet eToken and highly reccomend it but it does X.509 certificates instead of GPG.

Re: Strengthening 2-Step Verification with Security Key

#136

Some comments are pointing out how awkward this might be, > I don't see a point in plugging my entire keychain (the physical keychain, with my car keys) into my laptop every time I want to log in > I'm not sure about having to plug it in every time I'll share my experience. I use two of these on a laptop and desktop and I have never unplugged them; there's no reason to. They sit very flush in the USB slot. I suppose…

> I use two of these on a laptop and desktop and I have never unplugged them; there's no reason to. I use a Yubikey for ${WORK} and we are required to remove such tokens as soon as they have fulfilled their purpose. On pain of disciplinary action, as it is considered on par with leaving a password on a Post-it. Otherwise there's no point in them as an additional security step in the event that the laptop is lost or s…

If laptop is stolen you can revoke it, and your password shouldn't be compromised at this point. And hacking through phishing is way more likely in any case (security keys protect against it while regular 2fa doesn't).

Re: Strengthening 2-Step Verification with Security Key

#137
ISTM that a nice feature for HN would be to strip out the

  ?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Google...
crap that gets stuck in URLs occasionally when people use RSS readers. In this case it doesn't seem to include any PII but I think sometimes it does?

Re: Strengthening 2-Step Verification with Security Key

#138

Earlier quoted context omitted.

I think its pretty obvious that anything without a USB connection this probably won't work (maybe usb otg), but would 2FA still be used as a fall back ?

You can get NFC enabled keys to use with any device without USB that supports NFC

well in that case my desktop/laptops don't support NFC. So its still working on one platform and not another.

Re: Strengthening 2-Step Verification with Security Key

#139
post #136

Earlier quoted context omitted.

> I use two of these on a laptop and desktop and I have never unplugged them; there's no reason to. I use a Yubikey for ${WORK} and we are required to remove such tokens as soon as they have fulfilled their purpose. On pain of disciplinary action, as it is considered on par with leaving a password on a Post-it. Otherwise there's no point in them as an additional security step in the event that the laptop is lost or s…

If laptop is stolen you can revoke it, and your password shouldn't be compromised at this point. And hacking through phishing is way more likely in any case (security keys protect against it while regular 2fa doesn't).

Additionally, if somebody removes the token, dumps a bunch of OTPs and then puts it back, as soon as you use the token once, it will invalidate all previous ones so their dump will be reasonably useless. I leave my key in my computer when I'm at my desk but have it attached to my keychain so that I take it with me if I leave my desk.

Re: Strengthening 2-Step Verification with Security Key

#140
post #61
post #43

So, we recently had a bunch of articles coming out on "the fundamental insecurity of USB" [1]. How does that jive with a USB-based security key? Can't this be "flashed" like any other USB device? [1]: https://www.schneier.com/blog/archives/2014/07/the_fundament...

The insecurity relates the problem with allowing random usb devices to be plugged into a computer. Specifically, it points out that, even if you wipe an usb stick, you still can't trust that it's safe. The devices that Google is referring to should be inherently safe. If you don't trust the supplier of these devices then yes, that's an issue. But, in theory, you receive these from a trusted source. As long as the dev…

"Read-only" is a property of flash memory in a USB thumb drive.

The nasty USB vulnerability covered recently infects the chip firmware, which can always be re-flashed (indeed, that's how the firmware got there in the first place). And it affects all USB devices, not just thumb drives.

The only way to make a USB peripheral safe from this attack is to engineer some sort of fuse that can be burned after the final firmware flash (so it can't ever be re-flashed), or cryptographically sign the firmware it can't be re-flashed without the private key.

Until Google says their security key has one or the other of these, I personally would not trust it.

Post reply on HN