That's not how 2FA works
Mostly agree with a lot of this, but it's a little unfortunate to lump all WebAuthn authenticators together.
WebAuthn keys--physical dongles you plug into the USB port--are indeed problematic for the reasons the author notes. (A small--but user-visible--cost; the requirement for a spare USB port of the right form factor; loss.)
However, authenticators that are built into the client device (e.g. Apple's support for a TouchID-verified WebAuthn authenticator) solve these problems, to varying degrees: the user doesn't see a marginal cost (it's built into the computer!) and doesn't have to worry about loss, USB ports, etc.
The principle challenge with using (as an example) Safari's WebAuthn support is what how the relying party should support loss of the device. (If you lose your Safari--or claim to--how does your bank authenticate you?)
Ultimately, the lost-device--or new-device bootstrapping--problem is currently what stands in the way of a truly secure ecosystem, but with platform providers increasingly supporting WebAuthn, we can at least reduce phishing risk to "phishing of the platform provider credential." Your iCloud password might get stolen, but at least that's the _only_ thing an attacker can steal to gain access to your other accounts.
For most services, delegating authentication (and anti-phishing) to someone like Apple is a big plus.
Not sure why the author is so negative on Yubikey. His only reason is that an attacker can steal his laptop with the key plugged in. That’s a user error.
I much rather have Yubikey over all other forms of security because it simply forces the attacker to be physically present. Why is that important? Because even if your laptop is stolen with your Yubikey at a local Starbucks, you’re more likely to catch that person versus a completely remote attack. Security isn’t just about attacks. You also need to think about mitigation and recovery following the attack.
All the complaints made about yubikey and webauthn could be made about 2fa 5-10 years ago. Hardware tokens gated by software (ala yubikey + webauthn) are clearly the next step in auth.
It’s an accident of circumstance you even need to buy a yubikey - your iPhone, iPad, laptop, android whatever can do everything a yubikey does. There just needs to be enough demand and time for OS and hardware vendors to come around to shipping and integrating this stuff by default. Suddenly you’ll own 3 or 4 yubikey equivalents without buying any special auth devices.
25 years into the web and our login tools remain pretty barbaric. Maybe in 25 years we’ll have it sorted out. But change is coming. Call it 2fa, webauthn, whatever - regardless of the details username/password auth (on its own) is dead.
They author makes a few good points, but I find the author's critique of Yubikey weak:
>Cost. The average YubiKey is £50...
If that's too expensive for ensuring your internet security, then either you underestimate the risks, or undervalue your information. If a Yubikey cost 10 times more it would still be a bargain.
>Usability. Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time.
Pressing the button at the right tight was a joke, right? Although, I admit it may be challenging for people with disabilities. Websites making it hard to find 2FA settings is not a Yubikey's problem, it's a website problem. Setting up a Yubikey is rather straight forward too. The main issue is the inability to clone a Yubikey programmatically, but that's the price of security.
>Convenience. My YubiKey is on my keyring. My keys are in my coat...
That's can't be serious too. I won't even elaborate on this.
>Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
That's actually the only valid point I somewhat agree with. Again, this is largely mitigated by developing the right habits. You don't leave your car keys hanging in your car's lock after leaving the car in a parking lot, right? Then why do it with Yubikey? If developing a new minor habit represents a problem, then either you underestimate the risks, or undervalue your information.
An additional password/fingerprint protection would be nice though. I agree on that.
>Support. WebAuthn is a great standard – but only a few sites support it...
Again, this is not a Yubikey's problem. It's a website problem.
The Yubikey/WebAuthn comments are really ignorant and discouraging people from the best defense against this sort of attack that exists.
First of all you can get WebAuthn devices for as little as $10 now.
Second, there is no app to configure. You plug it in when it says register and tap it. Done.
Third, if the WebAuthn device gets stolen the attacker presumably lacks a password. You can't use the device by itself. Also the vast majority of attacks are remote, not IRL.
Fourth: fingerprint or pin authenticated WebAuthn devices exist if your threat model worries about physical access.
IRL attacks are a radically different threat profile.
I can't even with this article.
> Buy a device, register it, install the app,
What u2f app is this referring to? I've never needed anything more than chrome to use u2f on windows or ubuntu. Also seems weird to complain about setting up an app, when a few sentences before that they recommend installing a password manager...
No.
2FA is designed to authenticate that this is you logging in. Wrong off the bat.
The "they just use your login token" is akin to "they just hacked the CIA's database". Just.
I also don't see how the author thinks that the same users who struggle with yubikey won't simply search for the github.com login on githud.com in their password manager. Bitwarden and co are great but the default domain creates a problem where login.signup.domain.com does not match login.domain.com and so users are used to searching.
The bit that completely lost me was the lamenting of convenience with the YubiKey.
Security and convenience are polar opposites.
Coupled with the "tech bros" comment, I am not sure this is in good faith at all
2FA prevents harvesting of passwords - but it just means that they have to be actively (or programmatically) attacking
I suppose if they AlSO have protections against proxying (forbid more than X login/login attempts from a given IP) it might help - but certainly not against spearphishing. Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
Certificate based authentication in theory allows both sides to Authenticate the Other.
This is a weird post. Yubikeys are absolutley the solution here, also a password manager. A decent password manager will check the URL for you.
Another aspect that people always forget is that 2FA protects only the login process.
Any successful attack against your browser (or any other application on your workstation) allows the attacker use existing and future browsing sessions.
The attacker can simply wait until you log onto your bank account and remotely control your browser.
Something people here are missing is that unless the phishing site uses your credentials right then and there within the existing session, they can't do much even if they do capture your 2nd factor.
But if the site just captures your credentials and puts them in a database of site/username/passwords, they are useless later, even if they also store your 2nd factor of the moment. The next time someone tries to authenticate with your stolen username and password, and the MFA challenge comes up, they will be stuck. The factor they captured phishing has long expired, and the site has no ability to provide the correct value for your 2nd factor at a later time.
So in other words, 2FA does provide additional protection in this scenario, unless the malicious party has programmed the system to also hijack your session.
I honestly can't say for sure how often the phishing sites use session hijacking vs. just collecting for later use. If the first scenario is most common then no, 2FA doesn't help much. If the second scenario is typical, then 2FA provides significant additional protection over just username/password.
So almost nothing can be done because
> The top result on Google is invariably an advert for a scam site.
No, use an adblocker. It's the modern antivirus and you should use one.
Nice blog post with interesting views.
I leave my YubiKey plugged in all the time. It's basically a permanent part of the computer.
Time to implement Password Authenticated Key Exchange, e.g. Secure Remote Password, in the browser?
Here is what I suggest. Let there be a field <input type=pake challenge=blah />. Whatever is typed into that field is unavailable to the front-end code. Instead, the browser computes a one-way function of the password, challenge and origin, and makes that available to the front-end.
The devil is in the details, but I'm pretty sure that a robust security analysis could eventually produce a solution that allows any user to type any password in a "super-password" field, and rest assured that the phishers are out.
The next issues would be: - How to prevent "downgrade" attacks, i.e., the user should immediately notice if a legacy password field is used. - How to convince the Internet to adopt this.
+1 for bitwarden as password manager. It did indeed save me a few weeks ago from a phishing attempt. After reporting it to my employer and warning all my colleagues it turned out to be the tech department doing a white hat test to educate the employees :)
"Security Key by Yubico" is significantly cheaper than YubiKey, and supports open-source protocols ("U2F and FIDO2/WebAuthn") but not corporate 2FA protocols. It doesn't address the keychain/password issues though.
> Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
The key is only the second factor. You need to lose the key *and* have your password stolen in order to have your accounts compromised. At that point, think about what you're doing wrong as a user.
Correct me if I'm wrong but I've seen oauth implementations that require you to be redirected to the site you're giving credentials for to finish the flow of authentication. Wouldn't this make it a lot easier to determine that you're being phished, if you have to go to a whole different web site that warns you that you are giving external parties access to your credentials?
> The average YubiKey is £50. There are a few around the £30 price point. That’s a huge expense given the small number of sites that support them.
A wide variety of sites support them. I'd estimate around 1/3rd of the services I use daily (both personally and for work) support them. (That said, I got mine for $30 by signing up for a magazine subscription, and wouldn't have paid significantly more. And, of course, some of my services have been chosen because they differentiated themelves from the competition by Yubikey support.)
> Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time.
Except, with U2F, that's not true. It's just "buy a device, plug it in, find the place on the website, wait for a prompt, press a button".
> Convenience. My YubiKey is on my keyring. My keys are in my coat.
That's a pretty personal problem. For me, my keys are either on my belt loop or on my desk, which means it's always handy. Of course, you can also get one of the models which is designed to stay plugged in, if that is compliant with your threat model.
> Risk. YubiKeys have no password lock of their own. ... if you’ve stolen my laptop and the YubiKey is plugged in
True, which is why they're not generally suitable for standalone use; only as a second credential. Also, if your threat model has you worried about them being stolen together, simply don't leave them plugged in together.
> Support. WebAuthn is a great standard – but only a few sites support it.
That's still as false it was when it was your first point.
> If fake-github.com said “Hmmm we’re having problems with our WebAuthn backend – please use a one-time code from your authenticator app for added security” would you be fooled?
At the very least, it would probably cause me to double-check that I was on a legit site.
Overall: I don't think you give enough credence to the fact that it's real, secure, convenient 2FA. No more digging your phone out of your pocket, unlocking it, navigating to the app, and then setting your phone down so you can type in the code. And then locking your phone and putting it back away.
Personally, my Yubikey goes into my laptop at the start of the work day (the first time I use it), and it doesn't come out until I'm done working (well, or if I need to use my keys). All I have to do is tap the button after I put my password in.
I think password managers are the first step you should take and FIDO/U2F hardware keys are the second similar important step.
With that even if your password manager get hacked you still have a secure account as they didn't got the U2F at the same time a password manager is a must have as it's prevents a lot of phishing attacks from even getting any chance and is quite convenient, too.
The problem with hardware keys is that for many people they are not so easy:
- You MUST generate and safely store recovery keys, storing them in your password manager is suboptimal, but better then not having them. (Not having them means potentially losing account access permanently.)
- You often need to enable it.
- You should store it with your keys, which dependent on habit might not be around your PC (in my case they always are in my pocket so :=) ).
- If your site doesn't support U2F/FIDO you might need an additional phone + app, or laptop app to get the numbers out of your key.
So while I think it's a must have for every developer to have a hardware security token lie a Yubikey it's not something I could convince e.g. my Dad or Sisters to use.
Let's say I've got 2FA enabled. I get a confirmation link to my e-mail. I click the link. Because the e-mail is sent by the real site, the link leads to the non-phishing site. The scammer has my password, but is still unable to access the site. How does that not help?
Of course if it's a 6-digit code or something, then they are able to stole my it like they did with the password.
Although I agree that 2FA like Google Auth/Authy/etc. doesn't authentify the site, I'd like to comment on this:
> Then the fake site uses your real token and logs in as you. > > Game Over.
Depending on how the site's security work, it's not totally game over. I've seen sites, optionally (you still have to turn the feature on), requiring a 72 hours delay before any setup change is taken into account (like, say, a password change). During this time a warning is sent by email and you can at any time during these 72 hours, unilaterally, prevent the change from happening.
So it may be "game over" in that the attacker can login and see all you account/activity/data (which, yes, is really bad) but it's not totally "game over" as in it doesn't mean "logged out of your account" (unless the attacker also compromised your email ofc, but now we're talking about something else).
You don't need a $50 Yubikey token to do U2F, there are ones in the $10-15 range.
Most sites that support U2F support enrolling multiple tokens, so just have one in each machine.
Theft of a machine still needs your password to access the accounts, so it's not "keys to the kingdom" as the article suggests.
I feel that this article is... wrong.
There is another issue, I think, with Cloudflare serving in the middle.
For many websites the Cert is owned by Cloudflare and shows Cloudflare as the Organization and not the website owner. In that case there is no way for me to figure out whether I'm on the actual site or a phished site.
For example see this (it is the Visa opt-out website that was posted a few days ago on HN): https://marketingreportoptout.visa.com/OPTOUT/request.do
Supposedly the above it authentic, but the Cert is showing Cloudflare as the Organization. Now unless the claim is that Cloudflare will never serve phished websites, which I doubt unless Cloudflare is doing a human validation for each client, this is a problem.
2FA can actually prevent phishing, though it requires close integration with the app and the authenticator. It's actually quite similar to CSRF prevention. On the site itself, display a random nonce to the user for confirmation then send an request for authentication to the authenticator with said nonce which the user can confirm. The battle.net authenticator does this.
For added protection, you can prompt the user to select which nonce is correct to force them to verify it is correct. The Microsoft authenticator does this sometimes.
The downside of this approach is that it requires a constant connection between the second factor the service. It also relies on the fact that the service authenticates itself via TLS or some other means, though that is a relatively minor issue.
FIDO is a subset of 2FA, and it's one of the protocols that yubikeys etc. implement. While it won't protect you from all attacks, it does make the standard MITM harder.
To take the OP's example, if by mistake you are tricked into visting githud.com or something, they can get your password (bad!) but if they try and MITM the FIDO, they'll send a digitally signed message for githud.com on to github.com. This will not work as intended (except for the user, because their github account isn't compromised yet.)
Indeed the point of FIDO as I see it is that it's less security critical for the end user to validate the identity of the site, which optimistically speaking about 95% of users will fail at anyway.
I recently experimented with the Yubikey OTP feature. Like TOTP, it can be proxied through as there's no challenge that includes signing the website name like FIDO. Also.. The Yubico OTP feature types using QWERTY with letters and no numbers. As I use dvorak, this resulted in considerable confusion as two yubikeys behaved the same.
Interestingly, copying the credentials between Yubikeys will not result in an accepted yubikey OTP. The serial seems to be used somewhere in the calculation.
A yubikey, using the CLI tool, can have TOTP credentials stored inside. This can be used in conjunction with grep and sed for any CLI scripts that may interactively request a TOTP.
Is there potential for a simple popup in, say, 1Passwordx Chrome extension that, if the base url doesn't exist in any key chains, that reminds us to watch for phishing sites?
I have a question: if a website is clearly involved in phishing how does one report such a website and what is the process of blocking the domain name and chasing the owner?
I think the negative aspects stated by the "hardware authentication device" is overkill. It's really easy to use and cost is relative (gets cheaper with use). May be real issue is that we're not using these new solutions and are still relying on unnecessarily complex passwords to save with master passwords. In some cases, 2FA can be a pain in the butt to manage when you have hundreds of them. A couple hardware keys and voila.
fido2/webauthn, adds MFA and a anti phishing protection!
https://www.amazon.in/Auto-ePass-2003-FIPS-Token/dp/B00S7LUL...
does anyone know if its posible to reuse these fips pki tokens? they are cheap enough.....
> WebAuthn and hardware tokens are probably the future. And they’re probably the best way we have to verify site legitimacy. But they’re also currently a poorly supported usability disaster.
I was looking for the punchline but it seems like there isn't one. Complaining about hardware tokens and then saying they are the future doesn't contribute much...
The author of this article has no idea how 2FA works or why it's used.
2FA is used to prevent or mitigate the impact of phishing or other attacks where a password is compromised (password reuse, random guessing, keylogger, etc.). The author does bring up one hypothetical attack -- a man-in-the-middle attack -- where someone can trick a user into providing their 2FA or triggering an authorization (like with a Duo push). This requires the ability to execute a real-time attack.
FIDO/U2F/Webauthn (I still haven't figured out exactly what you're supposed to call them) security tokens solve that use case by allowing the website to authenticate directly to the token. That can't be phished -- even if you're tricked into a fake website and given a fake webauthn prompt, AFAIK there's no known way to proxy or otherwise intercept that second factor authentication to allow a phishing attack to succeed.
His complaint that the token doesn't have a password is largely pointless -- the token is the second factor, the password on the site is the first. If you're using passwordless FIDO2 logins, then it does have a PIN.
Long story short, this guy is full of crap.
Slightly OT: Odd timing but one of my services sent me a push notification earlier about setting up a "personalised code" which would be included in all emails. I thought this to be a novel way that could _help_ with the email phishing problem, if adopted and implemented properly.
for one, html email is vicious, terminal email clients can help to not fool you with visual alignment.
I like the feature `From: <> via <>` in the view, maybe this tipped her off - "palette.cloud" is an unlikely envelope-sender for github mail. Reactivating an old gmail account, I can't see how to enable the feature.
In a muttrc, you can get context with showing you more headers.
ignore *
unignore from: to: cc: date: subject: user-agent: x-mailer: return-path: authentication-results:
hdr_order date: from: return-path: to: subject: user-agent: x-mailer: authentication-results:
Fake 2FA works if it's stateless, eg entering a code from Authy or a physical token.
However, stateful 2FA like sending an SMS to your phone, or popping up a notification on your banking app is much harder to spoof, and would have protected the user here.
Is GPG Auth the answer?
It is tied to the site keys and not the address nor even the CAs.
It forces you to check and think before doing your thing.
And It is easier to use than 2FA, since it is one factor, open your key one time, the key auths you as long as you want.
This is why password managers are so important.
A password manager won't offer to auto-complete if the protocol/domain does not match with what you've saved. This is an immediate red-flag that something fishy is up.
The author recommends BitWarden, but it seems like it's run by one guy. How do I know he doesn't go away? Get hit by a bus?
>>> The top result on Google is invariably an advert for a scam site.
Wait what now?
The criticism of YubiKey seems kind of unfair. For one thing, it doesn't actually explicitly state that they totally address the major issues in the article.
Instead it's "in theory" and "can help". No, it totally addresses the issue of phishing your 2FA token and it does so in practice.
The pricepoint mentioned is over twice what the cheapest Yubikey is - $24.99 [0]. The author states the "average" cost is £50 and "there are a few around £30". Again, 24.99USD for USB + NFC yubikeys that support U2F/webauthn.
'usability' and 'convenience' are the same thing but split into two points, which give the impression that there's a whole other issue, but it's really the same thing.
> Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time
So for TOTP it's install the app, configure it, find the setting on the website, enable it. So Yubikey adds the one additional step of "buy it", all of the others are the same for all other forms of 2FA. "Press the button at the right time" come on... as opposed to "find the TOTP and type it in on time" ?
The 24.99 USB Yubikey also supports NFC, so like, "has USB or NFC" is the requirement - I'm seriously struggling to think of a device that doesn't meet this requirement.
The author states that leaving the yubikey in the laptop increases risk. I find this to be a mixing of threat models personally - we've solved credential phishing with the 2FA token, but now you're talking about a threat where the attacker has unfettered physical access? I just don't see why that's relevant, sorry.
And for support, I think it's important to note that most sites are not sensitive. But a couple of important sites are. The most important is probably email, since email is effectively an auth mechanism for most other sites via account recovery. So just by protecting email you're protecting every other site. That's really important.
IMO,
Yes, Yubikeys should get cheaper. I certainly hope they do. At my company I give every employee 2 Yubikeys and they are theirs to keep - they're free to use them for personal accounts. I hope more companies do this in the future, essentially distributed U2F to the workforce.
But, otherwise, I really think that the benefits are being drastically undersold and I think that the criticisms are really not particularly fair.
[0] https://www.yubico.com/product/security-key-nfc-by-yubico/
> A second factor allows a site to better authenticate you. It does not help you identify the site.
That's correct. On the first visit (or enrolment).
All subsequent visits (many more!) do identify the site, or rather they tell you that you're logging in to the same site as all those times before.
What about certificates? The fake GitHub almost certainly does not have a valid certificate. Isn’t that our one defense against these things?
This is a good article about the weaknesses of the trust models of navigation on the web. The author uses a password manager that also fulfills the role of a personal 'have I seen this site before?' database, which helps them associate a URL to its conceptual entity, in their quest to determine if the site they visited was the site they intended to visit.
In this exact form, this is a feature that's absent from mainstream browsers today. Because browsers do not have this, people instead turn to all sorts of other signals to judge the site's identity, but each one of those signals is designed for another purpose, and ought to not to be used directly by the user to make such determination. But no other signals are available, so they get used nonetheless.
Some people look at the URL before clicking it, or the URL bar in the browser after they've already navigated to the site, and try to judge from the URL whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including: (1) people often read visually instead of comparing codepoint-by-codepoint, so reading errors or homoglyph attacks are possible, and browsers can only meaningfully mitigate against the latter; (2) very few people keep a computerized allow-list, so they check against expectations in their head; and (3) some organizations will make use of domain names that greatly differ from their own name, which works contrary to the instinct of a URL-judging user who consider themselves 'cautious', and it's difficult to stay aware of all this.
Some people look at the TLS certificate, and try to judge from the information displayed by the browser about the cert whether the site belongs to the entity they intended to visit. This is fallible for a bunch of reasons, including (1) DV certs only prove that someone (i.e. anyone) had control of the domain at the time near the cert's issuance, so its value as a trust signal to the user ought to be zero and immediately reduce to the prior case of mentally validating the URL by its character content; (2) EV certs validate against a legal entity in some jurisdiction, but as the 'stripe.ian.sh' stunt has demonstrated, jurisdiction-by-juristiction registries of legal entities are a tool for a different use-case and were never intended to collectively ensure globally unique Organization names; and (3) in their rush to ensure widespread TLS deployment on all sites, and their involvement with efforts to bring short-lived cost-free DV certs to everyone, browser-makers began de-emphasizing the UI distinctions between DV certs and EV certs some time before the true shortcomings of EV as a user-facing trust signal were widely demonstrated.
Some people look for the visual design of the website. This is trivial to fake.
Some people will rely on browser-resident bookmarks, browser history, or 'top sites' tiles to navigate to common sites they've visited before (or to sites the browser-maker pre-loaded into the listing). This is a great way to preserve the trust chain and reduce the likelihood that the user arrives at an unintended site by mistake. But these features do not directly address the case of a person navigating to a URL they were linked or provided from an arbitrary source, such as the example raised in the article.
Building blocks exist today that could be used by publishers and browser-makers to aid users in judging URLs. Some of these will require past UX decisions to be undone.
For example, top sites could become their own Root Certificate Authorities [1] and be listed in browser trust stores; these companies would be expected to issue certs for sites associated to themselves. This would eventually reshape the cert landscape so that a parent-child relationship between issuer and subject could be meaningfully distinguished from a 'provider and customer' relationship. Companies that provide services to others, such as payment processors, could also become root CAs and sign for their customers. These changes, and a browser UX that once again shows the cert issuer, would go a long way towards reducing the likelihood that users are fooled by sites trying to impersonate top sites.
If this were to come to pass, other CAs would be expected to pivot to minting certs that play the role of a trustmark, by conferring a degree of ongoing assurance that's useful to the user (which, in fairness, was the original point behind EV certs). They would do this by establishing strong brands around their trustmark, issue certs for a short lifetime, and monitor the site on an ongoing basis to see if it's still deserving of their trustmark. This would result in a business model similar to those of EV certs, but a trust model that's based on the user's trust in the CA's exercise of good judgment befitting their brand.
I was able to recover over $17,000 I lost to fraud. All thanks to this pro hacker Arthur Vitali who helped me track funds and eventually wired all the money back to my account within 3days. I am more than grateful. If you need help please contact Arthur on EMAIL- Quickarturhack @ Gmail,com WHATSAPP +17025301177
He also does phone hacking, credit fix/score boost, all social media accounts hack, website hack and a lot others
> The top result on Google is invariably an advert for a scam site.
Um... no?
The linked article is correct, but uncharitable. It correctly states the behavior of two-factor auth systems but incorrectly understands their value.
Yes, 2FA won't protect you from being phished by a site if you aren't careful. 2FA absolutely will protect you from a phishing site using the password it stole.
So no, when someone says "Use 2FA if you might be phished" you shouldn't be replying "That's not how 2FA works", you should reply "That's right! But let me explain why you are still at risk of password theft and should still be careful."