Passwords

Protect Your Office 365 Accounts By Disabling Basic Authentication

This had been on my to-do list for a little while since I heard about it (mostly from Daniel Streefkerk who quite rightly has been drawing attention to this via Twitter, thanks!)– and it should be on yours too.

By default, Basic Authentication is allowed as an authentication method in Exchange Online. This is because that’s the ‘standard’ way things have worked for a very long time – you want to get your emails, you provide a username and password and you’re done.

In our modern world, that doesn’t work too well anymore. It’s too risky in that many ways, and things like 2FA and Conditional Access add an extra layer of security when logging in. That’s great, but many systems weren’t built or haven’t been updated to support this – they’ll just fail when logging in.

What this leaves us with, is an internet exposed authentication system that accepts username and password logins without any other layers of authentication, even if you have 2FA and conditional access turned on.

As per Microsoft’s documentation around disabling basic authentication covers, this lets attackers use brute force or spray attacks to try different credentials to get into your tenant. With the amount of leaks we see these days (register on Troy Hunt’s https://haveibeenpwned.com/ if you haven’t already), it’s likely attackers are hitting Microsoft servers with correct accounts of your staff members. If they manage to get the right password – which is very possible if people end up using an old password they used years ago, or password changes were disabled because you thought you were covered with 2FA – they now have valid credentials to get in and pretend to be that staff member, often to then send emails to all their contacts with a malicious link or some other scam.

If you want to see what’s going on for your tenant, go to the Azure portal and into Azure Active Directory > Monitoring – Sign-ins. Set the Status to ‘failure’ and apply, and see what’s there.

Here’s an example, where you can see the client app is ‘Other clients, IMAP’. This account is disabled, and if you look in the device info there’s no data.

Once you have a look here, you might start to get worried – so it’s time to see if you can disable basic auth!

Only certain email clients will work without basic auth, so your first step is to work out what people are using, and get approval to force the usage of only these:

  • Outlook 2013 or later (Outlook 2013 requires a registry key change)
  • Outlook 2016 for Mac or later
  • Outlook for iOS and Android
  • Mail for iOS 11.3.1 or later

That can be a tough ask, and you’ll need to weigh up the risk of leaving basic authentication in place (to me this is an easy choice, but can still be difficult to get approved and implement).

Again, the Microsoft documentation explains how to do this quite easily – create a new Authentication Profile which has Basic Auth disabled by default, and apply it to test users:

New-AuthenticationPolicy -Name “Block Basic Auth”

Set-User -Identity testuser@yourdomain.com -AuthenticationPolicy “Block Basic Auth”

Set-User -Identity testuser@yourdomain.com -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

That’s all you need to do to test. The third command forces an immediate refresh on the test user.

I would recommend leaving this in place for a while, and get as many test users on as possible as you might find certain systems using basic authentication that you weren’t aware of.

If you need to drop the policy off of a user, use this command:

Set-User -Identity testuser@yourdomain.com -AuthenticationPolicy $null

If you’re then ready to apply this policy to all accounts company wide, these three commands will do it:

$users = Get-User -ResultSize unlimited
$usersid = $users.MicrosoftOnlineServicesID
$usersid | foreach {Set-User -Identity $_ -AuthenticationPolicy “Block Basic Auth”}

You’ll also want any new accounts to get your new policy by default, which can be done with this command:

Set-OrganizationConfig -DefaultAuthenticationPolicy “Block Basic Auth”

And with that, you’ll have all existing and future accounts protected from the risks of leaving Basic Auth enabled. Of course if you have a special requirement where a few accounts do need Basic Auth, create another policy, enable basic auth on it, and apply it to those accounts. Your attack surface will still be greatly decreased, and hopefully you’ll eventually be able to disable basic auth on those too.

Why Haven’t You Deployed LAPS Yet?

LAPS – Local Administrator Password Solution is an official Microsoft solution for doing exactly what it’s called – managing local administrator passwords on the computers you manage (both desktops and servers).

The solution is fairly simple – have a tiny client rolled out on each PC, that gets told by Group Policy to generate a random password. The local admin account gets set to that password, and Active Directory also gets told what that password is. That changes on a 30 day cycle

The end result is that anyone who obtains local admin access through that account, can’t access anything beyond that single computer – and, that’s only for 30 days maximum before it gets changed. Even if the computer is taken off the domain, your Active Directory will have a record against the computer of what the last set password was.

There’s a great overview, demo, and install files available from TechNet with Jessica Payne going into great detail on how it all works and showing you exactly what to do which I highly recommend after watching it personally.

As she says, it only takes 10 minutes or so to set up, and it’s that much more secure than using Group Policy to set everyone’s local administrator account to the same password (which by the way, doesn’t securely save the password in the Group Policy anyway) and running into issues when someone needs the local administrator password for one reason or another.

Oh, there is a tiny AD schema update, but it’s a single command and nothing to worry about :)

