Author Topic: Microsoft RDP login with revoked PW  (Read 669 times)

0 Members and 1 Guest are viewing this topic.

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 9188
  • Country: de
  • A qualified hobbyist ;)
Microsoft RDP login with revoked PW
« on: May 02, 2025, 12:12:07 pm »
You can't make this up:
Windows RDP lets you log in using revoked passwords. Microsoft is OK with that. - https://arstechnica.com/security/2025/04/windows-rdp-lets-you-log-in-using-revoked-passwords-microsoft-is-ok-with-that/

They really care about security. :-DD I've lost any trust in Microsoft a long time ago as they are doing such stupid things over and over again, unable to learn anything from their mistakes. It's hopeless!
 

Offline dferyance

  • Regular Contributor
  • *
  • Posts: 225
Re: Microsoft RDP login with revoked PW
« Reply #1 on: May 02, 2025, 08:52:01 pm »
I agree with this being a security risk (provided I understand it correctly). But understand this is a difficult dilemma. When your authentication server is only accessible through an internet connection to a data center, you cannot reliably expect to always be able to communicate to it. Especially, if you cannot login to change your network settings.

Because the system may or may not be able to communicate with the authentication server, it may or may not know if your account has been changed or deleted. So it works off of a cache.

All this is solved by not putting your authentication server where you don't have guaranteed connectivity (cloud!). Either use local accounts or Active Directory (Kerberos / LDAP) over a LAN.
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 2446
  • Country: pl
Re: Microsoft RDP login with revoked PW
« Reply #2 on: May 03, 2025, 03:31:22 am »
Diarrhea from PR mouths is of course of no value here, so let’s skip Microsoft’s explanation. What could be the line of thinking behind this decision, though? I have three guesses.

One is that user-initiated password changes, with no administrators’ intervention, are mostly password change policies. From this perspective the password change is without any value, meaning there is no technical reason to make any changes. Just give people their illusion of control. An actual security breach would be handled by admins, who clear the local credentials cache.

Another is, that caches are caches for a reason. They are used to not poll upstream constantly. The removal of caches means additional, and in most cases pointless, load. It also means any network issue or misconfiguration cuts off everybody from the RDP. Timeouts may be implemented, but any reasonable timeout is almost useless with threat models observed in 2020s. I’m not saying I would vote for not changing that, because I probably would. But I can see it’s not a clear situation and I can understand reasoning behind taking a different option.

Finally, this may be an organisational issue. Changing the protocols may involve two independent developer teams. You know, how many levels each message would need to go up and down the chain of command, how many meetings would need to be held? ;)

I must also note, that nobody asked for customers’ opinions. I may value security, Wade may be security-focused, and so may you. But most people don’t share our beliefs, our values, and our mindsets. We see fixing a potential vulnerability. Customer ACME Inc. management sees a worker not being able to log in, causing $1M losses to the company.
Why 📎 | We live in times when half of people have IQ below 100.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->