The mind boggles
How is brute forcing Office 365 passwords even possible, doesn't Microsoft use any mitigation system against it?
King's College London has suffered an IT worry but this time not of its own making – yesterday it warned staff and students that some accounts have been "compromised" due to an apparent brute-force attack on password systems. The Register has been informed that the raid, which has been ongoing for several days, originates in …
Of course there are mitigations against it. However Office365 supports a variety of older protocols as well as their own proprietary ones. As these get turned off on an account by account basis, it will cause small groups of users to suffer connection problems IF they happen to have set things up using the old way.
It's part of the everyday life of an IT admin now that your systems are going to be under attack from somewhere.
I dare say they do, but those brute forcing accounts don't hammer the same account from the same source address endlessly; the attacks are distributed across multiple source addresses and target multiple accounts.
If you have say 30,000 accounts to protect you will have predictable usernames, and at least 5% will pick really dumb passwords (easily guessable).
Far, far back in the mists of time, Aberystwyth university had a fairly simple technique for ensuring passwords were up to par. All they did was run Satan against the departmental password file (I did say this was a long time ago!) and any account thus compromised was immediately locked without warning.
Users affected by this would then have to do the shuffle of shame over to the helpdesk to reset their passwords, and be patronised by whichever foolhardy twerp pulled the short straw of telling the head of department of wherever that he'd just have to think of a longer name for his cat.
This all worked remarkably well.
But it hates spaces being at the beginning of a password. AD likes it, syncs that to azure ad which then breaks the users office 365 login as fucking office 365 doesn't like the leading space.
Fing annoying trying to work that one out, although didn't take long but, against best practice, I had to ask the user their password to find out that was the issue.
> Complexity requirements aren't infallible - the classic (outdated) example is "Password1" which
> meets the default complexity requirements of AD quite a while ago, but is definitely a weak
Not at all surprising. A bit more than thirty years ago I looked at security on a departmental server, using a well-known poular password brute force cracker algorithm, and found that most passwords were hopelessly insecure: there was a good batch of 4 or 5 character passwords using only alphabetic and numeric characters which were or course trivially breakable even then, and at the other extreme there were two occurrences of "qbttxpse2" which were the securest passwords (apart from mine) on the system.
Currently I use mostly 32 character passwords with alphabetic (including characters with marks like àèìòùáéíóúý«âêîôûçïñ» and the rest of the usual West European marked characters, and their capitalised versions, not just lower case) and numerics and some special symbols such as !"£$%^&*',./..,|\ except where the thing I'm connecting to won't allow some of those or won't allow cpasswords that long - but since I'm lazy, for some sites which now allow 24 characcters I'm still only using 16 because i can't be bothered to change them. Of course I don't remember all these, I have a password safe (with an access key of about 200 characters that I can remember) which is easier that remembering 50 of so of the individual passwords. Or course none of this is adequately secure, so for many connections I'm using two factor authentication as well.
Which would make sense except the important research data was in the folder BACKUP, not NO_BACKUP. In the case referred to, if you followed the rules, you lost. If you put your working data set onto the postdoc-built comedy home-brew setup, your heart only skipped the one beat and you could breathe a sigh of relief.
It might seem hard for some of us to comprehend that it wasn't the user's fault, and that the backup didn't backup, and that the backup of the backup also didn't backup... but that's what happened!
A good suggestion, with some flaws.
Assuming you turn on Modern auth for Mail, you severely reduce the amount of mail clients that support it. GMAIL: Nope. Any mac prior to 10.12. Nope. iOS 10. Nope. Virtually every mail client known to man on Android: hella nope. Just outlook.Nine supports Modern auth but enterprise version only.
To be fair, what MS call "Modern Auth" is just a standards compliant implementation of OAuth2, which was first published in 2012, and is used by loads of providers (including GMail).
If they'd stuck with some out of date protocol they'd have been slated for being insecure. If they mandated OAuth2 then people would complain about backwards compatibility with old software. Instead they allowed the email admins the choice, and get criticised for being both insecure and incompatible.
That explains a lot.
We just got new email rules from our corporate overlords. Email will now only work in Outlook, on company issued laptops (the heaviest shitiest of Dell's business models).
The result - our software team ignore corporate email and use Whatsapp among ourselves.
One day they are going to work out we never replay to email - but since 99% of emails are informing us of changes to the HR management structure of the widget group in the Azerbaijan subsidiary we can live without them
You just demonstrated that password complexity requirements do nothing - except to create passwords that are easy to forget. "Password" has been pawned over 3 million times, Pa55word about 14,000 times, P@55word about 2,000 times, but Dorwssap has never been pawned even once.
Regularly changing them isn't necessarily a good idea
If somebody steals them you can brute force them in minutes/hours on a GPU - it's not like they are going to work away at your password for months and so a 90day change will defeat them.
Requiring regular changes and no reuse generally means either post-it notes or Password101,102 etc
Yes, that's standard.
You get their passwords from a compromised site dump, check the password policy and increment as appropriate, plus any other leaked passwords from "the dark web".
Cyber Essentials doesn't require regular password changes for this reason.
Even GCHQ advise against regular password changes as they build false assurance.
Best defence is GOOD user education then MFA (avoid SMS as these can be diverted), after that again, GOOD user education, then a robust password policy, then sub 10 and ideally sub 5 failed attempts before account lockout.
Depending on the value of the account you may want the lockout to need sysadmin level human intervention.
Doesn't work very well when you have legitimate logins coming from China.
A more sophisticated approach is to look at locations from where the login comes from, and disallow logins that would require an unreasonable travel time (if someone logs in from the UK and within 2 hours an attempt is made from China, the second attempt isn't very likely to be legitimate).
It can also come from a compromised botnet not located in China, although the code may have been put on that botnet by someone in China. Or Romania. Or from any one or more of a hundred well known nation states with a reputation for dodgy goings on. Heck, I get a dozen injection probes an hour coming from places like Germany, Hungary, France, UK...
Biting the hand that feeds IT © 1998–2019