• dblsaiko@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    56
    arrow-down
    2
    ·
    14 days ago

    Their stated reasoning here sounds bullshit and I’m sure the actual reason is a technical one, where they’re trying to retrofit the MS accounts login system to a protocol that wasn’t designed for it and for some reason are refusing to extend the RDP protocol to support the new auth mechanism. SMB network shares probably have the same issue I’d assume.

    I’m sure AD domains don’t have this problem since it uses Kerberos, otherwise this would have been a problem already decades ago.

    Using the password for a public account for local login is a disaster anyway, they should have done it like Apple and kept the local login password separate from the MS account login. I have never used a MS account for local login but it sounds to me like it just leads to people using insecure passwords for publicly reachable accounts because they don’t want to type a long password every time logging into their computer.

    • adrian@50501.chat
      link
      fedilink
      English
      arrow-up
      22
      ·
      14 days ago

      I have never used a MS account for local login but it sounds to me like it just leads to people using insecure passwords for publicly reachable accounts because they don’t want to type a long password every time logging into their computer.

      I guess that’s what the PIN feature is for, even though you’re Personal Identification Number can have letters…

      • dblsaiko@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        7
        ·
        14 days ago

        Oh, so that’s what that’s for. I’ve seen it before but never got the reason for it, but combined with this it makes sense. The name is very unfortunate though.

        Now, the question is, will the cached RDP password update when you log in with the PIN :)

        • TheRealKuni@midwest.social
          link
          fedilink
          English
          arrow-up
          3
          ·
          13 days ago

          The real reason for PIN login is so you can login quickly with just the numpad, even if you have to edit the registry on your work laptop to enable it. /cough

        • fluxion@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          13 days ago

          If I’d known that i wouldn’t have set a pin that’s longer than my normal login

  • taladar@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    27
    ·
    14 days ago

    So if I understand that correctly that cache is never updated again after it is initially created? Wouldn’t that lead to a lot of issues when the online account has its password changed in terms of the new password not working too? Something seems to be missing from this article.

    • Gibibit@lemmy.world
      link
      fedilink
      English
      arrow-up
      28
      arrow-down
      1
      ·
      14 days ago

      That is addressed in the article

      Even after users change their account password, however, it remains valid for RDP logins indefinitely. In some cases, [independent security researcher Daniel] Wade reported, multiple older passwords will work while newer ones won’t.

      • taladar@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        14
        ·
        edit-2
        14 days ago

        Yeah, but “some cases” is extremely vague. If it is indeed cached indefinitely under all circumstances I would expect changed passwords to never work at all.

        If it is just “some cases” it could be anything from the system using a stale cache just when it can not reach the online server (reasonable) over caches still being in some kind of TTL period to some sort of bug.

        • SL3wvmnas@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          4
          ·
          14 days ago

          In typical MS fashion this might be very hard to debug with the hundreds of interacting components./s

          In all seriousness they reviewed their internal docs not even the code (likely because it’s extremely complex) and said fixing this would brake existing functionality. I think “some cases” is doing heavy lifting for “we know many cases, but won’t tell the bad guys out there”.

      • SL3wvmnas@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        1
        ·
        14 days ago

        “We originally looked at a code change for this issue, but after further review of design documentation, changes to code could break compatibility with functionality used by many applications.”

        Year of the Linux (Server|Desktop). Seriously. If you are in IT pls look into this (and hide your RDP server behind some VPN. No not MS RDP Gateway.)

        • the_crotch@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          7
          ·
          14 days ago

          hide your RDP server behind some VPN

          Anyone who isn’t doing this already is dumb. Same goes for exposing ssh publicly. I don’t care that you’re using a cert to log in, if there’s a 0 day in the openssh server you’re boned

          • Max@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            13 days ago

            If there’s a 0 day in the VPN software then I’m also probably boned. The chances of that seem on par with the likelihood of an openssh vulnerability? I feel like vpns are useful to secure services without good authentication, but their use in front of an openssh server has never made much sense to me.

            • the_crotch@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              3
              ·
              edit-2
              13 days ago

              They would have to breach the vpn and then also breach the other services once they’re on your network. It’s another layer of protection.

  • GreenKnight23@lemmy.world
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    1
    ·
    13 days ago

    the real reason?

    Yeah… Bill Hinks used to be the guy that did that but the execs fired him and replaced him with AI. Now when we ask the AI to fix it, it just removes the password requirement entirely and lets anyone login as admin with the username “fuckyou”. I wish Bill was around but he won’t answer our calls and any emails we send him just get an auto-reply of “fuck you”.

  • fatalicus@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    ·
    13 days ago

    This case is just fantastic. Someone discovered Cached domain logins, something that has been around for years and years to solve an issue when networks were less stable and AD might not be available, and decided to make a stink about it, as if sysadmins aren’t already aware of it and know how to handle things like this.