Getting Started with Security Keys(paulstamatiou.com)
paulstamatiou.com
Getting Started with Security Keys
https://paulstamatiou.com/getting-started-with-security-keys/
103 comments
I would put greater emphasis on not locking yourself out, since that's the most likely threat for many people. Losing your phone (or having it die on you) is common and you should assume you'll do it sooner or later. Print out backup codes and store them somewhere safe that you won't forget before enabling two-factor authentication that depends on you having your phone or other device that can break.
This. This is why I am happy to use security keys at work (if I lose all of them, there is a way to be issued new ones using a manual identity verification method plus another person's security keys ) but I've been too nervous to put them on my own account.
Also, if you are adding support for security keys in your app, please make sure there are ways to add and remove multiple keys (so I can have backups, and per-device keys).
Also, if you are adding support for security keys in your app, please make sure there are ways to add and remove multiple keys (so I can have backups, and per-device keys).
Or you upgrade your phone, or wipe your phone for some reason, and forget that your OTP codes don't transfer over.
This is one reason I love OTP codes stored in 1Password. That was until I read a post here which convinced me that this approach is a total waste of time as I no longer truly have '2FA'. I have 1FA, and that is 1Password.
This is one reason I love OTP codes stored in 1Password. That was until I read a post here which convinced me that this approach is a total waste of time as I no longer truly have '2FA'. I have 1FA, and that is 1Password.
You could use Yubikey with Yubico Authenticator - the secret key is stored in the Yubikey. I did this because phone upgrades were a PITA, as you alluded. If you wanted you could have two Yubikeys (I have my second one in a safe deposit box).
Having 2FA in 1Password is still strictly stronger than 1FA. The a leaked OTP token stays valid for about 60 seconds. Your leaked password may never change.
What is the threat model where an attacker gains access to your 1password vault in a way that gives them only a single OTP code and your password, and not the underlying symmetric TOTP key?
- using your password on a compromised desktop
- attacker looking over your shoulder as you enter your password
- Company mitm breaks open ssl encryption and reveals your password.
Obviously, if someone breaks into your 1Password it’s game over.
- attacker looking over your shoulder as you enter your password
- Company mitm breaks open ssl encryption and reveals your password.
Obviously, if someone breaks into your 1Password it’s game over.
All of these aren’t related to your 1password vault. They all occur even if you’re using your phone as a totp device.
I think the point wasn't that 1password TOTP is more secure than separate TOTP device, probably even less secure than typical alternatives, but it is present, convenient, automatically backed up and safer than just a password.
Terminology clarification: The seed driving TOTP is a shared secret but NOT a symmetric key.
[deleted]
Not locking yourself out and not letting a company lock you out. When the article started talking about using Google’s registrar, advanced account protection, and Google Fi, I started wondering whether it’s more likely these days to get specifically targeted for an online attack or for Google to randomly decide to lock your account forever.
Including printable backup codes, most services supporting FIDO U2F or WebAuthn support tying multiple security keys to your account. Many of these authenticator devices are pretty cheap these days, its not insane to have a few of them. Have one on your keychain, another in a desk drawer, etc.
I was super surprised to learn AWS will only allow you to register a single FIDO token - the inherent lockout risk pushed me back to using OTP with the seed stored in multiple Yubikeys.
This is actually against the WebAuthn spec (https://www.w3.org/TR/webauthn-1/#credential-loss-key-mobili...). Hope they fix it soon.
Yea it's very annoying. I ended up making multiple IAM users--one for each of my security keys.
It's bad that many sites require you to set up TOTP (single seed) before they allow you to set up U2F (multiple keys), so you have the problem of having to take care of the TOTP seed anyway even if you have multiple U2F keys. (It's even worse when sites forget the U2F keys when you regenerate the TOTP seed.)
Exactly this. And that's why AWS's U2F feature is basically useless. They should've allowed to add multiple keys simultaneously.
My guess is that their thinking is that you should use your root account to make an admin user via IAM, and the admin user should use IAM to make users for your people who will actually manage your services. Their advice [0]:
> We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
Here are those things that you need to use root for [1].
If you use U2F on your regular users and someone loses their key, they can ask the admin to temporarily disable 2FA on their user account, or switch them to TOTP, until they can get a new U2F key set up.
If you use U2F on your admin user and lose the key and there is only one admin account, I would guess that it is similar to the user account case, except you need to have the root account deal with it.
That only leaves the question of how to deal with the root account. If you enabled U2F and lose your key, Amazon provides a way in using email or phone instead [2].
[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-use...
[1] https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that...
[2] https://aws.amazon.com/blogs/security/reset-your-aws-root-ac...
> We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
Here are those things that you need to use root for [1].
If you use U2F on your regular users and someone loses their key, they can ask the admin to temporarily disable 2FA on their user account, or switch them to TOTP, until they can get a new U2F key set up.
If you use U2F on your admin user and lose the key and there is only one admin account, I would guess that it is similar to the user account case, except you need to have the root account deal with it.
That only leaves the question of how to deal with the root account. If you enabled U2F and lose your key, Amazon provides a way in using email or phone instead [2].
[1] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-use...
[1] https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that...
[2] https://aws.amazon.com/blogs/security/reset-your-aws-root-ac...
Yes, an interesting exercise I did once was to actually draw the dependency graph of auth material (both passwords and 2FA tokens/devices) and accounts, with edges where one thing can bootstrap another. E.g., with my password database and master passphrase, I have a password; with that and my OTP backup, I can recover my email account; with that, I can reset other account X; etc.
I now make sure I have sufficient backups of the roots in that graph so that losing hardware doesn't lock me out. It's easy to lose track of!
I now make sure I have sufficient backups of the roots in that graph so that losing hardware doesn't lock me out. It's easy to lose track of!
The requirement I've set for myself is that I should not lose access to my accounts of data if I lose some or all of my hardware, be it to mechanical failure, theft or me losing my phone somewhere.
I don't think there's any way around having a safe physical location to store backup codes / secrets on paper.
I don't think there's any way around having a safe physical location to store backup codes / secrets on paper.
Codes on paper are still bits of hardware that can be lost, stolen, or destroyed.
I'm less likely to lose a piece of paper in a safe than I am to lose the phone in my pocket
This is what SSI has done well.
See https://sovrin.org/wp-content/uploads/2019/03/What-if-someon...
See https://sovrin.org/wp-content/uploads/2019/03/What-if-someon...
Yeah, scenario that I still need to solve is:
Go on vacation, loose your phone and security key (along with any written passwords) - by robbery, theft, customs or accident.
You'd still need to be able to access your email etc. or else your experience is going to be a hundred times worse.
What you really want is optional 2FA. You have a regular (unique) password but you never use it unless there is an emergency.
Now you just must make sure to remember that password that you never use, even when in distress... Not that straightforward either.
Also upon use any "smart" site would flag it for unusual activity and lock you out until you can verify it.
I guess I'm stuck with passwords.
Go on vacation, loose your phone and security key (along with any written passwords) - by robbery, theft, customs or accident.
You'd still need to be able to access your email etc. or else your experience is going to be a hundred times worse.
What you really want is optional 2FA. You have a regular (unique) password but you never use it unless there is an emergency.
Now you just must make sure to remember that password that you never use, even when in distress... Not that straightforward either.
Also upon use any "smart" site would flag it for unusual activity and lock you out until you can verify it.
I guess I'm stuck with passwords.
Many services offering 2FA, esp. TOTP, will give you a set of backup codes – print/store them separately, safely (using the rule of backups). At the very least, Google does and allows you to view the existing ones and I think regenerate new ones on-demand as long as you can currently securely access your account.
The same can be done with security keys – typically you can add more than one to your account so have at least two and keep one stored safely somewhere.
Sadly, I recently set up an AWS account and, from what I could tell during that period, they support TOTP/hardware keys, but you can seemingly only pick a single 2FA method – so either TOTP or one single hardware key. That’s a service I would have expected better from (or perhaps I am misunderstanding my settings panel where I can’t find a way to add another factor – I am rather new to managing that ecosystem/account).
The same can be done with security keys – typically you can add more than one to your account so have at least two and keep one stored safely somewhere.
Sadly, I recently set up an AWS account and, from what I could tell during that period, they support TOTP/hardware keys, but you can seemingly only pick a single 2FA method – so either TOTP or one single hardware key. That’s a service I would have expected better from (or perhaps I am misunderstanding my settings panel where I can’t find a way to add another factor – I am rather new to managing that ecosystem/account).
I think that you are intended to use AWS as described in this comment [1]. Even if you are a one person operation, you can create those separate IAM accounts for admin and normal use. Once you have this hierarchy of accounts in place, it is fairly straightforward to deal with a lost hardware key.
[1] https://news.ycombinator.com/item?id=21411013
[1] https://news.ycombinator.com/item?id=21411013
In my organization there are certain operations that we require you to have authenticated with 2fa in order to perform them. For the CLI or terraform this means using something like awsmfa. There's no way of doing that with a FIDO key.
It would be nice to be able to use a FIDO dongle for the web console and TOTP for cli tools but the (bad) AWS restriction forcing you to only use one or the other means I'm stuck on TOTP for everything.
It would be nice to be able to use a FIDO dongle for the web console and TOTP for cli tools but the (bad) AWS restriction forcing you to only use one or the other means I'm stuck on TOTP for everything.
1. Buy 2 yubikeys (with U2F)
2. Add both for each site you use it for
3. If using gpg keys you masterkey lives on a USB key, use subkeys which get transferred onto both yubikeys
4. Lock one the USB key and 2nd yubikey in a safe* with the password you never use
5. If you lose your day to day keys, unlock safe
*safe can be an actual safe, a "secure enough" place in your house, a bank safety deposit box, etc... You can also have multiple safes, one on site, one offsite.
2. Add both for each site you use it for
3. If using gpg keys you masterkey lives on a USB key, use subkeys which get transferred onto both yubikeys
4. Lock one the USB key and 2nd yubikey in a safe* with the password you never use
5. If you lose your day to day keys, unlock safe
*safe can be an actual safe, a "secure enough" place in your house, a bank safety deposit box, etc... You can also have multiple safes, one on site, one offsite.
Doesn't cover the scenario I outlined.
Step 1 then becomes "buy airline ticket to get home so I can get at the safe".
Sure, of course doable, but a million times more cumbersome.
What if passport was also stolen? Maybe in such a time it would be convenient to be able to contact anyone? Even if not to solve the situation but more of a heads-up.
Step 1 then becomes "buy airline ticket to get home so I can get at the safe".
Sure, of course doable, but a million times more cumbersome.
What if passport was also stolen? Maybe in such a time it would be convenient to be able to contact anyone? Even if not to solve the situation but more of a heads-up.
For me, I have a sibling I trust to store a set of back up codes in their fire safe across the country. Another option would a lawyer, such as one you already have a will with. That would be an expense though.
> Switch your carrier to Google Fi
Now no one can socially engineer access to your account -- including you yourself, in case you're locked out :-)
Now no one can socially engineer access to your account -- including you yourself, in case you're locked out :-)
So is Google Big Brother?
I think calling this 'paranoid' is a bit misleading. Paranoia suggests you are deluded or irrational, and that nobody's out to get you. In reality, people might be out to get you, just like walking a city street, someone might be looking to mug you. The difference is, they aren't looking for you specifically, the chances are pretty low of you running into them, and you shouldn't be overly worried or take too many precautions just because of that possibility. But you should be informed, and let your awareness of the possibility inform your actions.
I have a Yubikey but I can't use it fully yet:
- There is no Yubikey OTP app for the iPhone
- Safari iOS does not respond to WebAuthn APIs (the apis are available but don't have any effect). I rather use plain Safari or Firefox, so Brave browser is not an option for me.
- There is no Yubikey OTP app for the iPhone
- Safari iOS does not respond to WebAuthn APIs (the apis are available but don't have any effect). I rather use plain Safari or Firefox, so Brave browser is not an option for me.
> does not respond to WebAuthn APIs
Hmm, is it still the case? I don't have an iPhone, but after reading this post https://www.yubico.com/2019/09/yubico-ios-authentication-exp... my understanding was that WebAuthn will now work with all browsers, not only Brave.
No, I tried it. The APIs work normally from the web application perspective, but no prompt comes up to connect the security key. You also need to enable it from the experimental features page.
I can't help but think the author has recommended (1) storing backup keys (presumably in 1Password?) (2) storing OTP key generation QR codes in 1Password, so it can generate OTP codes for you.
Doesn't this defeat the whole purpose of "two"-factor authentication? If your 1Password gets hacked the attacker has both your passcode and one-time password?
You should consider keeping these two separate: If your 1Password unlocks with FaceID, do not make your Authy (or etc.) also unlock with FaceID. Otherwise, you're defeating the purpose of 2FA (something you "know" and something you "have"), I think.
Doesn't this defeat the whole purpose of "two"-factor authentication? If your 1Password gets hacked the attacker has both your passcode and one-time password?
You should consider keeping these two separate: If your 1Password unlocks with FaceID, do not make your Authy (or etc.) also unlock with FaceID. Otherwise, you're defeating the purpose of 2FA (something you "know" and something you "have"), I think.
The author was pretty clear about the risks:
> This solution is fine for most people, but this section is about being a bit more paranoid, so I would recommend not using the 1Password integration for your one-time password codes.
> The more extreme option is to manually keep track of the QR code or setup key provided when setting up 2FA for a TOTP authenticator on each account. Backing up these setup codes is a bit controversial and not recommended by the more hardcore security folks as it introduces another avenue by which you could be compromised if not securely stored. If you opt to backup your QR codes, you may want to store them outside of your password manager and in an encrypted manner.
> This solution is fine for most people, but this section is about being a bit more paranoid, so I would recommend not using the 1Password integration for your one-time password codes.
> The more extreme option is to manually keep track of the QR code or setup key provided when setting up 2FA for a TOTP authenticator on each account. Backing up these setup codes is a bit controversial and not recommended by the more hardcore security folks as it introduces another avenue by which you could be compromised if not securely stored. If you opt to backup your QR codes, you may want to store them outside of your password manager and in an encrypted manner.
It's slightly less secure but much more convenient, which I think is worth the trade-off. Just having 2fa on means you don’t have to worry if a website has its passwords compromised, which is probably the biggest threat for most people.
See my comments elsewhere in this thread. I’d argue that ‘having unique passwords for every site’ is much more important than 2FA when it comes to the consequences of a site’s database being compromised.
For instance, I’ll happily give you my password to ‘My Vodafone’. It’s nXewr7Vq4f)s9>ky. It really is. I don’t give a shit if their database is compromised, it doesn’t affect the rest of my life.
(I haven’t been a customer in about a decade. The login no longer works. You get the point.)
2FA adds nothing to this scenario. I should assume that an attacker who has compromised the site’s database has also compromised their OTP systems.
For instance, I’ll happily give you my password to ‘My Vodafone’. It’s nXewr7Vq4f)s9>ky. It really is. I don’t give a shit if their database is compromised, it doesn’t affect the rest of my life.
(I haven’t been a customer in about a decade. The login no longer works. You get the point.)
2FA adds nothing to this scenario. I should assume that an attacker who has compromised the site’s database has also compromised their OTP systems.
This is true for some 2FA methods but you can literally publish all the data for WebAuthn and it won't make any difference to the security for your users or your site. Same reason seeing the certificate for Hacker News doesn't get you any closer to successfully impersonating the site, public key cryptography.
Bad guys who steal my WebAuthn credentials for foo.example don't learn how to sign in as me on any site at all, even on foo.example. If they break into another site. bar.example and steal all their WebAuthn credentials too, they can't even correlate them to figure out who has sign-ins on both sites.
Bad guys who steal my WebAuthn credentials for foo.example don't learn how to sign in as me on any site at all, even on foo.example. If they break into another site. bar.example and steal all their WebAuthn credentials too, they can't even correlate them to figure out who has sign-ins on both sites.
Some websites insist on using 2FA, even if you don't want it.
Further down in the same article:
>but you don't really want to have your password manager also store OTPs
>but you don't really want to have your password manager also store OTPs
For some reason I‘m basically locked out of any paid Google product because my Google Pay account is disabled for whatever reason. I think it might have been flagged for fraud years ago and now cannot use it at all, including for Fi. It’s crazy.
Set up a new account, and remember not to link the new or old accounts by way of a recovery email address or using the same phone number.
It's a bit of a hassle, but most things you can transfer over between the accounts, and then just dump the old one. Lots of effort, but the only way unless you know an employee to get the block removed.
It's a bit of a hassle, but most things you can transfer over between the accounts, and then just dump the old one. Lots of effort, but the only way unless you know an employee to get the block removed.
Or just get off the Google bandwagon.
Googles customer service: None
Google's care of their users: None
Google's desire to sell every single thing about you they can figure out: Unlimited.
Googles customer service: None
Google's care of their users: None
Google's desire to sell every single thing about you they can figure out: Unlimited.
To be fair they may have customer service, but you are not the customer but the product.
SSH key storage needs more info I think. I am using SSH enough that this '...can also do SSH...' would want to be the main topic.
advanced modes disabling API keys means a lot of the older third party integrations which depend on a simple API token are SOL. this worries me, lockin risks.
advanced modes disabling API keys means a lot of the older third party integrations which depend on a simple API token are SOL. this worries me, lockin risks.
>SSH key storage needs more info I think. I am using SSH enough that this '...can also do SSH...' would want to be the main topic.
Different audiences, I think - this article doesn't go into technical details that often besides mentioning various protocols and what they do. Using a Yubikey for SSH (either via GPG or X.509 certs) is significantly more involved than using one for U2F/FIDO2.
There's a pretty in-depth guide here on using one as a GPG smartcard with SSH (that's what I do): https://zeos.ca/post/2018/gpg-yubikey5/
Different audiences, I think - this article doesn't go into technical details that often besides mentioning various protocols and what they do. Using a Yubikey for SSH (either via GPG or X.509 certs) is significantly more involved than using one for U2F/FIDO2.
There's a pretty in-depth guide here on using one as a GPG smartcard with SSH (that's what I do): https://zeos.ca/post/2018/gpg-yubikey5/
There's also DrDuh's pretty comprehensive guide https://github.com/drduh/YubiKey-Guide
For bonus points, you can also sign your Git commits.
Yup! And it's simple enough to do this automatically by just putting this in your gitconfig:
[user]
signingkey = <your GPG fingerprint here>
[commit]
gpgsign = trueYou don't need signingkey if you have a GPG key with the same email as your git user.email (I guess that's the majority of cases).
>I use and love 1Password and pay for the cloud account
Is it just me, or does a hosted password manager smell like an absolutely terrible idea to anyone else?
Is it just me, or does a hosted password manager smell like an absolutely terrible idea to anyone else?
The convenience outweighs the risks for the vast majority of users. My parents need something that is available on all devices, syncs automatically, and requires no maintenance.
You get a master encryption key that never leaves your device when setting up the account. Anything that touches their servers is encrypted with that key. You need that key to setup a new device (in addition to your username and master password).
You get a master encryption key that never leaves your device when setting up the account. Anything that touches their servers is encrypted with that key. You need that key to setup a new device (in addition to your username and master password).
OP comment from Reddit post:
>Hey folks, OP here. I’ve been using security keys for a few years now and decided to spend some spare time over the last few months writing this up. Despite the name it’s pretty detailed (15k words!) and hope it can help folks understand the benefits of security keys and what fido2 brings to the table.
>Hey folks, OP here. I’ve been using security keys for a few years now and decided to spend some spare time over the last few months writing this up. Despite the name it’s pretty detailed (15k words!) and hope it can help folks understand the benefits of security keys and what fido2 brings to the table.
> TOTP risks - You could still fall victim to a fake website (or real one being proxied via man-in-the-middle like with Evilginx 2 and Modlishka)
> Security key benefits - Even if the user willingly tried to log into a fake phishing site, the security key authentication would not work as the domain would differ.
Why are security keys secure against man-in-the-middle attacks?
> Security key benefits - Even if the user willingly tried to log into a fake phishing site, the security key authentication would not work as the domain would differ.
Why are security keys secure against man-in-the-middle attacks?
https://developers.yubico.com/U2F/Protocol_details/Overview....
Via the U2F protocol, the browser embeds the URL and optionally the TLS Channel ID in the challenge, so a phishing website asking for a challenge will produce the wrong challenge (and response).
Note this does not prevent an attack via webUSB (https://www.wired.com/story/chrome-yubikey-phishing-webusb/ ).
Via the U2F protocol, the browser embeds the URL and optionally the TLS Channel ID in the challenge, so a phishing website asking for a challenge will produce the wrong challenge (and response).
Note this does not prevent an attack via webUSB (https://www.wired.com/story/chrome-yubikey-phishing-webusb/ ).
There's no we ay to stop a full MITM though where maybe the State took over the certificate of a site.
If the Channel ID is included it stops MITM completely.
In fact doing the authentication inside the secure channel in a way that depends on the key that is used by such channel is the best way to perform mutual authentication. In MitM case the authentication will just fail and passive attackers cannot learn anything about the identities used for authentication.
Both SSH2 and many Windows-related protocols work in exactly this way.
In fact doing the authentication inside the secure channel in a way that depends on the key that is used by such channel is the best way to perform mutual authentication. In MitM case the authentication will just fail and passive attackers cannot learn anything about the identities used for authentication.
Both SSH2 and many Windows-related protocols work in exactly this way.
Now we have APIs for 2FA tokens in place.
When will we get an API for password managers? That'd enable effective domain name checks and such.
When will we get an API for password managers? That'd enable effective domain name checks and such.
These hardware tokens usually support PGP as well! It's possible to generate a full set of keys on the device. Combining this with an offline primary key makes for a very secure system that's also relatively easy to use.
Most FIDO devices don't do anything else. Yubico sells a lot of products that do, but Yubico's cheapest line of FIDO compliant USB keys, and most competitors cheaper products do not do anything except FIDO.
Yeah and you really want FIDO. It's such a better experience.
[deleted]
There is a depressing lack of open standards with these off-the-shelf physical tokens. It's unfortunate that a company's security can rely on the APIs of another company which could go bankrupt and disappear at any time.
This comment held water about five years ago, but times have changed.
Unpopular opinion: These keys are about selling the idea that physical-based security is somehow magically better.
If you have good password hygene (read: a decent password manager) then I'll need to breach your host to obtain it - if you use a security key, I'll have to breach your host and hijack your session which is slightly more convenient but chances are you're royally screwed once you're breached anyway.
Sure there's some edge cases where this might work (one-way keyloggers, etc) but these aren't realistic threats for a large majority of people.
Somehow a sales team have taken a bullet hole, and attempted to use a square peg to band-aid it.
Stop buying stupid products and just use a damn password manager.
If you have good password hygene (read: a decent password manager) then I'll need to breach your host to obtain it - if you use a security key, I'll have to breach your host and hijack your session which is slightly more convenient but chances are you're royally screwed once you're breached anyway.
Sure there's some edge cases where this might work (one-way keyloggers, etc) but these aren't realistic threats for a large majority of people.
Somehow a sales team have taken a bullet hole, and attempted to use a square peg to band-aid it.
Stop buying stupid products and just use a damn password manager.
> Unpopular opinion
Yes, quite unpopular since keyloggers and clipboard watching malware are probably a threat model to many more people than someone stealing a security key off your keychain.
Yes, quite unpopular since keyloggers and clipboard watching malware are probably a threat model to many more people than someone stealing a security key off your keychain.
If malware is in a position to steal data from your clipboard or keylog your device, it's very likely to be in a position to hijack your session tokens.
Dubious. On a desktop device it's really common for there to be mechanisms that make it easy for software to steal the clipboard contents and intercept keypresses because these are things that some legitimate desktop software needs. There may often be a documented API that even a mediocre programmer can use to get this working in a few hours.
On the other hand, stealing session tokens is typically going to require reaching inside the browser process, which is perhaps the most sophisticated software on a machine, and then groping around to find these tokens. It definitely is possible in some cases but it's likely to be pretty hard.
I'd compare it to the difference between stealing a person's credit card from a bag they left under their seat versus reaching under somebody's shirt to take the money they've tucked into their bra. I don't doubt that somebody, somewhere, is good enough to get away with that second one unnoticed, but I know for sure the first one is easier.
On the other hand, stealing session tokens is typically going to require reaching inside the browser process, which is perhaps the most sophisticated software on a machine, and then groping around to find these tokens. It definitely is possible in some cases but it's likely to be pretty hard.
I'd compare it to the difference between stealing a person's credit card from a bag they left under their seat versus reaching under somebody's shirt to take the money they've tucked into their bra. I don't doubt that somebody, somewhere, is good enough to get away with that second one unnoticed, but I know for sure the first one is easier.
Last I checked hooking key events in Windows requires SYSTEM access.
Stealing session tokens can be as easy as just pulling the entire browser profile, which I doubt requires elevated access.
I imagine black market postexploitation kits would have session data theft as a feature.
Again, if somebody has system access, you're probably completely fucked from a different angle irrespective of your preferred authentication method so now we're talking about semantics of how you're getting fucked because most 'apt's are going to be grepping your disk for words key phrases like 'financial data', not caring about your facebook account.
Stealing session tokens can be as easy as just pulling the entire browser profile, which I doubt requires elevated access.
I imagine black market postexploitation kits would have session data theft as a feature.
Again, if somebody has system access, you're probably completely fucked from a different angle irrespective of your preferred authentication method so now we're talking about semantics of how you're getting fucked because most 'apt's are going to be grepping your disk for words key phrases like 'financial data', not caring about your facebook account.
While it is true that hooking _all_ keyboard input requires SYSTEM access (because it involves either impersonating the session manager or injecting code into kernel), you don’t really need that to exfiltrate passwords for random websites that are entered into web browser. Owner of session can hook any event that is passed to the session, which obviously includes any keyboard event that the browser is going to see.
Even if the malware hijacks your session tokens, using something like WebAuthn prevents silent theft of a password, which is much more powerful (allows creation of new sessions).
If your host is infected with malware but it can't steal your passwords due to hardware boundaries, it still has access to your host at a pretty reasonable permission level.
In most corporate environments that's far more damaging than getting persistence in a handful of webapps.
Also, 2FA solves this exact issue.
In most corporate environments that's far more damaging than getting persistence in a handful of webapps.
Also, 2FA solves this exact issue.
Other folks have mentioned things you missed, here's another: insider threats.
A authentication event requiring a hardware token is significantly harder to deny, especially if used again by the legitimate user after the questionable event. So any insider attacks that are not last-hurrahs or one-shots plausibly explained by theft are significantly riskier.
A authentication event requiring a hardware token is significantly harder to deny, especially if used again by the legitimate user after the questionable event. So any insider attacks that are not last-hurrahs or one-shots plausibly explained by theft are significantly riskier.
If you're trying to prevent credential theft: Educate users on password managers, deploying 2FA, or tokens like this would also make sense. MFA deployments are probably significantly cheaper though (And yes, ActiveDirectory OTP and smartcard based MFA tools exist). Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone.
If you're trying to have rock solid audit trails that will stand up in court: This, or 2FA won't have a huge functional difference, but chances are unless you have NSA/Google tier security, your money would be better spent hardening infrastructure - your logs won't be worth jack if a pentest rips your network apart in two hours. I regularly see $1m+ SEIM deployments on MS17-010 vulnerable networks, I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
If you're trying to have rock solid audit trails that will stand up in court: This, or 2FA won't have a huge functional difference, but chances are unless you have NSA/Google tier security, your money would be better spent hardening infrastructure - your logs won't be worth jack if a pentest rips your network apart in two hours. I regularly see $1m+ SEIM deployments on MS17-010 vulnerable networks, I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
> Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone.
(Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device).
Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on all web internal web sites, the SSO implementation supports U2F * short-lived (less than a day) ssh certs signed by Yubikey OTP * VPN access authenticated by Yubikey OTP
Enrolling of yubikeys is self-service, and supports up to 2, and employees in critical positions can have 2. Re-setting the Yubikey OTP pin is mostly self-service, but you need to enter it any time you VPN or get a new ssh cert, so you are more likely to forget your phone at home than your Yubikey OTP pin.
> I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
Many banks (especially in my country) rely on SMS OTPs. Some banks have OTP authentication for their websites on their mobile apps (but then if you uninstall the app, you have to re-enroll, which is quite tedious).
I would much prefer all banking sites to support U2F/WebAuthn, and hopefully that would also sufficiently motivate good support on phones for U2F/WebAuthn. If they allowed you to turn off any SMS-based OTPs (e.g. if they support recovery codes and 2 tokens), I think it would be possible to eliminate SIM-swap fraud (which is quite rife here ...).
And to be clear, I don't mean this in place of good password managers, I mean in addition to password managers. Defense-in-depth and all.
(Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device).
Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on all web internal web sites, the SSO implementation supports U2F * short-lived (less than a day) ssh certs signed by Yubikey OTP * VPN access authenticated by Yubikey OTP
Enrolling of yubikeys is self-service, and supports up to 2, and employees in critical positions can have 2. Re-setting the Yubikey OTP pin is mostly self-service, but you need to enter it any time you VPN or get a new ssh cert, so you are more likely to forget your phone at home than your Yubikey OTP pin.
> I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.
Many banks (especially in my country) rely on SMS OTPs. Some banks have OTP authentication for their websites on their mobile apps (but then if you uninstall the app, you have to re-enroll, which is quite tedious).
I would much prefer all banking sites to support U2F/WebAuthn, and hopefully that would also sufficiently motivate good support on phones for U2F/WebAuthn. If they allowed you to turn off any SMS-based OTPs (e.g. if they support recovery codes and 2 tokens), I think it would be possible to eliminate SIM-swap fraud (which is quite rife here ...).
And to be clear, I don't mean this in place of good password managers, I mean in addition to password managers. Defense-in-depth and all.
Banks inside the EU probably can't easily go to WebAuthn because they're coming under rules that say their multi-factor authentication needs to tie into transaction details.
The concern is, a customer is tricked into _legitimately_ authorising transaction A ("Send my cousin $50 for emergency cab fare") but the bad guys use the authorisation instead for transaction B ("Send my entire account balance to Anne Actual Crook in Russia") and the bank thinks everything checks out because they used multi-factor. Making the transaction details part of the authentication can defuse this significantly if you do it properly.
A straight forward WebAuthn setup which is just proof of control isn't enough there. Maybe you can put together something using extensions to WebAuthn or fudge it somehow to add these transaction details, but out of the box the banks seem to be going for:
* Bank branded authenticator apps for smartphones
* SMS (ugh)
* Custom authenticator devices with their own input
The concern is, a customer is tricked into _legitimately_ authorising transaction A ("Send my cousin $50 for emergency cab fare") but the bad guys use the authorisation instead for transaction B ("Send my entire account balance to Anne Actual Crook in Russia") and the bank thinks everything checks out because they used multi-factor. Making the transaction details part of the authentication can defuse this significantly if you do it properly.
A straight forward WebAuthn setup which is just proof of control isn't enough there. Maybe you can put together something using extensions to WebAuthn or fudge it somehow to add these transaction details, but out of the box the banks seem to be going for:
* Bank branded authenticator apps for smartphones
* SMS (ugh)
* Custom authenticator devices with their own input
How about phishing?
100% this. Phishing is incredibly common, really difficult for even sophisticated users to detect when done well, and the best password manager isn't going to help you. A security key will all but guarantee that this isn't an issue and is a pretty good UX too.
Correct me if I'm wrong, but password managers can prevent quite a lot of phishing, because autofill can automatically check the domain.
It would be abundantly obvious to me if I were going to put my paypal password into anything but paypal, for instance, because I wouldn't even have the option. I'd have to copy/paste if I wanted to, which would up my suspicion level to the extreme.
(this is not to downplay security keys though, I think they're very important)
It would be abundantly obvious to me if I were going to put my paypal password into anything but paypal, for instance, because I wouldn't even have the option. I'd have to copy/paste if I wanted to, which would up my suspicion level to the extreme.
(this is not to downplay security keys though, I think they're very important)
It would be abundantly obvious to me
That's what people say but even security experts have fallen for phishing attacks. And since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there.
That's what people say but even security experts have fallen for phishing attacks. And since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there.
It's really quite unusual. I'm not sure what password managers these security experts are using, but there's no way it works like mine (bitwarden). I've never had it fail to recognize the domain, which is good because that seems like really obvious functionality.
I have had it fail to autofill due to site implementation, and the couple of times it happened I was extremely on my guard and triple-checked everything before proceeding.
I think that's the important part of this, the manager has to be reliable enough that the bypass mechanism stands out _a lot_, and the user has to be aware.
I have had it fail to autofill due to site implementation, and the couple of times it happened I was extremely on my guard and triple-checked everything before proceeding.
I think that's the important part of this, the manager has to be reliable enough that the bypass mechanism stands out _a lot_, and the user has to be aware.
Sure it can handle logins to both "theircompany.com" and "service.theircompany.com", assuming the cert is set up correctly. It probably isn't going to figure out that those are related to "theircompany-service.net". This would arguably be a failure in domain setup, but I've certainly seen similar setups before.
Example: "https://hbweb.incompass-solutions.com/" uses the same credentials as "http://www.equineline.com/" since they're both owned by the Jockey Club.
Example: "https://hbweb.incompass-solutions.com/" uses the same credentials as "http://www.equineline.com/" since they're both owned by the Jockey Club.
Some password managers (like bitwarden) allow for N URL patterns for a given credential, for exactly this purpose.
Sure, but that's something the user sets up, so it still contradicts GP's contention that the user never needs to think about this. The only thing a password manager can (validly) do automatically is look at subject name and subject alt names. (I don't know that all of them even do this.) Even that's assuming that certs are set up correctly...
[deleted]
> since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there.
I imagine you can extract passwords out of security keys in some form without being on the correct domain, too.
Do domain check fails that regularly? I'm sure enterprise configuration policies would provide functionality to prevent password extraction should you be inclined to enable it.
I imagine you can extract passwords out of security keys in some form without being on the correct domain, too.
Do domain check fails that regularly? I'm sure enterprise configuration policies would provide functionality to prevent password extraction should you be inclined to enable it.
You can't
No, the whole point of U2F/FIDO is that phishing sites can't extract a usable credential from the key because everything is tied to the origin requesting the authentication.
WebAuthn doesn't have "passwords" it does public key crypto. So phishingsite.example gets a public key signed response saying "Yup, burner wants to sign into phishingsite.example" and the whole point of cryptographic signatures is that nobody can make it say mybank.example instead of phishingsite.example without invalidating the signature. So it's useless for breaking into your bank account.
There's no UI. Even if you are 100% convinced this is really your bank, you desperately want to sign in, you keep tapping that button, trying again, it can't help the bad guys. There is no "Yes I'm really sure this is my bank" option that destroys your security.
There's no UI. Even if you are 100% convinced this is really your bank, you desperately want to sign in, you keep tapping that button, trying again, it can't help the bad guys. There is no "Yes I'm really sure this is my bank" option that destroys your security.
What’s to stop a password manager behaving in the same way?
Compatibility.
Password managers have to be compatible with the reality of how passwords are used/ abused by site owners. When my preferred electricity supplier was bought by Shell (as part of an exercise in greenwashing the huge fossil fuel company) they rebranded and all their URLs changed overnight. My passwords still worked - but on these new URLs. This looks _exactly_ like a phishing attack, except for the huge advertising spend on a cynical rebranding exercise.
If you sell a password manager that fails in this scenario you're getting customer feedback saying this product doesn't work, fix it. How can you fix it? Add an override, destroy the security value of the product.
But WebAuthn comes out of the box enforcing this rule that the FQDN can't change. When Shell buys the electricity company and says "All your sites need to change" if they used WebAuthn the developer says "I tried that and it breaks login for all customers". "Tell them to override it, put up a banner saying so". "There is no override"... "OK, put the old site back". Done. Users saved from security lapses caused by corporate rebranding.
The WebAuthn people put a bunch of effort into thinking about evil things that can go wrong and defending against them. Having a clean slate to start from helped enormously.
Password managers have to be compatible with the reality of how passwords are used/ abused by site owners. When my preferred electricity supplier was bought by Shell (as part of an exercise in greenwashing the huge fossil fuel company) they rebranded and all their URLs changed overnight. My passwords still worked - but on these new URLs. This looks _exactly_ like a phishing attack, except for the huge advertising spend on a cynical rebranding exercise.
If you sell a password manager that fails in this scenario you're getting customer feedback saying this product doesn't work, fix it. How can you fix it? Add an override, destroy the security value of the product.
But WebAuthn comes out of the box enforcing this rule that the FQDN can't change. When Shell buys the electricity company and says "All your sites need to change" if they used WebAuthn the developer says "I tried that and it breaks login for all customers". "Tell them to override it, put up a banner saying so". "There is no override"... "OK, put the old site back". Done. Users saved from security lapses caused by corporate rebranding.
The WebAuthn people put a bunch of effort into thinking about evil things that can go wrong and defending against them. Having a clean slate to start from helped enormously.
So... Nothing apart from some convoluted anecdote?
If currently there's no password manager in existence that doesn't let you override the plaintext password extraction / override feature, there's nothing to stop one being made. You could probably hook it in with a system level service which cryptographically signs them, too.
If currently there's no password manager in existence that doesn't let you override the plaintext password extraction / override feature, there's nothing to stop one being made. You could probably hook it in with a system level service which cryptographically signs them, too.
>really difficult for even sophisticated users to detect when done well
Hard to believe. Can you substantiate that claim? Also you don't need to detect it, you only need to not fall for it.
Hard to believe. Can you substantiate that claim? Also you don't need to detect it, you only need to not fall for it.
Browser based password managers solve this.
[deleted]