While this is a great step forward for U2F adoption, AWS made the same mistake several other online services have made by only allowing a single key per account. The typical U2F user carries at least two keys. (one on their person and one stored securely for backup) I hope they decide to change this because it will cause a ton of customer support problems in their future.
How do you handle adding both keys if you store them in different locations?
Right now I do something similar, but I have to keep a list of which accounts I need to add to key 2, and the key is offsite, so I have a several week period during which an account only has one key associated with it.
I have one key permanently plugged in to my desktop at home. I have another on my keychain that I can use at work or if I'm travelling or whatever. This allows quick access to a yubikey anywhere I am. My previous problem (when I owned only 1) was that my keys were always in another room when I was home, and getting up to get them was too annoying when logging in to things. Now I have a backup if either is lost and I'm more-or-less guaranteed to have a yubikey within reach anytime it's needed.
You may consider that the authenticator offers enough security but a Security Key is more convenient. I hate typing 6-digit codes into things, touching the little contact or pressing the button on my Security Keys is much more tolerable.
Now, personally I wouldn't want the phishable Authenticator as fallback, but it's definitely better than SMS for example.
Maybe I'm misunderstanding, but I thought the whole idea of ubikey was that it proves who I am because I have it, no? If I own 4 ubikey, how does the system know whether I'm really me, or if I'm someone whose stolen one of my ubikey?
It is a second factor, so the'll also need to know your password.
You will notice your key missing, then you can disable that key with your backup key. With only a password, it becomes a lot harder to notice someone stole your pw.
But that person does have to if you have another key, you can. Fix the situation yourself.
It’s also helpful when you use a key that lives in a machine to not have to remove it. If you lose the machine, use another key to sign in and disavow the lost key.
With AWS you are the company, and you should be allowed to set your own policy, and decide things like whether you trust yourself enough to store a backup key in a safe or something similar.
Suggesting Amazon should treat you like some employee of theirs is silly.
Yes, but other people at your company have keys and they can reset your key. In many situations when you're using keys yourself, there is not trusted person that can verify your identity in person and reset your key.
does your company also disallow having backup keys to your office or company cars? you're supposed to have multiple keys so you're not effed if you lose one.
> I'd be surprised if "most" people have a backup device/codes.
Really? I'd expect someone who's paying $50 for a yubikey to spend another $100 to have a backup key, a key for their laptop, and one for their desktop. Add another one for your keychain if you are using it on your phone (if your phone supports it).
When I had 2FA enabled, using Google Authenticator, and had to reset my phone, I was locked out of AWS. No backup codes. No texting. Nothing. Had to send in a ticket and get a callback.
And this is also what makes Authy a terrible 2FA tool no one should use ever.
It stores your secrets in plain text on the phone without any secure enclave. If your backup password is sniffed or there is a flaw in Authy or your mobile OS sandboxing fails you are toast.
Use the Yubico Authenticator app. The main difference is the (secured) storaged of the shared secret. With Google Authenticator, your keys are stored on the phone.
With Yubico's authenticator, you store the secrets ontp your Yubikey. This means you can reset your phone and still be able to use the same TOTP shared secrets. Or if that matters, ask a friend to install the app and use your Yubikeys to get the TOTP.
Are you sure about that? My AWS 2FA authenticator code has been out of sync for a while and they offer multiple options to get around it. I've been receiving SMS codes easily, in fact I just did this a couple days ago. IIRC they also offered to call me.
Did you flip some bit somewhere to disallow this? Do you have a phone number set up?
Yep, it was a couple years ago. They ask questions, then disabled 2FA so I could just get in with a password, and re-enable 2FA. No options around it. So possibly they've improved the process since then.
Storing password + TOTP together does leave you vulnerable if your vault is stolen/broken into, but I've gone all-in on storing them in 1Password because that's a trade off I'm willing to make.
I used to do this. Then I realized I stored the backup codes in 1Password anyways which are as good as using a TOTP. So instead of investing in another safe place to store the backup codes I decided just to go all in with TOTP in 1Password.
If my 1Password vault is breached, I am pretty much in a world of trouble as it is.
Just don't store your email password in your vault. You could probably quickly regain control of most online services if you retain control of the email you used to sign up.
Not me. I had the TOTP factors in my password manager for a while, and boy was it nice, but eventually I decided that was a risk I wasn't willing to take. I feel safer knowing that they have to beak into at least two different apps.
I use Authy to manage my 2FA codes, but I rarely ever use the desktop app. I stick to my phone to keep a physical separation between my logins and my 2FA app.
I also started storing my backup codes as a base64 encoded gpg password encrypted text file in my password manager. If I ever lose my 2FA codes I can still get into my accounts in a emergency while also protecting myself from a password manager hack.
It's annoying, but as I said, I'm not willing to take the risk.
It's a tough call to make, isn't it? I just figured if they get into 1Password, I'm probably dealing with someone highly sophisticated and didn't stand a chance to begin with. I don't know yet. I might stick keeping them on some physical device.
There’s zero authentication on the Google Authenticator app and it loses all it’s data every phone upgrade. That’s basically what everyone uses.
If someone gets into your 1Password it’s all over anyway.
That said, I pay for the standalone app and store my vault myself. I have no actual reason not to trust AgileBits hosting it, but they must be a huge target and I’m not taking my chances.
AWS often releases features very early, to satisfy the first tranches of early adopters before rounding out the feature with feedback from these passionate users.
AWS EKS is a good example for anyone who has had a play already.
Nearly everything.
Old k8s version. No upgrade possible. Odd deployment process (not fully automated). Support is unable to help in a timely manner. First deployed cluster was directly broken (no DNS resolution).
We eyed on switching from kops to EKS. But immediately stepped down after experiencing so many issues.
Yikes! This is a non-starter for me. I have 4 keys (3 stored in safe places - yes this is inconvenient when setting up a new account, but this is the trade-off for security). What a strange decision.
Lastpass 2FA is just used for account management and sync anyway. It has no role in the secret crypto. If your attacker phishes the master password your synced passwords are all compromised.
Wouldn't they also need access to a device that already synced your passwords? That essentially switches your computer to be the second factor, albeit one that's more easily compromised with malware. And if they already have malware on your computer, you're probably hosed anyway since the passwords have to be decrypted at some point.
If all they managed to do was trick me into entering my master password on a dummy login page, the sort of phish that U2F is designed to protect against, U2F would still keep me protected while OTP wouldn't.
Key note: U2F isn't currently supported in the API, CLI or mobile apps. Docs are unclear as to what the fallback 2FA is, if there is one. Also, as before, you can only have one 2FA method configured at a time, so say goodbye to your hardware tokens or TOTP configurations for AWS if you switch to U2F.
EDIT: "Fallback" is to have root account remove your IAM user 2FA. If root account 2FA is lost they have a few alternative verification options like email or phone call. [1]
> Also, as before, you can only have one 2FA method configured at a time, so say goodbye to your hardware tokens or TOTP configurations for AWS if you switch to U2F
AWS makes it super quick and easy to remove lost 2FA devices using the root account, so it doesn't really matter as much as losing your 2FA for a crypto exchange or whatever where it's going to take at least a week or two to reset. Just keep TOTP on the root account, since you shouldn't be logging into that on a regular basis anyway.
I use this nice open source tool (really just some shell scripts) that Coinbase created, which supports cross-account assume-role with MFA at the command line:
As annoying as that is, if I can run U2F on the root account and the few console accounts I have, I'll feel like we've covered thing most likely to be phished. People are unlikely to type API keys into a phishing site.
It's frustrating that they only allow a single key. I use 4 different hardware U2F devices. Google, GitHub, Dropbox, and every other service on which I've set up U2F have always allowed me to attach all of my security keys. It seems like AWS is about 3 years behind on this stuff.
- Requiring the attestation cert and not accepting a self-signed one—which U2F devices will magically not work? I don’t know, but apparently it’s strictly Yubikeys now.
- Still not convinced anyone seriously uses the console except for root accounts, where AWS forces you to.
- Only one U2F key? Bad. Only one U2F key and overall only one MFA method at all, disabling MFA where it matters most? Baffling.
- The legacy U2F API instead of just using WebAuthn already?
This is one of those things where I keep thinking I should just open source the SAML thing that safely gets an assertion to your CLI where you can assume-role with it, but who knows when AWS is going to decide to reimplement your project.
Atleast Krypton doesnt' work, neither do Titan keys it seems.
I would consider they did that on purpose in some kind of deal with yubico. But given the general level of 'buring-pile-of-failure' AWS manages to produce around the console, it is probably just that they didn't know
If they require attestation that's one more reason I won't be using this, sadly. I always block attestation because there's no need for it when you're supposedly offering an optional second factor, even though I actually do own a Yubico product.
It makes no security sense to check attestation if your second factor is optional. How could a non-Yubico second factor make things worse compared to not using one? It couldn't. If you really, really care then store the attestations so that when fifty customers claim their U2F was broken into you can show that they all have Crap Co. FIDO tokens and point the finger at Crap Co. that's the absolute most that makes any sense with attestation.
Now, if second factor is _mandatory_ then it could make sense to decide OK, we trust Mattel, Apple and LexCorp but not HP, Tyrell Corp, or Weyland-Yutani. It's anticipated that banks (in fifty years when they hear about this new-fangled FIDO technology) would want that, giving customers their own tokens with their own attestation certs. But for an outfit like AWS this option makes no sense, so the correct design is to Never Ask, and if some higher-up insists on asking, just store the answer (including "No, fuck off") with the user's account and press on anyway.
How is U2F considered legacy already? It's still fairly the most modern way for a 2nd factor. WebAuthn just came outmonths ag and most of the Yubikeys - as well as apps/sites/services -- don't support it.
Bear in mind that probably as many AWS accounts are popped by losing access keys as IAM logins (if you're logging in to the root account, stop doing that).
For the access keys, you should look into things like aws-vault, which wrap the STS so that your shell is only ever handling temporary session-bound keys.
Sooner or later I'll move away from Gmail b/c they make it hard to U2F be used with Firefox. More U2F is the way to go, hopefully everyone supports it in the not too distant future.
Right? The only reason I can see for them making it so hard is to pimp Chrome. Firefox supports U2F, and they know I also have an authenticator app which works with any browser. But no, they have to make it awkward and shove a Chrome ad in my face. Very jarring, and yet another disgusting move from Google (one that has gotten very little press).
So, what i never understood about this flow is that only admins can set up mfa. A non admin (any account without IAM permissions) has no way to set up mfa unless an admin does it for them. Currently, I have to have the person tell me their mfa codes next to me, so I van type them in and set it up. How does this work for U2F? Do I have to use their usb device on my computer to allow them to have MFA?
It's such a chicken and egg problem.
Can you have more than one YubiKey associated with an AWS account? Or also setup TOTP, or have a set of backup codes in case you lost your hardware device? Seems kind of dangerous if you can only have one MFA method setup
The Trezor [1] hardware device supports backing up (at initialization) and restoring of the secret seed which is quite useful. It can also be used as a password manager [2].
No. But you also couldn't have a TOTP + Hardware token previously to U2F introduction [1]. AWS has also never had backup codes to my knowledge, other than saving the secret key used to generate TOTP codes. The "backup" has always been maintaining access to the root account to allow that to reset 2FA as needed.
That can't last (i.e., not more than one). The main reason being you can lose a key, forget it, have it stolen, break it, etc. Without a second you'll be living on the edge. They're gonna have to support more than one.
I have a Yubikey for my LastPass. I lived with a single key for over a year. I finally got two more. I'm not sure why I made myself so nervous / stressed those 12+ months.
I don't find the lack multiple U2F keys a big problem. It would be a great feature but considering proper user management it's not a big fail in my opinion.
In my case all AWS accounts have a root user that has MFA enabled and that secret key is stored in a password vault. When a root user login is needed the key is plugged into an OTP application, tasks are performed and then the key is removed from the application.
I do however miss MFA when using the AWS CLI. A lot of my clients require MFA enabled when assuming a role in their account.
I tried a Trezor 1. It prompts me to press the button, but then the browser prompts me to give permission for AWS to see the manufacturer/version of the device and then gives me the error "Attestation Certificate is not valid."
They specifically only support YubiCo at the moment, to the point that Chrome asked me if AWS could read my Security Key manufacturer and model when I pressed the button on my 4C Nano.
The manufacturer is irrelevant to the protocol, they may have asked you for these details but they do not matter. You can even emulate the key in software if you wanted.
Incorrect - everything related to the protocol, including becoming a compatible vendor, is managed by the fido alliance which Yubico is a member of. The U2F specification requires you to parse the certificate, and verify the response message against the cert's public key when registering the device with your application. You can choose to only accept certificates whose public key comes from a certain manufacturer, but that is up to the discretion of the implementer and is not required. If you want to read a full overview of the specification you can read the following document
It's not the manufacturer that AWS wants to read, it wants the attestation certificate, and Yubico's are signed with their Root CA, so it's not something you can emulate. https://developers.yubico.com/U2F/Attestation_and_Metadata/
I tried setting up my AWS account with a Tomu setup with U2F firmware and AWS rejected it.
Yeah I knew that it didn't matter to the protocol, I only made my comment because I could've absolutely sworn I read in docs or their UI that literally _only_ YubiCo was supported, as in no other U2F would work. Can't find it now, so my bad!
I’m using the Google Authenticator for MFA today, but are soon travelling abroad for a week. Should I loose my phone on the trip, a (single) Yubikey would be my rescue, both regarding AWS and other services supporting Yubikey. Any thoughts?
First think of it not from your perspective as a user, but from the site's perspective. If they don't support any form of MFA all they have to authenticate a user with is their password. It's impractical to enforce good password hygiene. If a user's password gets exposed by any means (they write it on a post-it, they get a keylogger installed on their laptop, they are successfully phished, etc), there's really nothing the site can do about it. If they do support MFA and require it on accounts, an attacker then has to get their password like before but also somehow get control of their 2FA device (whether it's a Yubikey or an MFA mobile app, etc). That is much, much harder to do. Not necessarily impossible, but there was a recent article from Google mentioning that they haven't had a single phished account (that they know of), since they mandated hardware MFA for all engineers.
Best practice for a user would be to use a good password manager (so you can use long, unique, secure passwords) and MFA. The second part of that is something that can actually be enforced within an organization.
As far as Yubikey vs software TOTP, etc, it's a bit theoretical. AFAIK, none of the auth apps have had compromises, but it's a lot easier to imagine someone out there figuring out a 0-day attack on a piece of software running on random Android and iOS devices than on hardware like a Yubikey. In theory, the way something like Yubikey works, the actual "secret" involved is stored on the device, and all the computation involving it happens on the device itself, carried out by hard-coded firmware.
As a user, I also really like that the Yubikey (higher end models at least) can store GPG keys and perform those operations securely. So I can set up GPG auth for SSH to servers, and sign my git commits using my Yubikey and know that my private key won't be exposed even if, eg, there's a trojan installed on my workstation. (obviously anything done while working on a trojaned machine is suspect, but the key itself never leaves the hardware, so they can't get that).
U2F credentials are tied to a particular domain, and so do not rely on the user making sure they are on the correct website. As such, they are not susceptible to typical credential phishing attacks.
This is assuming an owned machine. Not the easiest attack but still possible. Obviously things like Google Authenticator (while good) are even more susceptible to MITM phishing.
U2F is supposed to be immune to MITM because of the information sent in the protocol, protected by the encryption. I'm not familiar enough with it to know if it's really immune or not.
Too bad I can't pay for AWS through my bank because my bank doesn't allow payments without CVC for their insecurity. As do almost all banks in the country.
GP is using Safari, which has no native u2f support. I'm assuming the user isn't using Firefox for similar reasons to I (and many others) have thrown around: it's fan spinning almost immediately on Macbooks.
