Security Keys
imperialviolet.org
imperialviolet.org
I love the principle, but I can't use it with AWS, I can't use it with my bank, I can't use it with my domain registrar, and I can't use it with Office 365. That's 0/4 of the high priority targets for me.
Edit: If anyone from AWS is around, please consider this. Your organisation has made huge headway in the field of security, but the AWS console logon is a very high profile target.
https://lolware.net/2017/08/01/capturing-mfa-logons.html
Edit: I've always felt strongly about having things like the AWS logon connected to a dedicated and otherwise unused mailbox, it helps minimise the risk discussed here.
I used freeotp with my o365. :)
Do you check this mailbox frequently? If not, won't you miss important communication?
Banks are still a decade behind in almost every way. Can't help you there.
To apply some pressure, there are handy "public shaming" twitter-shortcuts.
Domain registrars are an odd one, because so rarely does one need to log in or do anything - but when you do it may be urgent.
I guess it works since it doesn't need anything else special and can easily work with web flows.
https://en.wikipedia.org/wiki/Transaction_authentication_num...
[1]: https://www.hsbc.co.uk/1/2/contact-and-support/security-cent...
I have RSA token device from Wells Fargo for example.
The problem with these is that I need a special device for every single account. There are two business accounts I have access to and I have to deal with two hardware devices.
It's frankly a bit disappointing, since storing secrets in their mobile app means that at the end of the day, when you do banking on your phone, you're really using only 1-factor authentication
Or they have a standardized API for accessing all accounts, and use your existing debit card’s security module to sign and authorize all messages you send via this API.
That’s FinTS, and every German bank supports it. Standardized, univerals, open, and secure.
Oh, and KMyMoney and GNUCash also have plugins to directly access it, and there’s even a taskbar widget for KDE to always show your account balance.
You can use Google Authenticator with TOTP with you AWS console. Or am I misunderstanding your comment?
It's not a hardware device obviously but its the same principle, just implemented in software.
The article I was responding to, was written regarding U2F keys, which is a different protocol, with protection for this scenario.
The YubiKey NEO-n (and I'll assume the more recent 4 Nano) are phenomenal if you can (semi-)permanently spare a USB-A port. The ability to generate TOTPs and FIDO tokens without having to dig out your keys is an amazing convenience.
Unfortunately I can't say the same for their 4C, which I'm using with the new USB-C-only MacBook Pro. The plastic it's made from begins cracking apart within a month of use, and completely disintegrates within three months, rendering the device inoperable. To their credit, Yubico has replaced my device twice so far, but how this made it past their quality control I have no idea.
I deeply hope they fix the plastic durability on this device, as well as offer a nano version with USB-C support that I can leave in my laptop permanently.
Or use subkeys most of the time and have master on dongle?
I don't think I've ever had any issues with any of them (there was a "bug" a few years back and they had to "re-issue" some keys) and I really don't have any big complaints other than they're a little expensive (but I keep buying them so apparently not too expensive), just a few minor things.
I've never actually used the U2F ones (browser usage is ~90% Chromium, ~10% Firefox, on Linux exclusively) but maybe I'll get to someday. The NEO and Nanos get used dozens of times a day as my SSH keys (GPG subkeys) are on them. They're also used for unlocking LUKS containers at boot (challenge/response, with a "passphrase"). I do wish it was easier to load (SSL/TLS) certificates on them -- and I wish they held more of them! -- but I have a bunch of physical ("real") smart cards so I just use those instead.
Ideally, I'd be able to put certificates on them and use them to authenticate (Open)VPN clients on both Linux and Windows. That might even be possible today but, if it is, it's likely way more complicated than it should be.
Oh, also I used the VIP and NEO at one point with LastPass and they worked great (but I switched from LastPass when LogMeIn bought them).
Have you tried logging into LastPass on your mobile device? It doesn't require the token - effectively bypassing the point of requiring a hardware token in the first place ..
What do you mean by "easier"? Yubico PIV manager is super simple to use. Of course you have to generate the certificate with OpenSSL yourself but that's part of the process. And the PIV certificates are automatically seen by OS. I'm using them in browser, git can be switched to use system certificate store effectively having hardware protected access to repos. SSH can also use them either via OpenSC or Putty CAC (depending on your OS). I've done that and it works, it's not much harder than the OpenPGP setup.
Is there any reason why a $3 A-to-C adapter wouldn't work for this?
Coolness factor? The openness of software and hardware is very important for a security device as this.
We should expect something so critical and simple to be easily auditable.
Yes it does! This meme is both widespread and incorrect. Security by obscurity is a great layer for defense in depth. The only time it's not sane is when it's used as the only method. But that's also like saying whitelisted input or parameterized queries don't work - they don't work on their own, but all things being equal you can have very secure systems that function in an opaque way while still getting strong assurances through formal audits.
> Nobody can analyze code they can't build and modify.
Essentially no one analyzes open source code regardless, unless they have a financial incentive. Even if you are one of the vanishingly small number of people who inspect the code for every FOSS tool you use, you are, with probability approaching 1, incapable of identifying all potential backdoors or critical security failures.
You need to balance the Platonic ideal of open software for audits with the fiscal reality that secure software is highly expensive and typically emerges as the product of well funded teams with significant expertise. This describes very few open source projects.
Use whatever tool is put out by the team with the most expertise and the least reason to do something untrustworthy (or alternatively: the most to lose). A backdoor can persist in open source tools just as easily as it can persist in proprietary ones, and teams which make open source tools are frequently smaller and underfunded for secure feature engineering when compared to teams which develop closed source tools.
It's a myth that they are always more secure, but my experience has been that they are generally more secure. I'd love it if we had some statistics behind this.
I would argue that foss tools have an inherent interest in being more secure, while closed-source tools have an inherent interest in being less secure.
Security is also about trust. I can't trust non-free software as a matter of principle---the developers, by keeping something proprietary, are hiding something from their users. The intent is irrelevant---"trade secrets" or not, the fact is there.
Back to code audits: a common rebuttal is that you can audit certain proprietary software through the signing of nondisclosure agreements. The trust then shifts to the auditor, performing an extremely complicated job (depending on the software). Nobody can verify their work, or even the integrity of the work.
Certain types of changes can be "audited" by chance in Free systems: malicious commits/patches to free software is an extremely risky operation because of the chance that you may be found out. You can set yourself up for plausible deniability, but that can hurt your reputation, and the reputation of the project.
Since trust is an important aspect of security, non-free software is by default less secure _to me_. It isn't even an option.
Just as easily? Citation needed. Especially when we are talking about a simple security device that can ship a tiny, well written, well documented codebase.
> teams which make open source tools are frequently smaller and underfunded for secure feature engineering when compared to teams which develop closed source tools
This is besides the point. The same code, developed by the same team, can be released, or simply made publicly auditable.
I like the idea of a physical token, but it would need to be more universally compatible, which seems difficult unless you go the route of one of those RSA tags with an LCD display on it. But there's no open standard for those, except for TOTP, and if you wanted hardware TOTP you'd need a separate dongle for every site. Inconvenient. (I wonder if you could make a TOTP dongle that can store multiple keys?)
I do use TOTP, but I use 1Password, which means my keys are not confined to a single device. I wonder how much less secure this makes them, but it's probably still better than not using 2FA at all.
However, the single TOTP hardware device for multiple sites that you postulate converges on the U2F design if you wrap the OTP in signatures so both sides know who they're talking to.
https://wiki.mozilla.org/Security/CryptoEngineering#Web_Auth... states that FF 56 or 57 should have native U2F support, and 57 or 58 would have it flipped on for everyone. Promising.
https://bugzilla.mozilla.org/show_bug.cgi?id=1065729 is still open, but has seen plenty of progress.
Even with current version (55), one would expect lot of the groundwork to be in place. And sure enough, searching for "u2f" in about:config brings up a nice triplet of security.webauth.u2f* keys.
> We are working on an additional smaller YubiKey form factor with a USB-C design akin to the YubiKey 4 Nano, but do not yet have a time frame for availability.
https://developers.google.com/identity/fido/android/native-a...
I see only:
> The API supports both NFC and BLE U2F devices.
https://developers.google.com/android/reference/com/google/a...
I suppose USB support might need integration on the operating system level, whereas NFC and BLE can be integrated through Play Services. It's a start.
Even though U2F is much more secure, it seems like the adoption is a bit slow, unlike TOTP which is broadly supported in my opinion.
However using TOTP with e.g. Google Authenticator makes it a pain when you lose/reset your phone, and it's harder to share, for example for administration of certain services at a company (say Heroku).
If I had a chance to buy a multi-key TOTP hardware device I could enable it on every service and then give the administrators one of the devices.
So yeah, ideally I'd prefer broader U2F support, but in the meantime I'd love a multi-key TOTP device, which I haven't been able to find unfortunately.
Closest thing I know about is the Protectimus Slim NFC [0], but I would to need to buy two of them for each service, which gets expensive and unwieldy very fast.
However I'd love to have a hardware device that I don't need an app to use. To load the keys and configure it I have no problem with, but to actually read the TOTP it would be great if I could just click a button and read a display instead of having to use extra infrastructure.
Kind of like my 2FA token for my bank, which just requires me to push a button and that's it.
Thanks for the tip though.
How could they fail silent? Bind to another URL? No, that's a functional failure.
Leak cryptographic material to an attacker? I guess not, unless the attacker controls the web browser, and then all bets are off.
I'm not a security expert, so take with heaps of salt, but I can't see much exposure here.
The point of U2F is to avoid trusting the system, including the browser. Otherwise, what's the point over using just a password manager?
The point is to combat phishing.
If you add a password manager to the mix, it keeps you safe in the event that only your password manager is compromised, unless you're storing your TOTP secrets in it.
(All of this applies to U2F too, of course.)
Having a hardware dongle is absolutely about preventing malware on the PC from making off with your key material. That's also why you usually have to press a button to complete the U2F flow.
Exceptions to that rule include sites that do things like what GitHub calls "sudo mode", where you have to confirm certain security-sensitive actions with another U2F confirmation. This would require more effort on the attacker's side, as they'd have to trick the victim into performing a U2F confirmation. More effort, but far from impossible: simply display a fake login prompt for the victim, but instead of logging in, perform whatever malicious action you want to perform. Session keys might also be less persistent (they're limited to something like 30 days on Gmail, for example), so that's another small advantage if the attacker wants to keep their access over long periods of time.
Still, for the vast majority of sites and threat models, hardware keys aren't a whole lot better. If it's easier to get adoption for soft keys, that might be a worthwhile trade-off. Natively supported TPM/SEP-backed keys would probably hit the security/UX sweet-spot.
I would hope there are specific requirements in the spec/standard WRT protecting the keys and such but I haven't checked to see if that's the case.
Yubico is, according to their website, working towards FIPS 140-2 validation for at least a few of their devices if that has any value to you (no idea about any of the others).
Right now, not too many providers support these auth protocols, even though they are more secure than current 2fa alternatives and provide a better user experience. The aren't widely supported because that costs development time and many of their customers don't have security keys.
Customers won't buy security keys because it's an added cost that isn't supported by many websites.
The author of the post briefly mentions SoftU2F at the bottom of the post, but it's important to recognize how significant SoftU2F is to the U2F ecosystem.
We're just now starting to see consumer hardware come with HSM's built in. Apple SEP, Intel SGX, etc. are examples of this. SoftU2F _will_ be able to leverage these consumer HSM's to do secure crypto operations - see the pull request at [0] about storing keys in the SEP. This will effectively put U2F and UAF capability into the hands of your average consumer with no additional cost. Things can be just _built-in_, which is what it'll take to start seeing increased protocol adoption across browsers and service providers.
I'm stoked about the future of security keys and the associated protocols. Both external keys and HSM's built directly into consumer hardware.
The hard part is that there's another more subtle chicken and egg problem when it comes to software implementations and consumer HSM. Google/Apple/Microsoft will likely only really push forward native implementations when there is enough market share for consumer hardware having HSM's built in to make it worth it with feasible fallback options.
I'm not very familiar with how TPMs work but don't they already give you this? TPMs are on most computers already, except for Apple-branded ones.
See Yubico documentation for details: https://developers.yubico.com/U2F/Protocol_details/Key_gener...
SGX doesn't provide any real advantage. For example Chrome team was evaluating storing Token Binding keys in SGX but eventually ended in using software store due to their (quite reasonable) threat model.
For this, it's imperative that there's either another way to get access or that I associate a 2nd security key with the service I need access to. Of course, it's possible that the 2nd key breaks or is lost.
At least with hard drives, it's common for two hard drives manufactures around the same time to fail around the same time, so I'd be concerned with the possibility of that happening with the two security keys as well.
Ftfy
You might argue "well why bother with U2F, if you are going to set up TOTP anyway", to which I respond that using U2F is still a net win, because for the times you use U2F, you are safe from phishing attacks.
That in an emergency situation you have to use TOTP, and thus be vigilant that you aren't being phished, does not negate the benefits from having used U2F previously.
I can see that by enabling TOTP as a second-factor, it increases your attack surface. That is, you now have to care about whether your TOTP secret has been leaked. I consider this cost to be small, compared to the benefit of being able to fallback to TOTP. Others may decide this tradeoff isn't worth it.
This stops the proxy attack you describe getting a session key, but not getting your password. Of course, the password alone is insufficient.
In what sense are the keys linked? I'm assuming it requires the browser to pass the actual domain requesting the auth?
Your original description is a bit ambiguous: were you referring to a case where the actual domain was being successfully man-in-the-middle'd with a valid TLS certificate? That's not something U2F aims to solve (and not something that people generally refer to as phishing).
Edit: Small correction: U2F makes use of TLS ChannelIDs, which, if I understand correctly, would help in that scenario (MitM with a trusted-but-attacker-controlled certificate on the "real" origin). I'm not sure if anyone other than Google makes use of this yet, as it requires a new TLS extension on the server.
What's 2-nd factor password? Well, basically yubikey stores just long text string, and another, shorter string, is stored in my brain. When i login i enter short string, then press yubikey.
To steal my data you don't only need to steal yubikey but also get my part of the password from me.
[-But it so happens that the-] Of course in OTP mode, the YubiKey protocol protects against replay attacks by using a counter on the YubiKey. This (authenticated) counter value is included in the messages that are exchanged during the authentication - and hence any replays can be detected/ignored as the counter value will be less than or equal to the last received counter value.
Edit (deletions marked with [- -]): I had no idea people used modes other than OTP with their YubiKey...
Ex: right now - myPass<boop the yubikey><long password from yubikey followed by linefeed>
with otp - myPass<boop><hashed and signed one time password that no nothing about myPass>
I had a blog post some time ago - https://varamashvili.blogspot.com/2012/09/using-yubikey-with...
I should note that currently i'm thinking to migrate to OTP and use brain-string (password that i remember) for filevault and mac login. I will try using OTP for sudo, maybe keychain, will try to add gpg subkey there and see how it'll go.
I've used it way before there were good solutions for mac. And my main concen was to unlock my machine.
I've would've ditched it if only filevault could be unlocked with it :(
I may ditch this in favor of one-time passwords any way - support on mac is pretty good now and filevault will be secured with 9 symbols string.
Considering Feitian ePass FIDO security key's pretty good quality (injection molded and sealed key), great price point (with the special, it was almost half the price of lowest Yubico keys yet still NFC capable), it's gonna be my next go-to choice for future U2F keys.
The last time I tried to use U2F on Firefox, I had install an extension, and I had to change my user agent string to Chrome to even be offered U2F on most sites, including my employer's DUO based auth system.
This caused no end of headaches, because my employer would ... helpfully... send me nagging email about using an out-of-date browser, due to the user agent strings specifying some older version of Chrome.
Someone wrote an add-on, but it doesn't work in nightly.
https://addons.mozilla.org/en-US/firefox/addon/u2f-support-a...
I fear that even once Firefox has native U2F support, websites may still be checking for a Chrome agent string.
Despite being a little fat and ugly, it seems like the best of the devices to me (I'll be ordering one soon).
Very surprised about them causing reboots (I assume this means hard resets?) on the reviewer's computer.
Users enter their credentials and game over.
The important point is that users are deceived, but not the web browser. The browser knows perfectly well, that the URL is amazon.com.something.com, the problem is that it has no expectation which URL is the one the user has in mind.
With a U2F key it's the same scenario. But the browser tells the key "this is for amazon.com.something.com" the key incorporates that into it's cryptographic input, so it's "bound" to that URL.
Later the bad guy presents the key's output to amazon.com, and now the server has an expectation that's not fulfilled: "I'm sorry, that's not for me".
Also, the scheme you describe requires the user to trust the web browser. But, if the web browser is, say, on a public computer, it can't necessarily be trusted.
b) Right. Perfect is the enemy of good.
They would also have to get a publicly-trusted TLS certificate for that domain. U2F is HTTPS-only, at least on Chrome. If the attacker can do that, you have bigger problems.
> Also, the scheme you describe requires the user to trust the web browser. But, if the web browser is, say, on a public computer, it can't necessarily be trusted.
No one has really solved secure authentication on a compromised system. I dare say it's not a problem that can be solved.
Basically, if the site sends a random nonce to sign, I don't see how you can reuse things. The most you can do is have the browser sneakily and remotely authenticate you on your computer (if you're the attacker), but the user still needs to press the button.
It's not impossible to get a phishing site on the same domain as the real site, but that requires a site security error, or active mitm with a improper cert. A much higher bar than simply tricking users.