AWS is pushing ahead with MFA for privileged accounts. What that means for you ... Heads up: Amazon Web Services is pushing ahead with making multi-factor authentication (MFA) mandatory for certain users, and we love to see it. The cloud giant in October said it would start requiring MFA for its customers' most privileged users in 2024. Indeed, we understand that since May this year, AWS has been gradually …
I have a work phone with Microsoft Office on it. Whenever I need to sign in on the phone, it prompts me for the MFA by displaying the message on the device and sending the code to the same device. I don't want work things on my private phone so how should I get around this?
I also recommend setting the access to privilege accounts up in a way that supports transfer. Ie. Make it easier for you to handover to someone else and leave the building , or in these post-Covid enlightened times, permit someone else to pick up your accesses due to your unplanned permanent absence.
Just taken over the IT of a client where (once again) they used a personal email account for such accesses and also did not use a password manager, so having to go through a spreadsheet (better than photocopies of handwritten notebooks) and changing everything…
Don't do this.
If you make it easy to transfer to someone else, you make it easier to transfer to bad actors* and then they have the keys to your whole kingdom.
Put the passkeys in an envelope in a safe, and put in protocols around who has the keys / combination. And keep it in a secure building. And ideally you'll almost never need to use it, only in an absolute emergency.
* And I'm not talking about Nicholas Cage.
> Put the passkeys in an envelope in a safe, and put in protocols around who has the keys / combination. And keep it in a secure building.
In my book, that is making it easier to handover!
Because you have thought about how someone else, trusted by the organisation, can use the privileged credentials; if you are not around to facilitate the transfer.
I would hope your thinking would then include the use of non-personal accounts, phones etc. and privileged credential management systems.
It really is quite scary when you encounter admins who have everything either in their heads, “little black” pocketbook, etc. with recovery to their personal email and phone, and think this is normal and perfectly okay, as they aren’t going be hit by a bus etc… Although this not as scary as the FinDir being the only person with admin access to the financial system…
Although this not as scary as the FinDir being the only person with admin access to the financial system…
If the FD is also always on holiday when the auditors are in, you've got another sort of problem.
This is based on a friend of mine auditing a firm where exactly that had happened for several years. A later (after the police were involved) conversation with the MD went: "Didn't you suspect anything?" "Well, I did wonder how he could afford a flash new car every year on his salary." Facepalm.
"By adding passkey support, AWS customers can now use Apple Touch ID on their iPhones, or Windows Hello on their laptops, as an authenticator – and then use that same passkey as an MFA method to sign in to their AWS console across multiple devices."
A fundamental for credential security is that no factor is used across multiple devices (or ideally, as in the case of one time codes, even across multiple transactions), for the simple reason that the more places it's used the more likely it is to be compromised. Once again, it seems convenience takes precedence over common sense.
To be technical, more of concern is that under NIST SP800-63b 5.1.6.1: "Single-factor cryptographic software authenticators SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices." Apple and Google not only do not discourage, they facilitate cloning the secret key (which is all a passkey is) onto multiple devices. It is unclear how Microsoft behaves. I've seen conflicting information there.
...unless there's a help desk that responds to aggressive, shouty management demanding that their credentials get reset LIKE NOW.
And unfortunately, in my experience it's the top echelons of management who think that everybody else should abide by strict and unforgiving processes, but as soon as it's them, then different rules apply.
Because the major passkey implementations are terrible?
Smartphones are abysmal authenticators. They're fragile (they break, they run out of charge). They're insecure and a tempting target for attackers. They're theft-prone. They're loss-prone, because many people use them all the time and become careless with them. Any authentication based on a smartphone is bad authentication.
Most passkey implementations are too difficult to back up (and remember that availability is one of the triad). It's a hassle to maintain a second passkey, and many people won't bother. Passkeys don't work well for shared accounts, and there are many good reasons to have shared accounts.
The most prominent passkey implementations encourage the use of biometrics, and biometrics are always a bad idea.
No biometrics are secure, for reasonable definitions of "secure". Biometrics have poor availability (they're fragile to injury, for example). They don't support delegation. They don't support rekeying, as you noted. They elevate the threat model — I don't know about you, but I'd rather be forced to tell someone a passphrase than be kidnapped so I can unlock a system in person. They have, historically, been rather crap at preventing various forms of credential forgery, and the industry has responded by implementing spot defenses; that is not a good approach.
Biometrics are authenticators for lazy users. They have no other justification.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
