So, a good long while ago, I started enabling all of my Internet-accessible accounts that supported it with two-factor authentication (a.k.a., "2FA"). It has been a somewhat 'fraught' road.
Typically, sites offer you the capability of using token-based — hardware or, thankfully, "virtual"/software — devices or SMS. I chose SMS because several of my customers make use of hardware-based tokens (like the YubiKeys I wanted to use) not practicable. Then, a couple years in, someone discovered "SS7 has a vulnerability that has the side-effect of rendering SMS-based 2FA no longer secure" and, not long after, a documented exploitation was discovered. Warnings were sent out saying "don't use SMS for 2FA".
However, when your work circumstances are like mine sometimes are, SMS-based 2FA was the only meaningful option. No better options available, I opted to "accept the risk" and keep going as is. Afterall, it seemed to me that some form of 2FA - even if potentially exploitable - is better than no 2FA at all ...if only in that it makes being attacked harder than attacking someone that doesn't have even that meager second level of protection. I mean, you lock the doors to your car and to your house even though you know that an adequately determined and/or skillful thief can still break-in, right? You're mostly hoping "if my house is a harder-to-hit target, they'll look for easier marks." Sorta like "security via obscurity", but, presumably, a little bit better.
At any rate, those warnings started coming out even before "in the wild" exploits were discovered. However, prior to those discoveries, the warnings were mostly advisory. Then, last year, AWS decided "we're sunsetting SMS-based 2FA: it was a beta capability, any way." That left me kind of "stuck". When I'd first set up my AWS accounts with 2FA, the only non-SMS options were either hardware keys or cellphone-based soft-keys. As mentioned previously, the hardware keys were not an option. Similarly, so were cellphone-based soft-keys. While there were other software-based key options, few of them had desktop-based clients. The few of those that had desktop-based options, most seemed to assume that you only ever used one desktop (such that, if you, say, set up your bank account for 2FA using such an app on your home computer, you no longer had the ability to use your bank's website at work without using one of the "backup" access codes). I thought I was going to be stuck going back to 2FA-less for my AWS accounts.
Fortunately, it seems like there's more options for 2FA. Some even have included the design-assumption, "many people don't have the ability to rely on just one token (virtual) device". Or, maybe they simply realized that no one was going to carry around an inch-thick deck of filing-cards, each with a given 2FA-enabled site's backup codes printed on it. Don't really care on the why, simply care that now I can "2FA all the things" (that support 2FA at all).
This morning, it was a dead day at work (a lot of people in the US take off the day following the Fourth of July). So, I decided to see whether/how to change my AWS account to use a 2FA protection that wasn't reliant on SMS. I looked at AWS's list of supported soft-keys — Google Authenticator (and presumably ones that operate compatibly – like LastPass's claims to) and Authy — it made my choice easy: the Google Authenticator only works on cellphones, thus, I could eliminate it. So, I opted to download and install Authy to see if I could make it work (surprisingly, they don't yet seem to have options for Linux desktop users). Also wanted to see how hard the setup was so I could make an informed "we should require all our AWS users to 2FA-enable their accounts" (or not) recommendation to our security-policy team. So, after downloading and installing Authy:
- Not wanting to lock myself out of my AWS account, I created a testing console-user with console login rights.
- I logged out of the account I have that's enabled for IAM-user creation
- Logged in to my test account using standard user/password credentials
- Went to the IAM console for my test-user
- Clicked on the "Security Credentials" tab
- Clicked on the (edit) pencil-icon next to the "Assigned MFA device" row
- Selected "A virtual MFA device" from the first dialog-popup
- Clicked "Next" till I got to the "Manage MFA Device" screen
- Clicked on the "Show secret key for manual configuration" button to expose the manual-configuration token-string (since, my computer had no ability to scan a QR code)
- Clicked on the "Tokens" icon in Authy, and then the "+" icon to add a new account-binding
- Copied the secret key from the AWS page to my cut-buffer
- Pasted the AWS secret key into the "Enter Code given by the website" text-box in Authy and hit the "Add Account" button
- Chose a meaningful account name and icon and hit the "Save" button
- Then copied the first and second six-charater tokens into the "Authentication Code 1" and "Authentication Code 2" fields, then clicked the "Activate Virtual MFA" button
- After AWS popped up its "The MFA device was successfully associated with your account. " message, I clicked the "Finish" button to exit the MFA setup tool
- I then logged into the account using a different browser. After entering the test user's normal user/password credentials, it prompted me for my Authy-generated string. I entered that and I was into the AWS console just like normal.
- I quickly logged out from my test account and then nuked it via my IAM-administrator enabled account. I repeated the above with my other AWS accounts (I have several - each with different priv-sets). Each was a breeze to set up and use.
Now to see how many of my other 2FA-via-SMS accounts I can convert to Authy. I'd really rather have "one ring", but some sites want you to use particular 2FA tools.