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.
Comments
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).
We aren't talking about just an offline password
"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.