The U2F protocol (that Yubikey and others use) is based on a cryptographic challenge-response mechanisms, and it includes the domain of the service you're logging into, as supplied by the browser.
The details are complicated, but basically: If you register the key at github.com and later get phished to visit githubverification.com, then the authentication will fail no matter what the phisher does.
Specifically, the phisherman's options for a typical Security Key (a physical authenticator device you buy and maybe plug into a USB port) are:
* Spew random crap claiming it is your githubverification.com key ID, ask you to sign in with this ID. Your authenticator won't recognise this ID and it doesn't work
* Proxy your real ID from github.com and present that from githubverification.com asking you to sign in. Your authenticator won't recognise this ID because it's for the wrong site, though it doesn't know that's why. It doesn't work.
* Proxy the ID from github.com and insist this is github.com. Your browser says "Er, no? This isn't github.com fool" and the UX doesn't fire.
Notice that the attacker not only doesn't get working credentials for signing into GitHub, they don't even get broken failed credentials that don't work, they just get a Javascript error at best.
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.
> 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.
It can, simple as that. Some make it moderately more difficult by showing you, say, 9 pictures and asking you to pick the one that's yours. But, again, dead easy to proxy.
Others also ask you to put in only some characters of your password, which is even more troubling because at best they hash them in various configurations when you change password, at worst - they keep it in plaintext.
With PAKE schemes such as OPAQUE, you verify the site as well, IIRC, and that can be used to derive a shared secret, I think.
It is my understanding that U2F and Webauthn can't be proxied either, but I forgot the specifics and would appeciate if someone could enlighten me.
Conceptually, you just have to generate a keypair using Diffie-Hellman, and sign a challenge after the session has been opened, so that the server can double-check you have the right key (it already has your public key).
In WebAuthn (and U2F but that's obsolete and you should just implement WebAuthn on a green field system) your credentials are inherently tied to an FQDN yes.
There are two tricks involved. Firstly, your web browser is co-opted to do this work. It knows this is news.ycombinator.com much better than you do. If this wasn't in fact news.ycombinator.com, but looked correct and behaved as expected, you likely would not notice, but the browser checks the name matches for every single individual HTTP transaction.
So if the site fakebank.example tries to do a WebAuthn validation for realbank.example it just plain doesn't work.
Next, for a Security Key or similar FIDO1 device, where you can enroll an unlimited number of sites on a single authenticator since they aren't actually stored on the authenticator - the keys used are encrypted with that FQDN. So if bad guys stole your real authentication database enties at Real Bank (maybe from a backup) they not only can't use them, they can't even play them back to you and have you use them - they only work at all on the real site they were for, they're just random garbage on any other site.
This relies on a two encryption technologies. 1. Public Key Signatures (mostly using elliptic curves but that isn't essential). I can pick two related numbers, tell you one, and then in future you can challenge me to prove I know the other one on different occasions, and you'll know I do even though you don't learn the number. Your Security Key can prove to GitHub that it is still the same Security Key that visited before, despite GitHub not knowing which one that is.
2. AEAD Authenticated Encryption. Modern symmetric encryption not only keeps your data confidential, it can also simultaneously authenticate it, your Security Key knows when given back an encrypted "ID" that it's a real one it issued to this web site, because random IDs will fail the authentication step.
Either of these tricks would arguably achieve our basic security goals, but they are both adding further strengths to the system, so why not have both.
> Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
WebAuthn. The article author dismisses it as basically too inconvenient (they apparently keep their Security Key somewhere out of reach and they struggle to remember the complicated user interaction of... pressing a button)
But WebAuthn is completely effective against phishing.
The closest to plausible attacks are: The bad guys take over the target servers (no reason to phish you); The bad guys persuade you to physically send them your authentication device (truly not everybody can be helped...); The bad guys persuade you to install software under their control on a general purpose PC (this won't work on a Phone) and then you follow their bad instructions to "use" your authenticator with their software to get them in.
Mutually authenticated TLS is in principle viable, and I have used it in machine-to-machine systems, but the UX is atrocious and it has grave privacy problems.
I think the conundrum is that such a device uses either a simple UI (like pressing the button), which then is unable to convey to the user which transaction is to be signed off on (the desktop/laptop/phone might be compromised) or the device has its own display and multiple-choice input that'll be too expensive and cumbersome for all to carry around all the time, everywhere.
How is this not a scam? The company is just presenting their form to ask for the same information, relaying it to the government, and charging you $90 for the privilege.
To me a scam involves paying money and then not getting anything for it. You get exactly what you pay for.
These is just competing businesses / orgs vying for your custom, where one org (the govt) is charging $0, so you should totally use them, but won't if you're foolish.
Regardless, one tiny example of all google results (goverment form services) is... the vast minority of google search results. It is certainly not "invariably" a scam.
In the UK there was a problem of commercial companies setting up look-alike websites and charging a fee to do stuff that is free to do via the correct gov website. It's not as common now, partly because UK orgs put pressure on Google to fix it.
For me the top four links are clearly marked ads. (Although some people may miss that [ad] marker). After the ads there are two links to the proper gov.uk website. Then there's a link to a commercial site called "Deed Poll Office", who charge for a services that's free.
In the past that TheDeedPollOffice link ranked higher.
Similar things used to happen for passports and tax self assessment.
...quality controls? They're paying customers, Google has no incentive to prevent scam sites, which is why the results and adverts are infested with them, and have been for decades.
That is quite incorrect. Google has more incentive than anyone else to deliver only the best results and ads to searchers. Delivering them to scams harms their reputation and would eventually erode the CTR.
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.
Author here. I did provide a few other reasons - mostly around usability of YubiKeys. Try observing a non-techie set one up and tell me if you think it is as easy as it could be.
Realistically, you're probably not going to catch a mugger. Otherwise robberies like that wouldn't occur. Snatching a laptop with a key physically plugged in it is probably easier than snatching a laptop and a separate phone.
Regardless of my opinions on tech, if you think being mugged is "user error" then may I suggest spending a couple of days volunteering for a local Victim Support charity.
Hey I understand but didn’t think other reasons were valid. I apologize if my comment came out curt. I know how that feels. However, I think you should reconsider your opinions on Yubikey. They’re significantly better than all other commercially available security solutions at the moment.
Edit: your comment also gave me an idea. Perhaps there should be a phone-based service that you can dial that locks out your account for a predetermined time period? Or it could even be tied to someone else that you can trust.
I have helped literally hundreds of people setup Yubikeys across several companies.
Your take is just not my experience at all. Tapping a blinking light it is much easier than fussing with a 2FA app and works when someone's phone is dead. Yubikeys in particular are near indestructible. They even work after you soak them in acetone overnight and melt the plastic off. I tried.
When it says "plug in your device" you plug it in. When it says tap you tap.
Also the mugger comment is not part of a typical threat profile. Yubikeys and similar devices are meant to protect you from remote attackers which is the class of attack 99.9999% of people need to defend against.
If a mugger points a gun at you, no form of 2FA is going to save you.
Also my Yubikey has a pin enabled and fingerprint enabled WebAuthn devices exist. I have several. If you are carrying things so valuable you are worried about being mugged, you can probably afford a higher end model with a fingerprint or pin.
Edit: yes I know random muggings happen, but a hit and run mugger that knows what a Yubikey is and already has your password is a hiiiiighly targeted attack. -That- pretty much never happens unless you are walking around with a $1,000,000 in Bitcoin in which case it has happened a total of 5 times that are public.
You have to (well, I guess if it isn't your job you don't have to but it's polite) help people set up anything. Doesn't mean it isn't easy. Helped my mum set up Zoom (so she could attend virtual church apparently), is Zoom not easy?
Two (three?) jobs back I had to set a bunch of people up on one time passcodes. Those seem pretty easy right? Still had to go there in person and show them.
Depends. Some have a bunch of magic numbers you can use as alternative "second factor", basically another password for the special purpose of bypassing a real 2nd factor. That's of course stupid and dangerous.
Then there are those where you can register another 2nd factor, e.g. another Fido-Key, SMS-Codes or recovery email. Those might be better or might be worse, depending on the method and circumstances. E.g. SMS is vulnerable to all kinds of SIM-Cloning and redirection stuff, email is vulnerable to whatever your email might be vulnerable to.
The only thing I would accept as really idiot-proof and secure is "go someplace, show a government-issued hard-to-fake ID" (like a passport, not your drivers license...) like banks do. But that only works with physically present businesses and accounts that are strictly tied to one person. And even there, "Joe Smith" might impersonate "Joe Smith"...
Some other responders have given you the answer as it currently exists. They are all either inconvenient, weaken security, or both. For that reason, I would only suggest using a security key for a small number of critical services, where it's worth the extra effort to deal with the backup mechanisms.
If you mean when registering for a new account, annoyingly you need to physically have each key with you to register it with a new service. Biggest flaw in the spec IMO.
If creating new accounts only when you are at the secure location where your backup key lives works for you that's great, but I suspect that most people in that situation would do one or more of the following:
(1) Store their backup key in a more convenient, but less secure location (likely their home), putting them at risk of losing both the primary and backup key to the same event.
(2) Enroll only their primary key when an account is created, putting them at risk of locking themself out if they forget to add the backup at some point.
(3) Only use security keys for the highest value accounts, which tend to be a small enough number that you have a chance of actually remembering to add the backup key every time you set one up.
Of these, #3 is the only one that doesn't pose what I consider an unacceptable risk of lockout to the average person, so that's what I recommend.
The location doesn't need to be "secure" in the military sense of the term. Mainly you want it "secure" in the sense that if you lose the one key, you won't have lost the other key at the same time.
In the end, the two keys are equivalent from a risk profile if they are compromised, and for most people, the one they carry with them is going to be the weak link in the chain, so additional security on the other key isn't really accomplishing much.
In truth, if your home isn't secured, there's enough holes in most people's online security that someone in your home could find a way to compromise much of your online security (and from there, most of the rest).
Just keeping the other key tucked away in a drawer has some risk, but is pretty decent for most people. Keeping it locked in a fireproof safe in their home along with other important documents/keys/bits is a better choice and not terribly inconvenient.
If you want to be more thorough, you can always have a third key that you keep locked away in a bank vault, and you do "wing it" with just two keys for a period of time on new accounts.
What you don't want to do is "wing it" with one key (though AWS seems to think that's the way to do things). That can lead to disaster. What you also don't want to do is only use it for a subset of your accounts, because in practice most people are terrible at risk compartmentalization, so invariably a compromise of some of your accounts quickly becomes a compromise in all of them.
In my experience #1 is the right way for most people to go. There are disaster scenarios where you lose both keys, but usually that's a disaster severe enough that recovering your online access is the least of your worries, and it does a great job of mitigating the much larger risk of mismanaging the security of accounts that aren't secured with the key.
I agree with your definition of secure for this topic. I don't agree that a primary residence qualifies as secure under that definition. Fire, flood, earthquake, etc all put you at risk of losing both keys, as does a search by law enforcement.
I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened.
And home isn't really convenient enough for many people: I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2.
"I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened."
You might care, but most people would have bigger problems at that point.
> I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
Again, most people aren't on the road a lot, and most of those that do already follow so many other bad security practices when they do so that creating new accounts in that context will already be fraught with peril regardless of the mechanism you use... and they'd probably be increasing their exposure if they used a password manager. I'd advise them to not do it, or to create a temporary account using some low-security, low-tech compartmentalized mechanism (like writing the passwords on a piece of paper ;-) and then delete the whole thing and create a new one from scratch when they get home, because that's probably less likely to be a problem. ;-)
"For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2."
I do use a YubiKey secured password manager for services that do not currently support U2F/Webauthn, so I agree that is really the only practical solution for certain cases. There's an in between space where you can use the SmartCard protocol or hardware based OTP, but... My observation has been that for "most people" the non Webauthn cases are a) not necessary and b) actually far more difficult for them to manage, leading to them simply not using the password manager for a lot of cases.
It turns out the typical person's needs are surprisingly limited, but the risk is enormous as is the number of "pathways to failure".
This was confusing to me until I realized a couple of things:
- you can still have TOTP enabled on the site as a backup 2FA method
- you can configure multiple yubi keys for a single site - so I have one on my keychain that does NFC + USB-C for my MBP, and another “Nano” key that is left in my home imac - they are both registered with most of the sites I’ve configured
If my keychain is lost/stolen then I can still login from home or with my TOTP code as a fallback.
I agree on the idea around usability of YubiKeys. I have them also and believe they are great, but I never seem to have them when I need them. Of course, maybe its on another floor or another room and I am being lazy not walking over there, but it is an added inconvenience on a process that needs to be balanced between security and convenience.
Your opinion is in this case based on your ignorance and misunderstandings. The main threat model U2F key protects against is phishing, and phishing is the largest threat currently. The password is sufficient to protect you for opportunistic offline attacks like theft or loss.
> may I suggest spending a couple of days volunteering for a local Victim Support charity.
Please try being less condescending.
Losing the keys, due to whatever reason, means losing one factor. If the user loses the key, the "mugger" still needs to get the users' passwords.
2FA = something you know + something you own. Having one factor compromised should not compromise your accounts if the service you are using is configured correctly.
That's not exactly correct. Another factor is something you are, such as a fingerprint or eye. There are three classes of factors from which drawing any two is called 2FA.
There is also a 1.5 factor auth, used for example by many banks, in which there is a server challenge for the very vulnerability stated in the article.
I've spent a lot of my life around Toxteth and Moss Side, and that doesn't affect my threat model relevant to phishing and FIDO. Mugging is probably less of a threat than break-in anyway, as far as compromised hardware goes. You separate the token when it's at risk, and the setup procedure claimed for FIDO, to the extent it exists, seems about as easy as it could be. It's a key. People can understand physical security to a reasonable degree, and typically not abstract computer security.
Being mugged isn't "user error", and the good part about YubiKeys is that the consequences of being mugged are much more intuitive (it's just like I had my keys stolen).
The "I left my keys in my coat" problem you have seems like it has a pretty obvious solution: don't keep your YubiKey on your key chain. Do you have a wallet or cell phone that you carry with you at all times? Put it in the wallet or cell phone case.
Speaking as an author of a webauthn library who helps users set up their security keys as part of their training, it's about as easy as it can be. We give each of our customers 2 yubikeys for each user when they sign up, tell them to keep one on their keychain and the other in a safe location only accessible to them. If you lose/destroy your main key revoke its access use your backup and buy/setup a new one. No one has had difficulty understanding the process for our site since we show them all the steps up front and describe what to do in common scenarios. If your customers have a problem setting it up, it's a reflection of poor user experience not protocol design.
If your laptop get stolen (with Yubikey in it) you only loose one of your TWO factors. So the thief does not have access to your account since they don't know your passwords.
Also, if a user can't learn how to operate a Yubikey after 10 minutes I don't think there is anything that can keep them safe online.
Another issue not mentioned by the author is what happens if the Yubikey is lost or breaks. The story around this type of event is sort of ignored and not understood properly. AFAIK it's not possible to duplicate a key (by design), meaning that the user will have to update all their websites' 2FA (hopefully there is a recovery method available).
Yes. You must have at least two keys registered. However it’s worth noting that most services do not offer priority. Meaning you can use either one. I think it makes sense to designate back up keys and only to be used when user reports lost/stolen primary key.
But what is the story there? You have a backup key, hopefully stored "off site", now you want to enroll in another website. You have to get that backup key before you do that? Or bookkeep which sites you have on the backup key and which you don't?
This is a very good point and perhaps something Yubikey and similar services should consider: paired keys. Once paired the backup can always replace original if user reports it missing or lost regardless of when they were paired.
Actually, this is one area where pgp's use in pass works really well. You use your public key to encrypt passwords. So, adding a new one doesn't need the physical key.
While it's not possible to duplicate an existing key, it is possible to create duplicate keys in the first place - you can't get the secrets out, but you can write identical secrets to two or more keys if you want to.
This adds some convenience, though it also does add some risks e.g. in case of breach you can't tell which token was misused, you can't invalidate a lost key without invalidating others at the same time.
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.
eBay, for example, offers a passwordless experience using WebAuthn--so it can be done, even on a major consumer site.
The problem is really that until relying parties can trust that
1. Platforms will backup and restore key material from authenticators
2. Users will figure out how to use those backups (including if they e.g. switch from Mac to Windows)
they will have to provide some fallback. (Realistically, that means "for the foreseeable future.")
This relegates WebAuthn, unfortunately, to a "neat trick"--eBay's "passwordless option"--and not a security guarantee. (Phishers can always downgrade the user to passwords or similar.)
What's needed in the interregnum is probably a way to make that fallback option more secure by, at minimum, conveying to users that it's not _normal_--so that phishing attempts targeting that phishable backup are less likely to succeed.
Unfortunately this requires a lot of good UX design and unilateral action on part of the relying parties, which I think is tough.
One form of securing fallback mechanism is to include a long delay, some 2 days, between reset request and execution. It surely does not fit all use cases, but should be good for a lot of less critical stuff.
I also think the most of the issues they bring up I understand as adoption (which gets improved by increased adoption on the user side), tolling maturity, and habits.
TOTP and U2F actually has achieved pretty wide adoption, so I have hopes for WebAuthn.
That's cool. Either I haven't seen this before or I've forgotten. :)
I do think (as I said elsewhere here) that ultimately people will adopt WebAuthn via their browser/OS vendor. Support is widespread! But for relying parties, there are still challenges to solve.
> Krypton is built on top of an end-to-end verified and encrypted architecture. This means zero trust. We, Krypt.co, cannot access your keys or see where you're authenticating. The keys only live in the Krypton app on your phone.
Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.
Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:
Trusting your HSM vendor is a requirement if you don't want your keys to be exportable, and there's much less risk in doing so compared to trusting Apple for other things like secure communications (iMessage is e2ee but doesn't tell you when your peer changes/adds keys, plus unencrypted backups are on by default).
Sure, I agree that RPs should not use attestation in most cases. (Enterprise use—where the company has issued specific hardware to clients—is an obvious exception.)
Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass.
That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
> Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore.
In the case where the SE/Keystore is controlled by something like the Intel Management Engine, that distinction might be meaningful, but you're probably right that in general if you don't trust the device manufacturer then it doesn't matter how the SE/Keystore is implemented or managed.
Moreover, I suppose if you trust the OS to be doing what it's supposed to, the only things a malicious SE/Keystore can do are cause a denial of service or fail to keep your secrets (in the worst case by broadcasting them with a hidden antenna).
I mean, in the extreme, yeah, malicious hardware can exfiltrate secrets. A hidden antenna, as you say—or more subtle attacks (e.g. https://dl.acm.org/doi/10.5555/1267336.1267341, though this would require more than just the Secure Enclave to be malicious).
But yeah, I think for the ordinary consumer this is not a useful distinction. For vendors who are thinking about supply chain attacks, for sure this is a real consideration.
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...
For U2F specifically you don't need apps except support in the browser. The apps you listed are used for other types of functionality provided by the yubikey, like OTP and TOTP.
If you had used one of the $10 USD Webauthn (aka U2F) tokens, it wouldn't have asked you to install any applications.
The "problem" is the expensive Yubikeys that you were whining about has lots of extra functionality that has nothing to do with U2F, and that's what the extra applications are all about.
I happen to use a Yubikey because I want that extra functionality, including using it to secure the keys I use for ssh and for digitally signing git tags so I can securely push git pull requests. But that's because I'm a developer, and it's why I'm happy to purchase multiple Yubikeys (one for my desktop, one for laptop, backups including one that is on a keychain, etc.) Perhaps you were reading web sites that was giving advice for developers as opposed to for consumers?
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.
most people have a phone that can leverage webauthn, so you don't even need to buy anything.
On top of that, webauthn can be configured to prevent phishing as well
Could you let me know where I can buy a well supported WebAuthn key for that price?
Looking at Amazon UK - https://amzn.to/3oWGYe4 - the cheapest appears to be about £30. Unless I want to risk my security to some no-name brand with zero customer support.
When I got my YubiKey, it told me I had to download an Android app to make it work. So, perhaps better documentation is needed?
I'm sorry you didn't like my post, I'll try to do better in future.
I don't think the kickstarter is relevant now. You just buy them from solokeys.com. There's been Somu since that, and Solo2 is in the offing, with plenty of storage, apparently. I bought Somu partly for convenience, and partly for the promise of PGP support, which unfortunately hasn't been added yet (though there is a development version).
In answer to the expense question, two Solo keys appear to set you back 38 quid at the current exchange rate. I don't know how they compare with HYPERFIDO, which I don't think I'd come across before.
I can confirm what you and _wldu are saying and yes, the latest project is https://solokeys.com/v2 and is launching end of this month.
From an economic perspective, unfortunately, it's really hard to focus on reducing the cost, there's simply no incentive.
First, consider that the biggest cost in the customer getting a security key is basically shipping + packaging. Imagine a key that costs <$3... even packaging with a polybag + printed label + padded envelop gets to a cost that has a significant % of the production cost.
Next, it's features. To stay on par with competition, people expect the same features (see, e.g., openpgp mentioned above - the code currently doesn't fit in the stm32l4 flash), both firmware and hardware. As a result we have to look at the latest & greatest micro, but of course that alone has a significant cost.
And finally, there's the overall viability. We all know that open source projects die without a business model. The numbers in the U2FZero review simply don't add up, that was clearly unsustainable and that's why we made SoloKeys. A business has expenses other than manufacturing and if you don't account for that, the business dies together with your dream project.
Anyway, thank you both (and all others) for the great support. One step at a time, we'll get to a stronger and eventually also cheaper product!
Ah, I didn't know about the PGP code size. Point taken about the cost, and I hope you can sell to organizations. I'm surprised I can buy a competitor for £8, but then I can't run the proprietary programming software or, I assume, re-flash it. I'm happy to support a free software project anyhow. I wish I could register my Somu with the work Duo system rather than the display-a-number-you-type HOTP keys they reluctantly issue as the expensive alternative to expecting us to use personal phones for such purposes. Phishing, we've heard of it.
Nice try, but I will never attach an usb device for frequent usage that sticks out like the Solokeys v2. The size of the Somu * is fine, as it doesn't need to removed when transporting a laptop.
The stm32 used in v1 was 3x3mm, while the new nxp lpc55s6x used in v2 is 5x5mm. Plus we added 2mb of flash, though it's optional.
If anyone wants to try to packing the components into a somu v2, that'd be a nice addition to the *omu family [1] and we'd be more than happy to help with manufacturing. Same for a somu for usb-c.
> I bought Somu partly for convenience, and partly for the promise of PGP support, which unfortunately hasn't been added yet (though there is a development version).
It is sad that with PGP being so horribly broken, it still casts its shadow over security products.
The HyperFIDO is basically fine, it's obviously your choice to insist on the expensive famous brand products, but it seems a bit crazy to on the one hand insist those are too expensive and then reject perfectly good cheap options.
If I had a corporate budget to spend maybe I'd order trays of Yubico Security Keys or Google's Feitian rebrand. But I just wanted to have more than one vendor so I have this product (well not this one, but it's the same product under different branding) and it works fine.
For the reasons listed in the article and more, Yubikeys and similar devices aren’t likely to ever be popular.
To give future security devices along the same vain a better chance at gaining popularity and being widely adopted (which will hopefully bringing us a more stable, less stressful society), the designs of these new devices must solve or workaround the issues the author describes.
It’s really annoying when individuals such as yourself respond so very negatively and unconstructively while others are trying to discuss the issues with existing designs — an act necessary for us (collectively) to develop new designs.
The author may not provide strong evidence for their claims, but neither do you provide strong evidence (or extensive reasoning) for yours. The net gain here is negligible, expect for showing that contrary opinions exist, but that’s not particularly helpful as for every opinion held it is inevitable that someone holds the polar opposite.
I’m not a moderator, but I ask you to please try to better further the discussion with future comments.
I think Yubikey (and similar physical solutions) will eventually gain popularity. Carrying a key is pretty much a standard practice across the globe and benefit is more than negligible because it forces physical attack versus remote/virtual.
Instead of a hardware authenticator to be carried on a keyring, they should be put into rings, i.e., the things meant to be worn on your fingers, i.e., the things that most people use for providing input to their computing devices, whether they sit on a desk or are held in one's hands.
Until keys become cloneable they will never gain popularity.
Nobody wants to re-setup every site ever because they lost their laptop that they kept it plugged into, so they won't. either this means using their backup until they lose it without even revoking the original and then swearing off the entire concept while telling all their friends to do the same, or just not using hardware tokens after the first lost of keys.
Also the "back up code" they will also get, guess where thats going! save as -> downloads or print2pdf -> downloads.
When it comes to personal account security by end users, hardware tokens will never take off, and this is why they get so much hate.
There is a real problem here that really needs to be really solved, wrt to end users and phishing/hack resistant credentials, and as long as we legitimize the lie that yubikey solves it, we gimp progress towards actually solving it.
I am not understanding your concern. You definitely don’t want the keys to be “cloneable”. You need at least two keys, sure, but I don’t see that as an inconvenience. And you should be using a password manager (with passwords cycled on a periodic basis) that is bound to your physical key.
I don't think cloneable is a good idea. If some 3rd party clones your token and uses it to commit a crime there is no way to prove that happened.
There are other solutions. Being able to make one key a proxy for another is one. That allows you to keep your master identity in a bank vault, and then use it to "sign" the one you keep on you during the day. Should you lose your daily driver, just sign another one. This still suffers from the "one true name" problem though - if someone steals that bank vault ID, you're gone.
Another approach is servers allowing a client to register multiple ID's, and later delete them. Since there are multiple ID's, there isn't one true name any more. If one is lost you cancel it, and replace it with another. The approach is already built into the FIDO2 protocol, so they've already thought about your concerns and solved them, and IMHO solved them in a better way than you propose.
A more robust approach still would be a combination of the idea above: FIDO2 multiple ID's solution, plus proxies. One key could then provide multiple ID's to every server you log into, signed by different masters that are stored in different places. Keys can't be copied, but a lost key can be replaced by signing it with the master. A compromised master can be have all it's ID's dropped by logging in with an ID proxying other master. You could think of it as RAID for 2FA's.
> Being able to make one key a proxy for another is one. That allows you to keep your master identity in a bank vault, and then use it to "sign" the one you keep on you during the day.
Yes, clonable tokens. Exactly.
When people ask for clonable tokens. This is an acceptable solution.
(But skip the bank vault. This is for avg Joe, not Jeff bezos. The closest safe will do)
I've long thought that U2F should be incorporated into phones, since everyone has one of those. Even not well off people in third world countries. In order for U2F to proliferate, everyone should have access to it. A $10 FIDO key probably won't be given a consideration if they think a free password is good enough.
WebAuthn is the modern replacement for U2F. Do not deploy greenfield U2F, it's a legacy technology only.
A modern iPhone or high-end Android phone already does WebAuthn secured with your fingerprint or (on some iPhone models) facial recognition, like your lock screen or contactless payments.
I use a Yubikey daily and the OP is greatly exaggerating the issues in my opinion. Vanguard for example it took less than a minute to set up. I don't have an "application" installed locally for the Yubikey, it was plug & play. No special software needed.
I honestly think Yubikey type devices' largest problems are -
1. Marketing. People simply do not know they exist or how they work (simple or not).
2. Support - Many websites do not support Webauthn yet. We really need developers and businesses to consider this a priority.
I have bought some keys for my family members and they love them once I demonstrate how they work.
Price. Yubikey's "best seller" goes for $45, that's grotesque. I would be surprised if the hardware costs exceeds $2 per unit and the software (or similar) can be had for free.
It's not about the hardware. In spite of the fact that they can nominally be broken into, most modern USB microcontrollers can easily implement being a security key.
The expense is that the security world hasn't converged on anything remotely approaching a single standard. So, a key has to support ... PGP, OpenSSH, FIDO, FIDO2, U2F ...
For example, you couldn't use some of the older YubiKeys with AWS because AWS only supported time-based TOTP.
That's a LOT of software work, and you can't be "Startup Sloppy" with your code or someone will break it.
The PGP thing is wildly different than the other applications in that it is a complete airgapped system on a key. The decryption and signing is actually done on key so the private key isn't exposed. PGP is pretty much the only thing that does this and as a result can be held up as an example of where we do in fact have a unique standard.
> I’m not a moderator, but I ask you to please try to better further the discussion with future comments.
Please don't go there. You're both adding to the discussion, maybe some strong words here and there, but this turn of phrase you used is a huge conversation destroyer.
It is disappointing that touch id doesn't support this yet, it would be great. I put my ssh keys on touch id but my webauthn and gpg are on the yubikey and I have to remember which to touch. And the yubikey with finger print reader isnt out yet and I already have pretty much the right hardware in the mac...
Disappointed but not surprised when reading this. To be really honest, I can't remember the last time I read something that criticized so called "techbros" and actually said something reasonable.
As for the U2F devices, the idea of just leaving them in, the small yubikeys and all that, seem to just be a bad idea from the get-go.
What is your objection to just leaving a yubikey plugged in? It eliminates most of the ways an attacker could impersonate me besides literally stealing my laptop, which is a high bar. Most people are valuable enough targets to phish or infect with malware or something, but not to plan a computer heist.
Stealing the computer is usually enough, as a browser cookie serves as proof of authentication all on its own. Some destructive operations require extra auth, but in terms of data exfiltration, stealing a laptop gives you everything you need.
What exactly does that have to do with YubiKeys though? Every time you use one you need to enter password. And you can also immediately revoke it as soon as you notice its stolen.
I kind of omitted that part. Having a YubiKey in or not in the laptop won't really affect things (other than the fact that you will need to get into your account somehow without the yubikey if the yubikey is stolen).
"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.
Same, and many websites have support for multiple keys so enroll a couple of the cheap $10 ones (per device) and then you can use TOTP or just printed codes as a backup.
Even if your device is stolen
1) it's unlikely by a technically savvy bad actor (and if you're at risk, you probably have had special data security training anyway)
2) you're still only stealing one factor. Your device should also be encrypted with a password which would protect any passwords [managers] on the device
It's essentially a smartcard (certificate storage) in a more convenient form factor for most users, so you could use them to store your RSA keys - though personally I would not trust them - but they are not FIDO/FIDO2 so they are almost useless in the context of the article.
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.
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.
> 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.
There are many legitimate situations in which a login domain is changed and a password manager no longer works. So then you manually open the password manager, look for the password, copy+paste, and save the new entry.
How can you be completely confident that this isn't an attacker?
In that rare case you just check the URL. Contact the company if it is a high value login. You can also verify by searching for the site and clicking through to see what their webpage offers as ground truth.
Right. One of the good decisions in WebAuthn is that this type of nonsense simply isn't possible. It's designed so that you can't do this. When the big boss absolutely insists that ourcorp.example must rename to xp4ifis.example because of whatever nonsense, there's nothing to argue about, it won't technically work, it can't be done. Like if they decided it would be better branding if up was down, too bad.
In almost all cases these were just about vanity (e.g. the university where I studied and had some of my first jobs renamed itself and gave every web site new URLs, purely out of vanity, at considerable cost with no benefit) and so when they discover it can't be done technically they just give up and continue to use the old name for authentication, meaning your security posture is intact. In the few other cases you're now going to have to have a conversation with your users about why you broke everything and need to begin over. I sure hope the gain to your organisation was worth it.
This leaves a human to try to make deductions about whether githubverification.com is github.com which is something humans are terrible at, so game over.
If you have WebAuthn then your browser also takes responsibility for only letting you use your github.com credentials on github.com and not even bothering you with any other possibilities that you might think could be safe and are not. That's why WebAuthn prevents phishing.
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."
Right, they could have access to your account, but not full access. A good website will ask for 2FA again if a user tries to do something destructive (like change password, email, or disable 2FA). They wouldn’t be able to do those things.
> A good website will ask for 2FA again if a user tries to do something destructive (like change password, email, or disable 2FA). They wouldn’t be able to do those things.
The page mocking the login page where you need to answer the 2FA will simply phish your 2FA then, after a little delay pretending there's some lag, would say "wrong code, please try again". Now the person enters a second 2FA (which, due to the delay, would be different than the first one).
As I've just commented in a top-level comment: I've seen sites using a 72 hours delay before any destructive change can be made, coupled with the sending of an email containing a link allowing to unilaterally prevent the change.
I've also seen sites using two 2FA (TOTP style), one for login, one for any setup/destructive change. And there are sites using both techniques.
It's not 100% foolproof but it's better than "one 2FA phished and it's game over".
While this is possible, it does require significantly more effort on the part of the attacker and there are many more points of failure. So I'm guessing most phishing sites don't actually do that, even though of course some do.
All that is required is that they phish in real-time or automate the attack. These attacks are not uncommon in the wild. MITM’ing three fields in a login page is not much harder than writing two fields to a DB. And it’s basically trivial to do it over the phone.
If you look at the context of the article, you should assume that phishing attack is sophisticated enough and responding to that attack with "you should use 2FA" is missing the point (which is exactly what the author claims).
2FA (at least the simple OTP variants) don't protect against phishing, they just protect against sloppy phishing attempts.
Phishing has been commoditised, the criminals don't write their own pages anymore.
In fact the phishing toolkits have been doing TOTP passthrough/relay for a few years now. For the attacker, it's a nice feature: victim could be using SMS, authenticator app or even an out-of-band delivered token book - they are all captured and passed along equally well.
U2F and FIDO2 with hardware keys are the only realistic safeguards. On the other hand, I do subscribe to the stated problem, because for most people they are a usability snag. The NFC variant has the potential to address this, though: instead of plugging a key in and touching the blinky button, you just wave your keyring next to the device. Too bad NFC readers are not universally available on phones, tablets or laptops.
German banking has ubiquitous qr-mediated second channel - the authenticator (app or physical device) reads a qr code, shows the transaction details on screen and if they match user types back a code from the app (which is based on qr content).
Also, I'm a big fan of U2F keys including Yubikeys.
I don't use SMS, deprecated it 10 years ago in favor of e-mail, and would never use SMS for 2FA. I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it.
For most people, SMS is hackable, tied to a single battery-powered device, easy to steal (after which for most people in the default phone configuration the SMS verification codes will happily pop-up on the lock screen without unlocking the phone), and hugely inconvenient if you are in front of a desktop computer all day and have to go find your phone (at home for example I pretty much never have my phone next to me). SMS also famously locks people out of their accounts when they go to another country and have to use a different SIM card. Also, if you have a giant desktop in front of you, it's ridiculous to not use that as your 2FA device. You should NEVER have to pick up a 6" handheld device for 2FA when you have a massive immobile, hard-to-steal device in front of you that in my case is also physically locked down to furniture.
Yubikeys and other U2F keys do exactly this.
The article is wrong about one thing:
"But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom."
No. My preferred way to use Yubikeys is to buy one for each immobile device (home/office desktops) that stays plugged in, and ONE mobile key that lives in my wallet. Register all keys with critical services. If any device gets stolen (highly unlikely for the immobile devices, the mobile device is the only one I need to worry about really), go home, log in with another key and remotely disable it.
My main gripe is websites that don't allow multiple Yubikeys. AWS is at the top of my hall of shame.
I would love to be a fan of Yubikeys, in fact most people would say I _am_ a fan of Yubikeys, I think I have like 10 of them (due to product evolution and always buying a few when I buy one).
Unfortunately most of the sites I use do not have anything to do with them.
Have you tried using the Yubico Authenticator? It usually solves the problem for the sites that don't support U2F, such as PayPal, Coinbase, Gusto, and others.
B. Find a different virtual SMS number. Try other countries as well. Sometimes it costs a small monthly fee but I don't want to give in to their idiotic game.
2FA absolutely will protect you from a phishing site using the password it stole.
Not if it also steals the 2nd factor. My response would be more like "2FA is good but not for this problem." This problem is about going to the wrong site. The solution is to go only to the right site.
I bought my whole family Yubikeys last Christmas for exactly this reason ... you can't trick someone into a hardware token authentication. Now I tell people to use something with U2F. I find myself using software U2F and include the secret key in my password manager so that I don't need a hardware key from my laptops.
Normally you can create backup hardware recovery keys (or alternate fallback 2F). (EDIT: Keys as in e.g. alphanumeric on time use tokens lie "23430240392")
This is necessary as you would else wise be permanently be locked out if you lose your U2F key.
That is assuming you can't reset your U2F key using mail password recovery. But your mail being a single point of failure is something U2F normally tries to prevent.
Through I guess for not relevant services. I would still want U2F but allow mail recovery and maybe even U2F _only_ login (or FIDO login without PIN).
Given that people have different opinions about what is important I guess this should be an option for fallback recovery, maybe with some warning around it.
The "workaround" to have no fallback for U2F is to generate recovery keys and then not store them anywhere ;=). But I would not recommend this, except if they have a insecure mail based password/U2F recovery anyway.
I have 4 keys which are stored safely. I do not want a fallback mechanism because that reduces the security of my account. The downside is I have to manage my keys on each site separately. It is a shame that the original OpenID never stuck around as I could have just had one secure account, without having to be part of the current ID provider cabal.
Or perhaps worse, they want SMS OTP to be added as a backup. Even with tons of messages telling people not to share OTPs, it still happens through social engineering.
Sure, but isn't that the point? There's now a second thing they have to steal, and if they only get the first it's pretty worthless, especially if there's monitoring/alerting in place that prompts a password change and/or locks your accounts pre-emptively.
As phishing usually includes impersonating a website and making the victim believe they are giving their credentials to the original service, I think it is implied that most victims would willfully provide their second factor, when asked for it.
So, in case of phishing that's not the point. If you're actively logging in yourself a second factor doesn't prevent the attacker from gaining access.
In Webauthn/u2f the 2nd factor is a proof that is unique against the particular site. So stealing the 2nd factor is significantly more difficult since it requires compromise of the computer/endpoint used to access the site to pass the wrong site to the hardware token, or cloning the physical device which should be tamper resistant (but not totally unheard of to clone some devices).
Your statement is true for HOTP/TOTP based 2nd factor like google authenticator on a phone, although the stolen credentials shouldn't provide persistent access.
And password re-use is still a problem if every service isn't covered by Fido2, but we need to start somewhere.
Given a successful login and session, perhaps on some sites this is enough for passwords reassign via some backend (likely intended for mobile apps) API?
Actually better education and training is often the only real solution. It isn't "victim blaming" if the situation is at least theoretically within the victim's control. If some random "plumber" that I didn't call for shows up at my house, asking to be let in to replace some of my pipes, and I say "okay", then he robs me, is it victim blaming to say perhaps I should have been more suspicious of strange plumbers randomly showing up at my house to do work?
> education and training is often the only real solution
No. That is never the real solution. At best it is a necessary evil, but generally resorting to this is a reflection of a failure of imagination.
The reverse authentication problem in particular is easily solved by the right UI design plus some improved infrastructure behind the scenes. Certificate pinning, for example, would help a lot. The hard part is not coming up with a solution, or even implementing it, but convincing everyone to adopt the solution because it doesn't help unless it is widely deployed.
The problem is that the people who need to be convinced are not the people who are being harmed by phishing. The people who are being harmed by phishing (non-technically-savvy end-users) are powerless. The people who need to be convinced of the merits of the solution are browser vendors and web site operators. Both groups would need to work together to solve the problem. Getting that to happen is the hard part. It's a very real problem, but it's a political problem, not a technical one.
Well, name one error that persists despite not making the error, and you can definitely say I'm wrong. But that wasn't the point. The solution is to go to the right site. You were supposed to use your imagination to come up with ways that might be caused to happen. The article and commenters here suggested password managers that discriminate between the right site and the wrong site, that's an example. "OH SURE BLAME THE VICTIM FOR NOT INSTALLING A PASSWORD MANAGER!" If you're looking for a solution that doesn't whatsoever require the participation of the user, you may meet with some degree of disappointment.
There may be viable solutions that include still going to the wrong site, but I know for a fact that going to the wrong site does not happen if you go to the right site. It's a tautology just like your disingenuous Twitter-style reductionist accusatory re-interpretation of my comment suggests. Speaking of which, if you want to blame the victim, go right ahead (that was your idea), but I don't think the computer cares who gets blamed, unless and until it affects what gets typed in or clicked.
Not all 2nd Factor solutions allow stealing the 2nd factor.
Mainly U2F incorporates the domain and (should) only work if an TLS connection with a valid certificate for given domain is used. Furthermore it uses a key exchange. This means:
- The attacker needs a valid certificate for the applications login domain, which wrt. web security is normally assumed to not be possible but tbh. might be possible in case of an state actor or similar.
- The attack needs to be live in the sense that password and 2FA auth needs to be directly forwarded to the attacked web-application and there it needs to trick any bot detection to make it believe it's not a bot. This also means even if they phish your authentication they only can use it once at the moment they phished you. But to e.g. then to disable U2F they often need to enter another password, so they need to phish you twice in a row, which is harder, but only slightly harder, tbh.
- Alternatively they might hack the service and get their hands on the private webcertificate and clients private key if the service doesn't use a HSM for that. But that is normally much harder and for many attacks unfeasible (and there is normally little reason to phish if you can hack a server that deeply).
The article's first and most prominent criticism is that it costs at least $30-$60, which might be a barrier to mass adoption but for most HN readers is not a serious reason not to use it.
I own two (one as a backup in my safe in case I lose this one. They all have the same TOTP stuff and setup in every service side by side where possible), to agree with you. Though it’ll be lovely when your iPhone can be a U2F key through their hardware security chips and some OS support, if I’m dreaming out loud.
I do like phones are building in these keys, it makes them way more accessible to the general population, and generally not a pain to use. And then those of us with physical keys get better support too :)
And the third is that they leave their keys in their coat. When I’m at home, I leave my keys (and therefore my yubikey which is on my key ring) on my desk and when I’m out, I always keep them on my person and never unattended.
So that leaves ease of setup and support. Since setup only has to be done once per site, and I only bother with important sites, that’s not a major deal for me either.
U2F is so infrequently used on public sites compared to SMS and TOTP. Of the things I use regularly, that arn't for work, that have a 2FA option - I think two (Google, and my password manager) supports U2F.
For either of those methods, stealing two SMS/TOTP codes isn't that much harder than stealing the first one - you just display a fake error saying that it failed, and try again.
For all but the most attentive folks - getting a "Whoops, try again" error when authenticating is probably going to be a semi-regular occurrence anyhow, so adding a fake one in there probably won't trigger any mental alarms.
Yeah, I really wish more things worked with U2F. I especially hate when I enable U2F on a site it works on (Twitter) and then every time I log in it does an sms code anyway, even though I have U2F enabled and would much prefer to use it, but like having my phone number as a recovery backup.
Well once the authentication token expires, they would need to phish you again to get another 2FA token, so there is that. But that is probably plenty of time to do some harm, and depending on the service, possibly even disable 2fa (although a good site will require another 2fa authentication in order to do so).
If it’s a website which supports API key or any token of sorts (without expiry or long expiry), they could do some real damage even if they can’t use the 2FA again. Another thing would be to disable 2FA.
All they have to do to achieve this is to use the phished credentials to immediately login with the original site, trigger 2FA and then show a field to capture it and pass along. Then capture all the cookies.
The best defense against phishing is to use a password manager that does domain matching.
Not the person you asked, but: 1Password which I like, and Lastpass which I don't, both do domain matching in the browser extension. All iOS password managers that integrate into the system do domain matching as well.
In addition to that, now I noticed that in the blog post:
> I recommend the open source Bit Warden.
A password manager stores your passwords. But it also stores the web address of site’s login page. If you visit githud, the password manager won’t prompt you to use the login details for github
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.
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.
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.
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.
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.
This is an issue with any domain-verified TLS certificate, which make up the overwhelming majority of certificates in use. Only CAs which offer organization-verified (OV) or extended-verified (EV) certificates, typically at exorbitant prices, does the TLS certificate attest the publisher of the website.
> Only CAs which offer organization-verified (OV) or extended-verified (EV) certificate, typically at exhorbitant prices, does the TLS certificate attest the publisher of the website.
Even so, I’ll expect financial institutions to have that.
Note: I’m not saying the above is a Cloudflare issue, perhaps someone at Visa was being stingy - I’m just saying it’s an issue and would be bad if that becomes the mainstream.
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?
268 comments
[ 4.9 ms ] story [ 249 ms ] threadThat'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.
I don't understand what you mean. Something about 2FA does this? How?
The details are complicated, but basically: If you register the key at github.com and later get phished to visit githubverification.com, then the authentication will fail no matter what the phisher does.
* Spew random crap claiming it is your githubverification.com key ID, ask you to sign in with this ID. Your authenticator won't recognise this ID and it doesn't work
* Proxy your real ID from github.com and present that from githubverification.com asking you to sign in. Your authenticator won't recognise this ID because it's for the wrong site, though it doesn't know that's why. It doesn't work.
* Proxy the ID from github.com and insist this is github.com. Your browser says "Er, no? This isn't github.com fool" and the UX doesn't fire.
Notice that the attacker not only doesn't get working credentials for signing into GitHub, they don't even get broken failed credentials that don't work, they just get a Javascript error at best.
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.
It can, simple as that. Some make it moderately more difficult by showing you, say, 9 pictures and asking you to pick the one that's yours. But, again, dead easy to proxy.
It is my understanding that U2F and Webauthn can't be proxied either, but I forgot the specifics and would appeciate if someone could enlighten me.
Conceptually, you just have to generate a keypair using Diffie-Hellman, and sign a challenge after the session has been opened, so that the server can double-check you have the right key (it already has your public key).
There are two tricks involved. Firstly, your web browser is co-opted to do this work. It knows this is news.ycombinator.com much better than you do. If this wasn't in fact news.ycombinator.com, but looked correct and behaved as expected, you likely would not notice, but the browser checks the name matches for every single individual HTTP transaction.
So if the site fakebank.example tries to do a WebAuthn validation for realbank.example it just plain doesn't work.
Next, for a Security Key or similar FIDO1 device, where you can enroll an unlimited number of sites on a single authenticator since they aren't actually stored on the authenticator - the keys used are encrypted with that FQDN. So if bad guys stole your real authentication database enties at Real Bank (maybe from a backup) they not only can't use them, they can't even play them back to you and have you use them - they only work at all on the real site they were for, they're just random garbage on any other site.
This relies on a two encryption technologies. 1. Public Key Signatures (mostly using elliptic curves but that isn't essential). I can pick two related numbers, tell you one, and then in future you can challenge me to prove I know the other one on different occasions, and you'll know I do even though you don't learn the number. Your Security Key can prove to GitHub that it is still the same Security Key that visited before, despite GitHub not knowing which one that is.
2. AEAD Authenticated Encryption. Modern symmetric encryption not only keeps your data confidential, it can also simultaneously authenticate it, your Security Key knows when given back an encrypted "ID" that it's a real one it issued to this web site, because random IDs will fail the authentication step.
Either of these tricks would arguably achieve our basic security goals, but they are both adding further strengths to the system, so why not have both.
[Edited to clarify some details]
https://en.wikipedia.org/wiki/SiteKey
WebAuthn. The article author dismisses it as basically too inconvenient (they apparently keep their Security Key somewhere out of reach and they struggle to remember the complicated user interaction of... pressing a button)
But WebAuthn is completely effective against phishing.
The closest to plausible attacks are: The bad guys take over the target servers (no reason to phish you); The bad guys persuade you to physically send them your authentication device (truly not everybody can be helped...); The bad guys persuade you to install software under their control on a general purpose PC (this won't work on a Phone) and then you follow their bad instructions to "use" your authenticator with their software to get them in.
Mutually authenticated TLS is in principle viable, and I have used it in machine-to-machine systems, but the UX is atrocious and it has grave privacy problems.
Um... no?
There are loads of copycat websites which appear in the top slot - especially for government site. https://www.which.co.uk/consumer-rights/advice/how-to-spot-a...
It's particularly prevalent in the UK, where you see companies proxying legitimate services and charging premium rate for phone calls - https://www.theguardian.com/money/2017/feb/04/beware-call-co...
I got 3 results on the screen
CanadianTravel - ETA Ad·www.canadaonlineapplication.org/
CanadianTravel - ETA Ad·www.canadatravelvisa.com/
CanadaETA - for UK citiziens - canadian-etavisas.com Ad·www.canadian-etavisas.com/
Which all look the same, and seem to charge $99 for the 'service' of filling in a form the Canadian government charges $7 for.
After that there is a wikipage for the Spanish terrorist group, two more wiki pages, then finally
The official site: Electronic Travel Authorization (eTA): How to apply - Canada.ca
Searching google for "Canada ETA" gives the above 3 adverts and also a link to https://www.etatocanada.com/ which charges £69 for the service.
These is just competing businesses / orgs vying for your custom, where one org (the govt) is charging $0, so you should totally use them, but won't if you're foolish.
Regardless, one tiny example of all google results (goverment form services) is... the vast minority of google search results. It is certainly not "invariably" a scam.
Here's an example:
[change name deed poll]
https://www.google.co.uk/search?sxsrf=ALeKk00J9KQR_SH1ZlvHgi...
For me the top four links are clearly marked ads. (Although some people may miss that [ad] marker). After the ads there are two links to the proper gov.uk website. Then there's a link to a commercial site called "Deed Poll Office", who charge for a services that's free.
In the past that TheDeedPollOffice link ranked higher.
Similar things used to happen for passports and tax self assessment.
Apparently they aren't so enforced.
Good thing that Google is still going after you if your website has nudity on it it, however. — 'tis very important.
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.
Realistically, you're probably not going to catch a mugger. Otherwise robberies like that wouldn't occur. Snatching a laptop with a key physically plugged in it is probably easier than snatching a laptop and a separate phone.
Regardless of my opinions on tech, if you think being mugged is "user error" then may I suggest spending a couple of days volunteering for a local Victim Support charity.
Edit: your comment also gave me an idea. Perhaps there should be a phone-based service that you can dial that locks out your account for a predetermined time period? Or it could even be tied to someone else that you can trust.
Your take is just not my experience at all. Tapping a blinking light it is much easier than fussing with a 2FA app and works when someone's phone is dead. Yubikeys in particular are near indestructible. They even work after you soak them in acetone overnight and melt the plastic off. I tried.
When it says "plug in your device" you plug it in. When it says tap you tap.
Also the mugger comment is not part of a typical threat profile. Yubikeys and similar devices are meant to protect you from remote attackers which is the class of attack 99.9999% of people need to defend against.
If a mugger points a gun at you, no form of 2FA is going to save you.
Also my Yubikey has a pin enabled and fingerprint enabled WebAuthn devices exist. I have several. If you are carrying things so valuable you are worried about being mugged, you can probably afford a higher end model with a fingerprint or pin.
Edit: yes I know random muggings happen, but a hit and run mugger that knows what a Yubikey is and already has your password is a hiiiiighly targeted attack. -That- pretty much never happens unless you are walking around with a $1,000,000 in Bitcoin in which case it has happened a total of 5 times that are public.
https://xkcd.com/538/
Two (three?) jobs back I had to set a bunch of people up on one time passcodes. Those seem pretty easy right? Still had to go there in person and show them.
Serious question; never understood how that works.
You either have other 2FA devices or backup codes.
Then there are those where you can register another 2nd factor, e.g. another Fido-Key, SMS-Codes or recovery email. Those might be better or might be worse, depending on the method and circumstances. E.g. SMS is vulnerable to all kinds of SIM-Cloning and redirection stuff, email is vulnerable to whatever your email might be vulnerable to.
The only thing I would accept as really idiot-proof and secure is "go someplace, show a government-issued hard-to-fake ID" (like a passport, not your drivers license...) like banks do. But that only works with physically present businesses and accounts that are strictly tied to one person. And even there, "Joe Smith" might impersonate "Joe Smith"...
If I somehow manage to lose both, I assume I’ll have to talk to a customer support rep or something.
However, a good solution for this issue is finally in the works: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
(1) Store their backup key in a more convenient, but less secure location (likely their home), putting them at risk of losing both the primary and backup key to the same event.
(2) Enroll only their primary key when an account is created, putting them at risk of locking themself out if they forget to add the backup at some point.
(3) Only use security keys for the highest value accounts, which tend to be a small enough number that you have a chance of actually remembering to add the backup key every time you set one up.
Of these, #3 is the only one that doesn't pose what I consider an unacceptable risk of lockout to the average person, so that's what I recommend.
The location doesn't need to be "secure" in the military sense of the term. Mainly you want it "secure" in the sense that if you lose the one key, you won't have lost the other key at the same time.
In the end, the two keys are equivalent from a risk profile if they are compromised, and for most people, the one they carry with them is going to be the weak link in the chain, so additional security on the other key isn't really accomplishing much.
In truth, if your home isn't secured, there's enough holes in most people's online security that someone in your home could find a way to compromise much of your online security (and from there, most of the rest).
Just keeping the other key tucked away in a drawer has some risk, but is pretty decent for most people. Keeping it locked in a fireproof safe in their home along with other important documents/keys/bits is a better choice and not terribly inconvenient.
If you want to be more thorough, you can always have a third key that you keep locked away in a bank vault, and you do "wing it" with just two keys for a period of time on new accounts.
What you don't want to do is "wing it" with one key (though AWS seems to think that's the way to do things). That can lead to disaster. What you also don't want to do is only use it for a subset of your accounts, because in practice most people are terrible at risk compartmentalization, so invariably a compromise of some of your accounts quickly becomes a compromise in all of them.
In my experience #1 is the right way for most people to go. There are disaster scenarios where you lose both keys, but usually that's a disaster severe enough that recovering your online access is the least of your worries, and it does a great job of mitigating the much larger risk of mismanaging the security of accounts that aren't secured with the key.
I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened.
And home isn't really convenient enough for many people: I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2.
You might care, but most people would have bigger problems at that point.
> I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
Yes, that's the use case where they are working to extend the protocol for using backup keys: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...
Again, most people aren't on the road a lot, and most of those that do already follow so many other bad security practices when they do so that creating new accounts in that context will already be fraught with peril regardless of the mechanism you use... and they'd probably be increasing their exposure if they used a password manager. I'd advise them to not do it, or to create a temporary account using some low-security, low-tech compartmentalized mechanism (like writing the passwords on a piece of paper ;-) and then delete the whole thing and create a new one from scratch when they get home, because that's probably less likely to be a problem. ;-)
"For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2."
I do use a YubiKey secured password manager for services that do not currently support U2F/Webauthn, so I agree that is really the only practical solution for certain cases. There's an in between space where you can use the SmartCard protocol or hardware based OTP, but... My observation has been that for "most people" the non Webauthn cases are a) not necessary and b) actually far more difficult for them to manage, leading to them simply not using the password manager for a lot of cases.
It turns out the typical person's needs are surprisingly limited, but the risk is enormous as is the number of "pathways to failure".
- you can still have TOTP enabled on the site as a backup 2FA method - you can configure multiple yubi keys for a single site - so I have one on my keychain that does NFC + USB-C for my MBP, and another “Nano” key that is left in my home imac - they are both registered with most of the sites I’ve configured
If my keychain is lost/stolen then I can still login from home or with my TOTP code as a fallback.
Please try being less condescending.
Losing the keys, due to whatever reason, means losing one factor. If the user loses the key, the "mugger" still needs to get the users' passwords.
2FA = something you know + something you own. Having one factor compromised should not compromise your accounts if the service you are using is configured correctly.
That's not exactly correct. Another factor is something you are, such as a fingerprint or eye. There are three classes of factors from which drawing any two is called 2FA.
There is also a 1.5 factor auth, used for example by many banks, in which there is a server challenge for the very vulnerability stated in the article.
https://www.yubico.com/solutions/passwordless/
The "I left my keys in my coat" problem you have seems like it has a pretty obvious solution: don't keep your YubiKey on your key chain. Do you have a wallet or cell phone that you carry with you at all times? Put it in the wallet or cell phone case.
Also, if a user can't learn how to operate a Yubikey after 10 minutes I don't think there is anything that can keep them safe online.
Also, the use of a PIN or fingerprint[1] to authenticate the yubikey itself and not sent over the network, mitigates the stolen key scenario. [2]
[1] https://www.yubico.com/blog/getting-a-biometric-security-key... [2] https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Gu...
This adds some convenience, though it also does add some risks e.g. in case of breach you can't tell which token was misused, you can't invalidate a lost key without invalidating others at the same time.
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.
Apple, Microsoft, and Android all support WebAuth (https://blog.mozilla.org/security/2019/03/19/passwordless-we..., https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-..., https://docs.microsoft.com/en-us/windows/security/identity-p..., https://developers.google.com/identity/fido/android/native-a...), so most (??) users are in fact covered.
eBay, for example, offers a passwordless experience using WebAuthn--so it can be done, even on a major consumer site.
The problem is really that until relying parties can trust that
1. Platforms will backup and restore key material from authenticators 2. Users will figure out how to use those backups (including if they e.g. switch from Mac to Windows)
they will have to provide some fallback. (Realistically, that means "for the foreseeable future.")
This relegates WebAuthn, unfortunately, to a "neat trick"--eBay's "passwordless option"--and not a security guarantee. (Phishers can always downgrade the user to passwords or similar.)
What's needed in the interregnum is probably a way to make that fallback option more secure by, at minimum, conveying to users that it's not _normal_--so that phishing attempts targeting that phishable backup are less likely to succeed.
Unfortunately this requires a lot of good UX design and unilateral action on part of the relying parties, which I think is tough.
TOTP and U2F actually has achieved pretty wide adoption, so I have hopes for WebAuthn.
[0] https://krypt.co
I do think (as I said elsewhere here) that ultimately people will adopt WebAuthn via their browser/OS vendor. Support is widespread! But for relying parties, there are still challenges to solve.
Sounds great, except one of the "ends" is likely the Secure Enclave (iOS) or Keystore (Android), over which the user has basically no control. So while the architecture might require "zero trust" of Krypt.co, it still requires complete trust of Apple or Google.
Perhaps completely trusting one of those companies is already the reality for nearly everyone, in terms of using a mobile device to access online data, but hopefully WebAuthn-supporting sites don't put extra restrictions on the devices you can use, via the "feature" of attestation:
https://www.imperialviolet.org/2019/01/01/zkattestation.html
Also, a lot of people who use Krypton don't know that SSH keys actually don't use the secure enclave because it doesn't support rsa or ed25519: https://github.com/kryptco/krypton-ios/issues/73#issuecommen...
Vanguard, for example, only trusts Yubico keys, and it's a pain in the ass.
That said, your complaint about Secure Enclave/Keystore trust doesn't make sense to me. Is there an architecture with on-device authenticators where you don't have to trust the device manufacturer? The use of SE/Keystore is a red herring here, no?
I was trying to draw a distinction between the OS (which could in principal be built from a trusted set of source code) and the firmware controlling the tamper-proof SE/Keystore.
In the case where the SE/Keystore is controlled by something like the Intel Management Engine, that distinction might be meaningful, but you're probably right that in general if you don't trust the device manufacturer then it doesn't matter how the SE/Keystore is implemented or managed.
Moreover, I suppose if you trust the OS to be doing what it's supposed to, the only things a malicious SE/Keystore can do are cause a denial of service or fail to keep your secrets (in the worst case by broadcasting them with a hidden antenna).
I mean, in the extreme, yeah, malicious hardware can exfiltrate secrets. A hidden antenna, as you say—or more subtle attacks (e.g. https://dl.acm.org/doi/10.5555/1267336.1267341, though this would require more than just the Secure Enclave to be malicious).
But yeah, I think for the ordinary consumer this is not a useful distinction. For vendors who are thinking about supply chain attacks, for sure this is a real consideration.
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...
Should I not have?
The "problem" is the expensive Yubikeys that you were whining about has lots of extra functionality that has nothing to do with U2F, and that's what the extra applications are all about.
I happen to use a Yubikey because I want that extra functionality, including using it to secure the keys I use for ssh and for digitally signing git tags so I can securely push git pull requests. But that's because I'm a developer, and it's why I'm happy to purchase multiple Yubikeys (one for my desktop, one for laptop, backups including one that is on a keychain, etc.) Perhaps you were reading web sites that was giving advice for developers as opposed to for consumers?
Whereas if you have RSA keys on the "full fat" Yubikey, they can be used regardless.
> 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.
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.
Looking at Amazon UK - https://amzn.to/3oWGYe4 - the cheapest appears to be about £30. Unless I want to risk my security to some no-name brand with zero customer support.
When I got my YubiKey, it told me I had to download an Android app to make it work. So, perhaps better documentation is needed?
I'm sorry you didn't like my post, I'll try to do better in future.
https://www.kickstarter.com/projects/conorpatrick/solo-the-f...
https://u2fzero.com/
I have a few U2F Zeros and they have been working fine for years. These are simple devices. You don't need to overpay for them.
Edit: Conor was building the U2F Zero tokens for $2.26 USD per unit. Read more here:
https://www.conorpp.com/u2f-zero-year-in-review/
In answer to the expense question, two Solo keys appear to set you back 38 quid at the current exchange rate. I don't know how they compare with HYPERFIDO, which I don't think I'd come across before.
From an economic perspective, unfortunately, it's really hard to focus on reducing the cost, there's simply no incentive.
First, consider that the biggest cost in the customer getting a security key is basically shipping + packaging. Imagine a key that costs <$3... even packaging with a polybag + printed label + padded envelop gets to a cost that has a significant % of the production cost.
Next, it's features. To stay on par with competition, people expect the same features (see, e.g., openpgp mentioned above - the code currently doesn't fit in the stm32l4 flash), both firmware and hardware. As a result we have to look at the latest & greatest micro, but of course that alone has a significant cost.
And finally, there's the overall viability. We all know that open source projects die without a business model. The numbers in the U2FZero review simply don't add up, that was clearly unsustainable and that's why we made SoloKeys. A business has expenses other than manufacturing and if you don't account for that, the business dies together with your dream project.
Anyway, thank you both (and all others) for the great support. One step at a time, we'll get to a stronger and eventually also cheaper product!
Integrated in to the laptop it would be great, like an Apple Watch allows https://support.apple.com/guide/imac/unlock-and-approve-with...
* https://solokeys.com/collections/all/products/somu-tiny-secu...
The stm32 used in v1 was 3x3mm, while the new nxp lpc55s6x used in v2 is 5x5mm. Plus we added 2mb of flash, though it's optional.
If anyone wants to try to packing the components into a somu v2, that'd be a nice addition to the *omu family [1] and we'd be more than happy to help with manufacturing. Same for a somu for usb-c.
[1] https://tomu.im
It is sad that with PGP being so horribly broken, it still casts its shadow over security products.
PGP should have been dead and buried eons ago.
How is ssh with a PGP key horribly broken? There's no shadow over Solo/Somu from where I'm standing.
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
[0]: https://www.amazon.co.uk/HYPERFIDO-MINI-FIDO2-HOTP-Security/...
[1]: https://www.hypersecu.com/products/hyperfido
If I had a corporate budget to spend maybe I'd order trays of Yubico Security Keys or Google's Feitian rebrand. But I just wanted to have more than one vendor so I have this product (well not this one, but it's the same product under different branding) and it works fine.
To give future security devices along the same vain a better chance at gaining popularity and being widely adopted (which will hopefully bringing us a more stable, less stressful society), the designs of these new devices must solve or workaround the issues the author describes.
It’s really annoying when individuals such as yourself respond so very negatively and unconstructively while others are trying to discuss the issues with existing designs — an act necessary for us (collectively) to develop new designs.
The author may not provide strong evidence for their claims, but neither do you provide strong evidence (or extensive reasoning) for yours. The net gain here is negligible, expect for showing that contrary opinions exist, but that’s not particularly helpful as for every opinion held it is inevitable that someone holds the polar opposite.
I’m not a moderator, but I ask you to please try to better further the discussion with future comments.
Nobody wants to re-setup every site ever because they lost their laptop that they kept it plugged into, so they won't. either this means using their backup until they lose it without even revoking the original and then swearing off the entire concept while telling all their friends to do the same, or just not using hardware tokens after the first lost of keys.
Also the "back up code" they will also get, guess where thats going! save as -> downloads or print2pdf -> downloads.
When it comes to personal account security by end users, hardware tokens will never take off, and this is why they get so much hate.
There is a real problem here that really needs to be really solved, wrt to end users and phishing/hack resistant credentials, and as long as we legitimize the lie that yubikey solves it, we gimp progress towards actually solving it.
There are other solutions. Being able to make one key a proxy for another is one. That allows you to keep your master identity in a bank vault, and then use it to "sign" the one you keep on you during the day. Should you lose your daily driver, just sign another one. This still suffers from the "one true name" problem though - if someone steals that bank vault ID, you're gone.
Another approach is servers allowing a client to register multiple ID's, and later delete them. Since there are multiple ID's, there isn't one true name any more. If one is lost you cancel it, and replace it with another. The approach is already built into the FIDO2 protocol, so they've already thought about your concerns and solved them, and IMHO solved them in a better way than you propose.
A more robust approach still would be a combination of the idea above: FIDO2 multiple ID's solution, plus proxies. One key could then provide multiple ID's to every server you log into, signed by different masters that are stored in different places. Keys can't be copied, but a lost key can be replaced by signing it with the master. A compromised master can be have all it's ID's dropped by logging in with an ID proxying other master. You could think of it as RAID for 2FA's.
Yes, clonable tokens. Exactly.
When people ask for clonable tokens. This is an acceptable solution.
(But skip the bank vault. This is for avg Joe, not Jeff bezos. The closest safe will do)
A modern iPhone or high-end Android phone already does WebAuthn secured with your fingerprint or (on some iPhone models) facial recognition, like your lock screen or contactless payments.
I honestly think Yubikey type devices' largest problems are - 1. Marketing. People simply do not know they exist or how they work (simple or not). 2. Support - Many websites do not support Webauthn yet. We really need developers and businesses to consider this a priority.
I have bought some keys for my family members and they love them once I demonstrate how they work.
The expense is that the security world hasn't converged on anything remotely approaching a single standard. So, a key has to support ... PGP, OpenSSH, FIDO, FIDO2, U2F ...
For example, you couldn't use some of the older YubiKeys with AWS because AWS only supported time-based TOTP.
That's a LOT of software work, and you can't be "Startup Sloppy" with your code or someone will break it.
Please don't go there. You're both adding to the discussion, maybe some strong words here and there, but this turn of phrase you used is a huge conversation destroyer.
As for the U2F devices, the idea of just leaving them in, the small yubikeys and all that, seem to just be a bad idea from the get-go.
I leave my YubiKey plugged in all the time. It's basically a permanent part of the computer.
Even if your device is stolen 1) it's unlikely by a technically savvy bad actor (and if you're at risk, you probably have had special data security training anyway) 2) you're still only stealing one factor. Your device should also be encrypted with a password which would protect any passwords [managers] on the device
does anyone know if its posible to reuse these fips pki tokens? they are cheap enough.....
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.
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.
A client could by default show "unverified" and use spf+dkim to get to verified. The "unverified" could be signal enough to enable spidey senseThe 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.
How can you be completely confident that this isn't an attacker?
In almost all cases these were just about vanity (e.g. the university where I studied and had some of my first jobs renamed itself and gave every web site new URLs, purely out of vanity, at considerable cost with no benefit) and so when they discover it can't be done technically they just give up and continue to use the old name for authentication, meaning your security posture is intact. In the few other cases you're now going to have to have a conversation with your users about why you broke everything and need to begin over. I sure hope the gain to your organisation was worth it.
Recently Ameritrade and Charles Schwab Corp. merged ...
This leaves a human to try to make deductions about whether githubverification.com is github.com which is something humans are terrible at, so game over.
If you have WebAuthn then your browser also takes responsibility for only letting you use your github.com credentials on github.com and not even bothering you with any other possibilities that you might think could be safe and are not. That's why WebAuthn prevents phishing.
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."
The page mocking the login page where you need to answer the 2FA will simply phish your 2FA then, after a little delay pretending there's some lag, would say "wrong code, please try again". Now the person enters a second 2FA (which, due to the delay, would be different than the first one).
As I've just commented in a top-level comment: I've seen sites using a 72 hours delay before any destructive change can be made, coupled with the sending of an email containing a link allowing to unilaterally prevent the change.
I've also seen sites using two 2FA (TOTP style), one for login, one for any setup/destructive change. And there are sites using both techniques.
It's not 100% foolproof but it's better than "one 2FA phished and it's game over".
The author is pointing out that they will steal both the password and your 2FA token.
2FA (at least the simple OTP variants) don't protect against phishing, they just protect against sloppy phishing attempts.
In fact the phishing toolkits have been doing TOTP passthrough/relay for a few years now. For the attacker, it's a nice feature: victim could be using SMS, authenticator app or even an out-of-band delivered token book - they are all captured and passed along equally well.
U2F and FIDO2 with hardware keys are the only realistic safeguards. On the other hand, I do subscribe to the stated problem, because for most people they are a usability snag. The NFC variant has the potential to address this, though: instead of plugging a key in and touching the blinky button, you just wave your keyring next to the device. Too bad NFC readers are not universally available on phones, tablets or laptops.
That's assuming one used a different password for the email or mobile provider.
I don't use SMS, deprecated it 10 years ago in favor of e-mail, and would never use SMS for 2FA. I still have a virtual SMS number that forwards to my e-mail for the idiot sites that still insist on it.
For most people, SMS is hackable, tied to a single battery-powered device, easy to steal (after which for most people in the default phone configuration the SMS verification codes will happily pop-up on the lock screen without unlocking the phone), and hugely inconvenient if you are in front of a desktop computer all day and have to go find your phone (at home for example I pretty much never have my phone next to me). SMS also famously locks people out of their accounts when they go to another country and have to use a different SIM card. Also, if you have a giant desktop in front of you, it's ridiculous to not use that as your 2FA device. You should NEVER have to pick up a 6" handheld device for 2FA when you have a massive immobile, hard-to-steal device in front of you that in my case is also physically locked down to furniture.
Yubikeys and other U2F keys do exactly this.
The article is wrong about one thing:
"But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom."
No. My preferred way to use Yubikeys is to buy one for each immobile device (home/office desktops) that stays plugged in, and ONE mobile key that lives in my wallet. Register all keys with critical services. If any device gets stolen (highly unlikely for the immobile devices, the mobile device is the only one I need to worry about really), go home, log in with another key and remotely disable it.
My main gripe is websites that don't allow multiple Yubikeys. AWS is at the top of my hall of shame.
Unfortunately most of the sites I use do not have anything to do with them.
Really? How? Last time I tried to do this it turned out that apps/sites would not send to these virtual SMS numbers.
B. Find a different virtual SMS number. Try other countries as well. Sometimes it costs a small monthly fee but I don't want to give in to their idiotic game.
Not if it also steals the 2nd factor. My response would be more like "2FA is good but not for this problem." This problem is about going to the wrong site. The solution is to go only to the right site.
This is necessary as you would else wise be permanently be locked out if you lose your U2F key.
That is assuming you can't reset your U2F key using mail password recovery. But your mail being a single point of failure is something U2F normally tries to prevent.
Through I guess for not relevant services. I would still want U2F but allow mail recovery and maybe even U2F _only_ login (or FIDO login without PIN).
Given that people have different opinions about what is important I guess this should be an option for fallback recovery, maybe with some warning around it.
The "workaround" to have no fallback for U2F is to generate recovery keys and then not store them anywhere ;=). But I would not recommend this, except if they have a insecure mail based password/U2F recovery anyway.
Since when?
Sure, but isn't that the point? There's now a second thing they have to steal, and if they only get the first it's pretty worthless, especially if there's monitoring/alerting in place that prompts a password change and/or locks your accounts pre-emptively.
So, in case of phishing that's not the point. If you're actively logging in yourself a second factor doesn't prevent the attacker from gaining access.
In Webauthn/u2f the 2nd factor is a proof that is unique against the particular site. So stealing the 2nd factor is significantly more difficult since it requires compromise of the computer/endpoint used to access the site to pass the wrong site to the hardware token, or cloning the physical device which should be tamper resistant (but not totally unheard of to clone some devices).
Your statement is true for HOTP/TOTP based 2nd factor like google authenticator on a phone, although the stolen credentials shouldn't provide persistent access.
And password re-use is still a problem if every service isn't covered by Fido2, but we need to start somewhere.
Given a successful login and session, perhaps on some sites this is enough for passwords reassign via some backend (likely intended for mobile apps) API?
i.e. blame the victim. This generalizes to: the solution to user error is for the user not to make errors.
So no, that is not the solution.
No. That is never the real solution. At best it is a necessary evil, but generally resorting to this is a reflection of a failure of imagination.
The reverse authentication problem in particular is easily solved by the right UI design plus some improved infrastructure behind the scenes. Certificate pinning, for example, would help a lot. The hard part is not coming up with a solution, or even implementing it, but convincing everyone to adopt the solution because it doesn't help unless it is widely deployed.
Unless you have a 100% vendor controlled system, (more than Apple + ChromeOS combine) you have to rely on the user not breaking their own security.
- Your solution is not sufficiently great as to be self-evidently great.
- People (i.e. the victim) must be faulted (i.e. blamed) for their inability to be convinced of its inherent majesty.
- Given convincing's similarity and overlap both with educating and with training, you are having a failure of imagination. (Source: Your comment.)
There may be viable solutions that include still going to the wrong site, but I know for a fact that going to the wrong site does not happen if you go to the right site. It's a tautology just like your disingenuous Twitter-style reductionist accusatory re-interpretation of my comment suggests. Speaking of which, if you want to blame the victim, go right ahead (that was your idea), but I don't think the computer cares who gets blamed, unless and until it affects what gets typed in or clicked.
Mainly U2F incorporates the domain and (should) only work if an TLS connection with a valid certificate for given domain is used. Furthermore it uses a key exchange. This means:
- The attacker needs a valid certificate for the applications login domain, which wrt. web security is normally assumed to not be possible but tbh. might be possible in case of an state actor or similar.
- The attack needs to be live in the sense that password and 2FA auth needs to be directly forwarded to the attacked web-application and there it needs to trick any bot detection to make it believe it's not a bot. This also means even if they phish your authentication they only can use it once at the moment they phished you. But to e.g. then to disable U2F they often need to enter another password, so they need to phish you twice in a row, which is harder, but only slightly harder, tbh.
- Alternatively they might hack the service and get their hands on the private webcertificate and clients private key if the service doesn't use a HSM for that. But that is normally much harder and for many attacks unfeasible (and there is normally little reason to phish if you can hack a server that deeply).
The second half of the article goes into detail about the shortcomings of U2F (using "Yubikeys" as it's terminology)
So that leaves ease of setup and support. Since setup only has to be done once per site, and I only bother with important sites, that’s not a major deal for me either.
For either of those methods, stealing two SMS/TOTP codes isn't that much harder than stealing the first one - you just display a fake error saying that it failed, and try again.
For all but the most attentive folks - getting a "Whoops, try again" error when authenticating is probably going to be a semi-regular occurrence anyhow, so adding a fake one in there probably won't trigger any mental alarms.
All they have to do to achieve this is to use the phished credentials to immediately login with the original site, trigger 2FA and then show a field to capture it and pass along. Then capture all the cookies.
The best defense against phishing is to use a password manager that does domain matching.
In addition to that, now I noticed that in the blog post:
> I recommend the open source Bit Warden. A password manager stores your passwords. But it also stores the web address of site’s login page. If you visit githud, the password manager won’t prompt you to use the login details for github
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.
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.
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.
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.
Even so, I’ll expect financial institutions to have that.
Note: I’m not saying the above is a Cloudflare issue, perhaps someone at Visa was being stingy - I’m just saying it’s an issue and would be bad if that becomes the mainstream.
Wait what now?