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.
Don't stop there. You can make some even greater efficiencies. By
having cyber-insurance you can do nothing and just have someone pay
you out money when you fuck up. There's no end of ways security
theatre and half-arsed "compliance" can help lower standards,
To be fair, if using insurance and risking being hacked anyway has a higher expected net payoff than implementing a given set of security measures, then you may be financially incentivized (or legally beholden to your shareholders) to take the risk, get hacked and pay any fines if it gets discovered. The security literature refers to it as "risk transference".
Chances are your company ultimately exists to optimize for shareholder value
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 run into issues where the password manager doesn’t update. And I also now have 4 managers (lastpass; chrome; edge; icloud keys) because of multiple platforms over the years.
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".
I just use a strong PascalCase passphrase (as strong as feasible if they have a stupidly short limit) and the year & month of the last password change. Something like `PascalCasePassphraseButRandomlyGeneratedProperly2024-12` for one this month. Fits many composition rules (those are also recommended against) by having uppercase, lowercase, numbers, and punctuation. Doesn't repeat previous passwords. And the entropy of the actual 7-word diceware passphrase is about 90 bits, which is pretty decent.
> 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
well congratulations to you. do you like to kick people when they're down to make yourself feel superior or was there another point to your comment? Great there's at least 3 companies that do not have this policy. That in no way negates all of the companies that do.
This is a really hostile comment. Sorry that your upset, but you don't need to take it out on me.
>or was there another point to your comment?
The purpose of my comment was to refute your claim that arbitrary password resets is the "recommended practice for every IT department for pretty much all corps".
Because it's not true.
>Great there's at least 3 companies that do not have this policy.
Between me and my colleagues we consult at dozens to hundreds of corporations per year. "At least 3" is pretty disingenuous.
do you honestly believe that i was unaware that there are companies that do not require the rotation policy? maybe the "pretty much all" phrase was confusing and you did not think that left room for some to not?
that's great that there are some companies that do not, but there are a great number of people that still do. it's not anything that needs rebutting as we're all aware they exist
>maybe the "pretty much all" phrase was confusing and you did not think that left room for some to not?
~90% or more of the companies we consult with do not have forced arbitrary password rotations when we start our engagement with them (~100% do not have it by the end of the engagement). We engage with dozens to hundreds of companies a year.
Does your definition of "pretty much all" actually mean "a small portion"? No wonder I was confused...
I'm looking at a sample of well over a thousand companies across multiple years where the vast majority (~90%) do not have a forced rotation and now ~100% of them do not. You can safely extrapolate that out to a general statistic.
Where are you getting your numbers from? What data are you reviewing?
So by your own comment there were thousands of companies that absolutely were still using rotation policies until they were blessed with your consultation.
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.
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.