91–100 of 113 posts
I wish channel bound tokens were mandatory in the u2f spec, or a browser key was part of the auth request to the token, for exactly this reason. U2f is "optionally" unphishable.
How would that help? Couldn't the webusb simply lie to the u2f device about what the channel is?
Earlier quoted context omitted.
How would that help? Couldn't the webusb simply lie to the u2f device about what the channel is?
Go take a look at token bound channels. It sure could but it'd be completely useless to do so.
It should be just as if you unplugged your u2f device from your machine and plugged it into the attacker's machine.
Earlier quoted context omitted.
It works, but only partially, and is still very very broken, which is why it is disabled in the first place. See also this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
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.
I am kind of surprised that the sites you mention can implement the spec correctly but Facebook and Google can't.
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…
The existence of WebUSB is awful. Why anyone ever thought it was a good idea to let JavaScript touch your USB devices is beyond me.
Originally the scale was connected via serial port to the desktop. A little Perl service we called "the scale daemon" exposed the current weight on some localhost port. The backend would constantly poll that service and the web browser would poll the backend to keep the value on the page up to date. It was a nifty solution albeit a bit clumsy and it meant running an extra piece of software on 50+ machines in a warehouse.
At some point our scale vendor stopped selling scales with serial connections or maybe it was that the PC vendor stopped including serial ports. It was 10+ years ago and I can't recall exactly. What I do remember is that the guy that wrote the scale daemon had moved on and I had to figure out how to make it work with USB. It was fun and probably not as hard as it seemed at the time, but wow, being able to get at that scale from inside the browser would have massively simplified things.
Sure, it's vulnerable to the man behind your back. But if such threat exists, you shouldn't type your password anyway.
I'm curious (assuming even) that it could be subject to this exploit?
Earlier quoted context omitted.
What kind of uniformed user uses a YubiKey? I supposed you could trick them by saying that the login process has changed and they need to enable WebUSB to let their YubiKey work
Uninformed users who have an informed friend looking out for them but not looking over their shoulder every single minute.
Earlier quoted context omitted.
Firefox barely supports U2F. It works on Github and Dropbox, but doesn't work on sites like Vanguard and Google. Every time I do a Firefox update I do a search of the bug listing and they seem to have an incomplete implementation of the spec. They're kicking the can until they fully implement the WebAuth API and jump over dealing with whatever earlier spec they were targeting. Speaking of which, why does Vanguard for…
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…
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.
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…
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.