Live data from Hacker News

Chrome lets hackers phish even 'Unphishable' Yubikey users

wired.com

101–110 of 113 posts

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#101
post #98

Earlier quoted context omitted.

The usual rationale from companies forcing SMS two factor is that you need to have a convenient account-recovery mechanism before you enable something strict and lock yourself out. They don't want the support cost of dealing with these lockouts. Unfortunately, these same companies often then claim that there is no harm in SMS two factor since "clearly it is stronger than one factor". But they are blind to their own s…

SMS is already 2fa. You need the sim card and the pin code. Hence a hijacked phone could be seen as stronger than a 1fa password.

Unfortunately the network security is kind of a joke so an attacker can intercept your messages if he is near you.

Not to mention that traffic inside the network is not encrypted so a lot of parties have legitimate access to the messages anyway.

I understand your point but SMS should not be used as the only factor for authentication.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#102

This is the attack: > If a victim logs into a fake Google site, the phishing site passes on their username and password to the real Google login page. Then the spoofed site passes back Google's request for the user's U2F token and collects the Yubikey's unique answer, all via WebUSB. When that answer is then presented to the real Google site, the attackers gain access to the victim's account. So basically they are so…

It sounds like the report glossed over a rather important bit of ux: If, when logging in, you see a big modal dialog asking if you want to grant webusb access to the site, then DONT select your yubikey out of the list of connected USB devices and click "Allow". As long as you can convince yourself to avoid taking that particular unusual action, it sounds like you're fine.

If the user thinks the site is Google it’s not that strange they’d give them access to the key.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#103
post #69

Earlier quoted context omitted.

Why do you want to use a Web IDE? I am not trying to cause tension, I am just genuinely curious.

For me: teaching! Getting 400 students up and running with python is painful alone - without USB. For projects, some small fraction of those used USB, and we again had a pretty good chunk of time spent getting them all working.

I would think that getting Python up and running is a valuable lesson.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#104

Earlier quoted context omitted.

They're slowly inventing operating systems, complete with hypervisor technology, with all the gargantuan complexity that it implies, to please big business that wants the client OS to essentially become obsolete.

The web browsers are so much more secure than what we had before (just accepting executable binaries from other people), so I look at this as a way forward.

And yet, at quick glance, Chromium THREE TIMES more CVEs than the Java JRE...so it might be more secure than before, but lets not celebrate just yet!

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#105
post #98

Earlier quoted context omitted.

The usual rationale from companies forcing SMS two factor is that you need to have a convenient account-recovery mechanism before you enable something strict and lock yourself out. They don't want the support cost of dealing with these lockouts. Unfortunately, these same companies often then claim that there is no harm in SMS two factor since "clearly it is stronger than one factor". But they are blind to their own s…

SMS is already 2fa. You need the sim card and the pin code. Hence a hijacked phone could be seen as stronger than a 1fa password.

Correct me if I am wrong, but these SMS-based login setups are only sending a message to your phone number. It's about as secure as sending an email to your email address. There is no end-to-end security between the original sender and the subscriber's phone and SIM card to ensure that the message only gets to the correct recipient.

You only need to hijack the victim's phone number so that messages are sent elsewhere. This can be done by technical or social hacks such as porting the subscriber's number to a new provider or pretending a phone was lost and having the phone company register a replacement SIM. There is no need to physically intercept the victim's phone, so it is not in fact a second factor.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#106
post #93
post #70

Earlier quoted context omitted.

Nonsense. It works fine on Github, Fastmail, Gandi... it doesn't work on Google because Google uses a different spec. That bug is about making Firefox compatible with the variation that Chrome/Google uses.

That bug mentions that Facebook is also broken. I am kind of surprised that the sites you mention can implement the spec correctly but Facebook and Google can't.

Google's CardDAV server isn't standards compliant (2014) https://news.ycombinator.com/item?id=16412730

I'm not surprised.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#107

It seems like i am often reading about reasons why Not to use Chrome.. Are there any good writeups about security of different web browsers? is Chrome a real issue?

I can't imagine that there would be such a writeup. Even just trying to understand the security framework of one browser is a gargantuan task.

As for Chrome being a real issue, some points off the top of my head: - Its extension store breeds out malware in regular intervals (feels like there's headlines about that at least every other month). - Pretty bad autofill exploit that was left unfixed for years: https://github.com/anttiviljami/browser-autofill-phishing (Might've been fixed in the past year, I haven't checked, but I doubt it.) - Chrome Sync is not end-to-end-encrypted without the use of a second password, which effectively means that it is unencrypted for 99.9% of Chrome users. Google also actively uses this data, weaving your browsing history into the profile that they keep of you. So, if they ever have a data leak, a lot of data is going to come from people using Chrome, too. The NSA/CIA/FBI also tap into this data, possibly using it for cyber war attacks, so if you live in a country other than the USA, you're making yourself a prime target and an easy target by inputting this data through Chrome.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#108
post #56

Earlier quoted context omitted.

FIDO discussed this on their site. It's optional so corporate firewalls that perform MITM can continue to work with U2F.

... sigh.

I mean, if you want a standard for everyone, it's hard to ignore where most people work.

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#109
post #76

Earlier quoted context omitted.

I have to admit that in all of my use of my Yubikey Neo in Chrome I don't recall ever being asked for permission to access the device. Firefox hasn't asked either.

I'm not saying that you need to grant any kind of permission in order to use U2F tokens, but rather that a user thinking "I want to login to Google" and "I need to use that USB key thingy to do that" is quite likely to accept a prompt that requests access to the U2F device.

Sorry, I guess what I was getting at is that in hindsight I'm surprised no browser ever explicitly asked me for access to the Yubikey or told me why it needed, I've just blindly trusted it because of the few sites I use it with.

On the other hand, it's basically functioning as another keyboard device and not a special USB device so it shouldn't be that surprising, right? (serious question)

Re: Chrome lets hackers phish even 'Unphishable' Yubikey users

#110

This is the attack: > If a victim logs into a fake Google site, the phishing site passes on their username and password to the real Google login page. Then the spoofed site passes back Google's request for the user's U2F token and collects the Yubikey's unique answer, all via WebUSB. When that answer is then presented to the real Google site, the attackers gain access to the victim's account. So basically they are so…

You can disable CCID, does that not solve the issue?
Post reply on HN