hckrnws

Two things can be true:

- This is not a bug; it is a design decision.

- Microsoft could still try.

This functionality is critical for offline access; in fact in some scenarios you may not be able to configure WiFi (or VPN) for Domain Access without first logging in. If the offline password didn't exist the machine would be inoperable.

Let's also acknowledge the fact that even if they try to address this, unplugging the network cable or otherwise interfering with connectivity would always fall back to offline credentials. You cannot simply invalidate them for reasons previously stated.

So now we're at the point where the fix is at best unreliable, and NOT even a hard security boundary. Yet they could still try. For example either phoning the mothership (e.g. AD, Microsoft Login, et al) on a regular schedule for a logged-in user and verifying offline credentials OR phoning the mothership during successful cached login (with aggressive timeouts).

There is actually precedent for this: UAC. UAC is also not a real security boundary, and is also unreliable. It is a "best effort" improvement. This would be of that nature, engineering effort to kinda-sorta make it better than nothing but trivial for a trained attacker to bypass.

But ultimately, this isn't a bug, and any improvements Microsoft makes will be similarly criticized (due to the trivially of bypassing them).

I'll take a look at this tomorrow, but it seems like a security researcher angling for a bug bounty.

Cached local credentials and saved rdp credentials have existed for a long time and both have gpo settings to modify/disable - you just don't do it because no caching requires some kind of sase/ always on vpn, etc. I think most systems have disallowed rdp credential saving for years.

Furthermore, how does one connect to the domain with an invalid password? I'm inclined to think this was tested on a workgroup and not a domain. If you go long enough your trust tombstones and you lose all access anyway, cached and saved or not.

Sounds like bollocks to me.

Your RPD password is your AD password and that is encrypted and salted (I think). There are some worrying extensions to MSAD but I don't think that unless you tick the box in ADUC that your password will be stored unencrypted, it will be stored unencrypted (hashed or whatever).

We need to understand what:

"...Microsoft said the behavior is a “a design decision to ensure that at least one user account always has the ability to log in no matter how long a system has been offline."

really means.

I'm a Linux jockey but I can't be arsed with nonsense like this.

> one user account always has the ability to log in no matter how long a system has been offline

To me, it's pretty clear.

Assume that every password has an expiration date. Having not logged in to the system long enough, you end up with a system where every password has expired. A relatively reasonable thing to do then is to accept some previously valid password, and direct the user to the password reset flow. Else you end up with a system that rejects every login.

A much more reasonable thing to do would be to accept rescue codes in this situation, of use 2FA so that passwords expiration is not needed. But I bet the security checklists used by some behemoth insurance companies predate these inventions, nobody wants to alter them, and companies who don't want to pay higher IT insurance premiums have to follow these outdated and inefficient practices.

> but I don't think that unless you tick the box in ADUC that your password will be stored unencrypted, it will be stored unencrypted (hashed or whatever).

The only option is to use a 'reversible encryption'.

https://learn.microsoft.com/en-us/previous-versions/windows/...

This is true for basically any AD windows login. If you log in with an account on a machine on your domain, then take that machine offline and change the password elsewhere- you can login with the old password.

If you instead restore network access after it’s been offline long enough - depending on the exact process it will still accept the old password. Entering the old password isn’t enough to trigger domain check in. However, if I recall correctly entering an incorrect password will cause the login window to hang for 30+ seconds while it attempts to perform such a check in to see if your password changed in the interim. This will usually fail - but not always.

It’s probably bad behavior but it’s probably configurable in the domain settings. But it makes the user experience terrible because logging in gets super slow, because domain syncs in azure/ Active Directory are super slow.

How is this offline if you're RDPing into it?

Offline can mean anything from "not able to connect to the internet" to "no networking active whatsoever" depending on the context. In this case, "not able to connect to AD for some reason".

> In this case, "not able to connect to AD for some reason".

Okay, but in that case, keeping the old cached passwords seems reasonable so you can log in and fix it. How do you avoid that?

"It's an older code, sir, but it checks out. I was going to let them through." https://www.youtube.com/watch?v=4HJ-Y8YTo8Q

This isn't working for me on an enterprise domain, I'm simply refused access. TFA doesn't link to any instructions either.

"The first time a user logs in using Microsoft or Azure account credentials"

Maybe it's related to using the online account for local logins

That is… insane. In what world is this expected or acceptable behavior?

There are 2 hard things in computer science. Naming things, cache invalidation, and off by one errors.

'Some' of this makes sense but not all of it.

For example let's imagine a linux password system that let's you take a system offline and still use it. You have to cache the password locally and if it doesn't connect to the online system where the password has changed then the old password will still work.

With that said you should also design the system to invalidate the cached password from upstream when it gets a notification it changed.