If security is important to you (and I think it should be) the problem
with outsourcing your technology to a company like Microsoft, Google,
Amazon or whatever is that you've no means of really testing it.
This could have gone unnoticed for years as so many cloud provider
gaffes do. It's unlikely that anyone would think "Hey let's try brute
forcing the login today". This violates trust-but-verify. You accept
their say-so and so you're fully delegating trust. And because you're
paying thousands of bucks for a service you assume it must be good.
That's the very model of a (con)fidence trick. You don't even know you
bought a lemon until its too late.
There's no substitute for having someone qualified and educated in
cybersecurity with that as their full-time job - and better yet bring
your critical assets back on-prem with some kind of hybrid setup. Big
cloud is really eating at the McDonalds of cybsersecurity.
> This could have gone unnoticed for years as so many cloud provider gaffes do.
I think that Microsoft is getting away easy here with Oasis publishing the vulnerability report. If Microsoft published the report it would be incumbent upon them to include information about what they did to discover whether this happened before Oasis reported the problem.
One wonders how many Azure accounts might have been compromised and are even now allowing data to be exfiltrated.
Doesn’t this just shift the problem? From trusting a company it knows about security to trusting ONE person she/he knows about security?
I would rather trust a company with x persons working on security than one person.
Yes Big Company Microsoft got this one wrong (and also some other), but how many did they right? It’s always easy to be mad at failure if we overlook the times where something was done right.
No. Perhaps counter-intuitively the "problem" isn't trust here.
What I'm raising above is not the necessity to trust but the extent to
which verification is possible or frustrated. For example, with open
versus proprietary code you may or may not have the capacity to audit
it, but you always have the possibility.
> I would rather trust a company with x persons
Trustworthiness does not scale in this way. Though the "many eyes"
theory has some weight, we also say "two people can keep a secret if
one of them is dead." Assigning more cooks to the broth yields rapidly
diminishing returns for reasons Fred Brooks explains [0].
But that is not my strongest objection. A more serious reason not to
trust a BigTech company with your security is the "principal agent
problem" [1]. As Ross Anderson puts it; "If Alice guards a system and
Bob pays the cost of failure, you can expect trouble!" [2]. Microsoft
does not "pay the price".
Worse, Google (and Meta, Linked-In etc) base their business model on
your insecurity - they are primarily in the business of acquiring data
about you to use in selling your person to advertisers. They are
therefore motivated, however weakly, against your actual security.
It's a scandal that such companies also act as data processors and
suppliers of services like online storage.
So while you can outsource trust, you cannot unload responsibility to
verify. A solution is education based on a credo of "principles not
products" [4].
At our place we work with secondary accounts that have their password expire every 8 hours - instead of primary accounts with MFA (though sometimes MFA is also enforced for the secondary account, but interestingly not for Azure Portal).
Of course, the vault where those accounts are stored is a complete enterprise product with associated usability so what ends up happening is that people copy their passwords to an Excel sheet, or worse to Windows sticky notes, which often get up getting screen-shared in Teams calls.
I think so. But I would argue that it is a valid issue that they were able to do it. There are solutions to bruteforce attacks, such as rate limiting, exponential backoffs, alerting et cetera. I wonder why they are not in place for Azure MFA.
Please stop saying "change your password regularly". Despite being a theoretical security increase, it has been shown repeatedly that it is a practical security decrease as it encourages both simpler passwords and incremental passwords. It also makes your users hate you, which isn't great.
A security company should know this. It's been strictly recommended against in the NIST guidelines (and others) for nearing a decade now. I start to really question the expertise of any security company that parrots this outdated advice. What else are they not keeping up on?
Focus on monitoring, alerting, educating, etc. Force password changes only when there are indicators of compromise.
Our organization contracts out our IT, I can cannot stress enough how bad/lazy their cyber security guys are. It feels like the owner told his directionless son "Hey boy, if you manage to pass this cert class I'll make you head of cyber security!"
Every few months we need to change our password. It cannot be a previously used password. It needs uppercase, lowercase, number, special character and minimum 12 characters. We have 2FA that is easily bypassed by going offline then back online once through login. We have 4 different active security suites running on our machines, and mandatory biweekly virus scans, at 10am (which cannot be changed). Every standard 16GB machine runs on it's knees all day long. But at least you can skip 2fa by turning off wifi real fast.
We made IT security a checklist compliance exercise and call it cybersecurity, and then we are shocked and surprised the main deliverable turns out to be checked checklists, not security.
I personally can't imagine trying to be a cybersecurity person. I'd be going out of my mind, concerned with all the things I can't keep up with. As a full stack dev, if I don't know what's new in React 19 it doesn't really hurt anybody, but if the cybersecurity people aren't up to date, that could very well be the end of the company. Either you're hot shit, just think you're hot shit, or you simply don't care, and that blend really scares me.
This is all that matters, regardless of whether a password manager is used or not.
Users should be able to change their own password (almost) whenever they want.
But arbitrary forced password changes from the admin should not happen unless the account has indicators of being compromised (even if all of your users have a password manager).
I would have thought the advice here would be use passkeys everywhere you can and avoid Totp altogether (particularly the sms variant which has real risks today). When I think big picture mfa exists because passwords are often assumed lost to infostealers, so changing your password seems moot for an adversary who is ready to brute force your mfa.
> I would have thought the advice here would be use passkeys everywhere you can and avoid Totp altogether (particularly the sms variant which has real risks today).
Why would you avoid TOTP altogether? Yes, SMS OTP is insecure because SMS is insecure, but OTP itself is fine, unless I missed something?
Passkeys address the phishing angle, but as always it’s a trade off.
With passkeys if someone gets remote control of your computer they have access to everything you setup a passkey for.
Typically people say “well full remote control is far less common than phishing”, and it is, for now, until everyone’s using passkeys and all of the sophisticated phishing attack effort just shifts to passkeys.
The obvious weak point here is all of the outsourced IT who aren’t specifically focused on cybersecurity. Every IT company is using multiple tools for central management that either allows remote control or remote execution, or there’s always in-house developers who realistically aren’t doing a security analysis of every third-party library they’re installing.
I think when compared with a breach in 2FA, changing your password is a good counter. But I agree that in the case of failed 2FA (total failure), an alert should be sent to the user: "password used to access account; but second factor authentication was unsuccessful; change password if this was not you".
It used to be a good idea with things like AD, where pass-the-hash attacks worked and hashes would be static until changed, and in environments where hashes were relatively exposed for cracking and used weak hashes.
Hopefully that is not the case now though, and I am surprised the advice has persisted... (though outdated gov standards probably played a part until recently)
For places that enforce password changes, I can always tell how old my account is by (password change frequency) * (counter I put at end of password).
I can't because there is generally a limit to how many passwords it checks for previous use. So you can usually just start back at "1" for the increment after you hit "0".
> It's been strictly recommended against in the NIST guidelines (and others) for nearing a decade now.
And yet it is still the recommended practice for every IT department for pretty much all corps. Even AWS has their forced 90 password reset policy where you start to get reminders 15 days early so it's actually 75 days. Only at AWS, they don't force you into the password rotation flow at the end of the 90, they automatically lock the account. While that might make sense for inactive accounts, for accounts that have clicked the Not Now for 14 days should be taken to a change password screen instead. /rant
I thought I would make it through the day without seeing "non human identity" in a security company pitch, I was wrong.
Not much to say about this article except that it's one more in a long trend of security startups hyping bugs to attract business.
I'm not loving how they claim it's MFA bypass when it's really brute force, though I wouldn't necessarily minimize the attack overall either, I'm more curious how widespread these kinds of timeout bugs might be in other places.
Readit News
This could have gone unnoticed for years as so many cloud provider gaffes do. It's unlikely that anyone would think "Hey let's try brute forcing the login today". This violates trust-but-verify. You accept their say-so and so you're fully delegating trust. And because you're paying thousands of bucks for a service you assume it must be good. That's the very model of a (con)fidence trick. You don't even know you bought a lemon until its too late.
There's no substitute for having someone qualified and educated in cybersecurity with that as their full-time job - and better yet bring your critical assets back on-prem with some kind of hybrid setup. Big cloud is really eating at the McDonalds of cybsersecurity.
I think that Microsoft is getting away easy here with Oasis publishing the vulnerability report. If Microsoft published the report it would be incumbent upon them to include information about what they did to discover whether this happened before Oasis reported the problem.
One wonders how many Azure accounts might have been compromised and are even now allowing data to be exfiltrated.
I would rather trust a company with x persons working on security than one person.
Yes Big Company Microsoft got this one wrong (and also some other), but how many did they right? It’s always easy to be mad at failure if we overlook the times where something was done right.
No. Perhaps counter-intuitively the "problem" isn't trust here.
What I'm raising above is not the necessity to trust but the extent to which verification is possible or frustrated. For example, with open versus proprietary code you may or may not have the capacity to audit it, but you always have the possibility.
> I would rather trust a company with x persons
Trustworthiness does not scale in this way. Though the "many eyes" theory has some weight, we also say "two people can keep a secret if one of them is dead." Assigning more cooks to the broth yields rapidly diminishing returns for reasons Fred Brooks explains [0].
But that is not my strongest objection. A more serious reason not to trust a BigTech company with your security is the "principal agent problem" [1]. As Ross Anderson puts it; "If Alice guards a system and Bob pays the cost of failure, you can expect trouble!" [2]. Microsoft does not "pay the price".
Worse, Google (and Meta, Linked-In etc) base their business model on your insecurity - they are primarily in the business of acquiring data about you to use in selling your person to advertisers. They are therefore motivated, however weakly, against your actual security. It's a scandal that such companies also act as data processors and suppliers of services like online storage.
So while you can outsource trust, you cannot unload responsibility to verify. A solution is education based on a credo of "principles not products" [4].
[0] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
[1] https://en.wikipedia.org/wiki/Principal-agent_problem
[2] https://www.csail.mit.edu/news/dertouzos-distinguished-lectu...
[3] https://techrights.org/n/2024/09/25/Technology_rights_or_res...
[4] https://cybershow.uk/blog/posts/principles
Of course, the vault where those accounts are stored is a complete enterprise product with associated usability so what ends up happening is that people copy their passwords to an Excel sheet, or worse to Windows sticky notes, which often get up getting screen-shared in Teams calls.
A security company should know this. It's been strictly recommended against in the NIST guidelines (and others) for nearing a decade now. I start to really question the expertise of any security company that parrots this outdated advice. What else are they not keeping up on?
Focus on monitoring, alerting, educating, etc. Force password changes only when there are indicators of compromise.
Every few months we need to change our password. It cannot be a previously used password. It needs uppercase, lowercase, number, special character and minimum 12 characters. We have 2FA that is easily bypassed by going offline then back online once through login. We have 4 different active security suites running on our machines, and mandatory biweekly virus scans, at 10am (which cannot be changed). Every standard 16GB machine runs on it's knees all day long. But at least you can skip 2fa by turning off wifi real fast.
With no need to memorize passwords, you can change them as often as you fancy.
This is all that matters, regardless of whether a password manager is used or not.
Users should be able to change their own password (almost) whenever they want.
But arbitrary forced password changes from the admin should not happen unless the account has indicators of being compromised (even if all of your users have a password manager).
Why would you avoid TOTP altogether? Yes, SMS OTP is insecure because SMS is insecure, but OTP itself is fine, unless I missed something?
With passkeys if someone gets remote control of your computer they have access to everything you setup a passkey for.
Typically people say “well full remote control is far less common than phishing”, and it is, for now, until everyone’s using passkeys and all of the sophisticated phishing attack effort just shifts to passkeys.
The obvious weak point here is all of the outsourced IT who aren’t specifically focused on cybersecurity. Every IT company is using multiple tools for central management that either allows remote control or remote execution, or there’s always in-house developers who realistically aren’t doing a security analysis of every third-party library they’re installing.
Hopefully that is not the case now though, and I am surprised the advice has persisted... (though outdated gov standards probably played a part until recently)
My actual password choices are secure, memorable, and available even if I lose my phone or password manager. The counter is just an annoyance.
I can't because there is generally a limit to how many passwords it checks for previous use. So you can usually just start back at "1" for the increment after you hit "0".
And yet it is still the recommended practice for every IT department for pretty much all corps. Even AWS has their forced 90 password reset policy where you start to get reminders 15 days early so it's actually 75 days. Only at AWS, they don't force you into the password rotation flow at the end of the 90, they automatically lock the account. While that might make sense for inactive accounts, for accounts that have clicked the Not Now for 14 days should be taken to a change password screen instead. /rant
This is a policy set by the organization. You can easily change it to longer in IAM (or disable it entirely).
Not any that I or my colleagues consult at.
Deleted Comment
Not much to say about this article except that it's one more in a long trend of security startups hyping bugs to attract business.
I'm not loving how they claim it's MFA bypass when it's really brute force, though I wouldn't necessarily minimize the attack overall either, I'm more curious how widespread these kinds of timeout bugs might be in other places.
Deleted Comment
Deleted Comment
Dead Comment