Once you’ve got LAPS set up, you use the LAPS UI program to view passwords:

Chris Brown has also written up a nice ‘how-to’ guide on setting up LAPS from end to end which is worth following too.

LAPS is easy to deploy, easy to manage and provides several security benefits… and it’s free. If you’re not using LAPS yet, it’s time to do it! Grab it from Microsoft here.

My Solution to Online Password Management

Hello,
Today’s blogpost is about password management. I have (what I think) is a good solution that means you’ll only need to remember a few small details for all your online passwords.

An entirely unexciting topic for most – including myself. You’ve all heard and possibly uttered phrases such as ‘the longer the password the better’ and ‘use complicated passwords’ which are of course true. Here’s a blurb taken from Intel’s Supplier Password rules via https://supplier.intel.com/Auth/PasswordRules.asp :

In order to protect your security, Intel has certain rules for choosing passwords. Please read the following rules so that you will know how to choose a good password.
The following rules apply to all passwords:

  • The password must be at least 8 characters long.
  • The password must contain at least:
    • one alpha character [a-zA-Z];
    • one numeric character [0-9];
    • one special character from this set:
      ` ! @ $ % ^ & * ( ) – _ = + [ ] ; : ‘ ” , < . > / ?
  • The password must not:
    • contain spaces;
    • begin with an exclamation [!] or a question mark [?];
    • contain your login ID.
  • The first 3 characters cannot be the same.
  • The sequence of the first 3 characters cannot be in your login ID.
  • The first 8 characters cannot be the same as in your previous password.
  • Passwords are treated as case sensitive.

*yawn* Please don’t give up on this post yet, I do have a point to make! Now, the next commonly quoted rule is ‘never usethe same password on multiple sites’. So, how do you remember the wacky combination? XKCD has half the answer:

Via http://xkcd.com/936/

Great for a single password, but again how do we manage 100’s? Many people use databases such as KeePass, or notepad files inside encrypted zip files with another password on top. Cumbersome in my opinion, you don’t want to have to go checking for passwords each time you log in somewhere. There’s also other solutions that save the websites, usernames and passwords in a centralised location – a big risk in itself I say. So, here’s my two layer solution:

1) Have your own email domain, and use a different email address for every single site you sign up to. On top of that, make the email address something that always identifies with the site.

For example, I could buy the domain passwordssuck.com, set up Google Apps with it, and have a catch all. This means I can tell people I like an email address like “adam.fowler@passwordssuck.com” but also if I were to sign up for Blogger, I could use “blogger@passwordssuck.com”.

Why do this? The first reason is spam. If you sign up to a site that gets compromised, or sells off email addresses, the most likely impact to you is getting a bunch of spam. If you no longer use the site, you can blacklist the email address you signed up with (in this example, blogger@passwordssuck.com) and you’ll never see spam on that address again. If you still use the site, you’ll have to either live with the spam that gets by any spamfilters, or change your email address. I don’t like the idea of changing it, because for this overall formula (coming up!) to work, you just want to look at a site and immediately know what the login is.

The second reason – again if the site gets compromised, is that your email address and password combination are now useless anywhere else. Even if you used the same password anywhere, the email address to log in is a one off.

2) The password part. You need a formula. Once you remember the formula, you don’t need to remember anything else.

You can adjust this how you like, but I’ll give an idea of a decent formula (and no, this isn’t exactly what I use!). First, come up with two words. Let’s go with ‘keyboard’ and ‘mouse’. Now, let’s use some special characters. Now we have ‘K3yboard’ and ‘mou5e’ – these will never change.

Between our two words, let’s go back to the site we’re on. Blogger.com. What I’ll do is take the first and last letter of the domain. B and R. We’re going to put this in between our two chosen words. ‘K3yboardBRmou5e’ – but let’s get even trickier! Instead of B and R, we’ll go up two letters in the alphabet. B goes to D, and R goes to T.

Now we have ‘K3yboardRTmou5e’ as our final password. This means, when I go to blogger.com and think ‘hmm what’s my username/password’ it’s going to be “blogger@passwordssuck.com” and password “‘K3yboardRTmou5e'”.

Youtube.com? That’d be “youtube@passwordssuck.com” and “‘K3yboardAGmou5e'”

If someone obtained your credentials for Youtube, there’s no way these details will work anywhere else. If someone targets you specifically for some reason, they’re still going to need to know your formula. They have no idea which parts of your password are static, and which change, and even if they thought the AG was the bit that changed, they then need to work out what that means.

In summary, once you remember your formula, that’s the last thing you’ll need to remember. You don’t have to go down the full path of having a different email address for each site, but I’d put a bit more work into varying your password formula.

If you have any feedback on the above, or think it’s a terrible idea for any reason please let me know!