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.
cbhl 1637 days ago [-]
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).
jen729w 1637 days ago [-]
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.
eaguyhn 1636 days ago [-]
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).
lixtra 1636 days ago [-]
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.
akerl_ 1636 days ago [-]
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?
lixtra 1636 days ago [-]
- 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.
akerl_ 1636 days ago [-]
All of these aren’t related to your 1password vault. They all occur even if you’re using your phone as a totp device.
labawi 1636 days ago [-]
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.
tialaramex 1636 days ago [-]
Terminology clarification: The seed driving TOTP is a shared secret but NOT a symmetric key.
1637 days ago [-]
thedanbob 1636 days ago [-]
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.
vel0city 1637 days ago [-]
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.
chowell 1637 days ago [-]
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.
Yea it's very annoying. I ended up making multiple IAM users--one for each of my security keys.
hsivonen 1637 days ago [-]
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.)
Boulth 1636 days ago [-]
Exactly this. And that's why AWS's U2F feature is basically useless. They should've allowed to add multiple keys simultaneously.
tzs 1636 days ago [-]
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].
With andotp I can export/backup the keys and use them on other devices. Also, you could scan the qr code (private key) with devices or print it out and keep it safe.
Boulth 1636 days ago [-]
Yeah but U2F is more secure (non exportable key, non phishable). With AWS OTP is the only viable option.
cfallin 1636 days ago [-]
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!
mxschumacher 1636 days ago [-]
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.
dragonwriter 1636 days ago [-]
Codes on paper are still bits of hardware that can be lost, stolen, or destroyed.
mxschumacher 1636 days ago [-]
I'm less likely to lose a piece of paper in a safe than I am to lose the phone in my pocket
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.
minty_phoenix 1636 days ago [-]
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).
tzs 1636 days ago [-]
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.
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.
deadbunny 1635 days ago [-]
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.
tjoff 1634 days ago [-]
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.
casefields 1636 days ago [-]
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.
ssivark 1637 days ago [-]
> 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 :-)
1984victim 1636 days ago [-]
So is Google Big Brother?
peterwwillis 1637 days ago [-]
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.
sebazzz 1637 days ago [-]
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.
jacekm 1636 days ago [-]
> 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.
sebazzz 1633 days ago [-]
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.
allset_ 1636 days ago [-]
Yubico Authenticator for iOS was released today.
delogan 1635 days ago [-]
> Only iPads with Lightning connectors are supported.
alpb 1637 days ago [-]
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.
zeroxfe 1636 days ago [-]
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.
wonnage 1636 days ago [-]
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.
jen729w 1636 days ago [-]
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.
tialaramex 1636 days ago [-]
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.
vbezhenar 1637 days ago [-]
Some websites insist on using 2FA, even if you don't want it.
regecks 1637 days ago [-]
Further down in the same article:
>but you don't really want to have your password manager also store OTPs
undefined3840 1637 days ago [-]
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.
londons_explore 1636 days ago [-]
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.
zie 1636 days ago [-]
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.
SaturateDK 1636 days ago [-]
To be fair they may have customer service, but you are not the customer but the product.
ggm 1637 days ago [-]
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.
ryukafalz 1637 days ago [-]
>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.
You 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).
parliament32 1636 days ago [-]
>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?
bradstewart 1636 days ago [-]
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).
breadandcrumbel 1637 days ago [-]
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.
CGamesPlay 1636 days ago [-]
> 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?
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).
There's no we ay to stop a full MITM though where maybe the State took over the certificate of a site.
dfox 1636 days ago [-]
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.
0b0001 1636 days ago [-]
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.
matheusmoreira 1637 days ago [-]
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.
tialaramex 1637 days ago [-]
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.
dickeytk 1637 days ago [-]
Yeah and you really want FIDO. It's such a better experience.
1637 days ago [-]
arshbot 1637 days ago [-]
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.
couchand 1637 days ago [-]
This comment held water about five years ago, but times have changed.
burner589432 1637 days ago [-]
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.
judge2020 1637 days ago [-]
> 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.
burner589432 1637 days ago [-]
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.
tialaramex 1636 days ago [-]
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.
burner589432 1636 days ago [-]
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.
dfox 1636 days ago [-]
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.
blintz 1637 days ago [-]
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).
burner589432 1637 days ago [-]
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.
_jal 1637 days ago [-]
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.
burner589432 1637 days ago [-]
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.
ti_ranger 1636 days ago [-]
> 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.
tialaramex 1636 days ago [-]
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
bodhi 1637 days ago [-]
How about phishing?
datguacdoh 1637 days ago [-]
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.
kadoban 1637 days ago [-]
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)
pvg 1637 days ago [-]
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.
kadoban 1637 days ago [-]
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.
jessaustin 1636 days ago [-]
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.
Some password managers (like bitwarden) allow for N URL patterns for a given credential, for exactly this purpose.
jessaustin 1635 days ago [-]
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...
1637 days ago [-]
burner589432 1637 days ago [-]
> 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.
chowell 1637 days ago [-]
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.
tialaramex 1636 days ago [-]
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.
Bnshsysjab 1636 days ago [-]
What’s to stop a password manager behaving in the same way?
tialaramex 1636 days ago [-]
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.
burner589432 1636 days ago [-]
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.
synotna 1637 days ago [-]
You can't
GoblinSlayer 1635 days ago [-]
>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.
burner589432 1637 days ago [-]
Browser based password managers solve this.
1637 days ago [-]
Rendered at 18:47:09 GMT+0000 (Coordinated Universal Time) with Vercel.
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).
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.
- 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.
> 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...
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 don't think there's any way around having a safe physical location to store backup codes / secrets on paper.
See https://sovrin.org/wp-content/uploads/2019/03/What-if-someon...
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.
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).
[1] https://news.ycombinator.com/item?id=21411013
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.
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.
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.
Now no one can socially engineer access to your account -- including you yourself, in case you're locked out :-)
- 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.
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.
> 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.
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.
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.
>but you don't really want to have your password manager also store OTPs
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.
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.
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.
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/
Is it just me, or does a hosted password manager smell like an absolutely terrible idea to anyone else?
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).
>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.
> 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?
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/ ).
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.
When will we get an API for password managers? That'd enable effective domain name checks and such.
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.
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.
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.
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.
In most corporate environments that's far more damaging than getting persistence in a handful of webapps.
Also, 2FA solves this exact issue.
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 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.
(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.
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
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)
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.
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.
Example: "https://hbweb.incompass-solutions.com/" uses the same credentials as "http://www.equineline.com/" since they're both owned by the Jockey Club.
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.
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.
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.
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.
Hard to believe. Can you substantiate that claim? Also you don't need to detect it, you only need to not fall for it.