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.
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.
That's called security.
How is it called if a compromised password can still be used to connect per RDP?
The only option is to use a 'reversible encryption'.
https://learn.microsoft.com/en-us/previous-versions/windows/...
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.
Maybe it's related to using the online account for local logins
- 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).
"Even after users change their account password, however, it remains valid for RDP logins indefinitely. In some cases, Wade reported, multiple older passwords will work while newer ones won’t."
Even if Windows knows the password is revoked and knows the new password, you can still connect with the old per RDP.
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.
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?
As for the article's stance: keep in mind RDP to any user account isn't necessarily automatically required to fix it. In general even, it's a tradeoff one makes when deciding between fail open and secure. There likely isn't a "right" and "wrong" answer here, neither approach is going to make everyone happy. Unsurprisingly, the security researcher is unhappy the needle doesn't lean more in the direction of security.
notnmeyer•9mo ago
pixl97•9mo ago
'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.