My guess is 2fa code apps. Why you ask? Because blizzard already did it. They use their own proprietary 2fa code generator app called battle net, so I have to use it. So after a few months/years of casually not using anything remotely connected with Mr. And Mrs. „Muttermilchknacker”

explanation

(A word derived from the „Panzerknacker” series of comics where the same named group of idiotic bandits try to break open a gold vault full of money, which I use since the scandal where someone stole the lactation bottle of someone working at Activision)

, I finally decided to try Overwatch 2 again, and when I tried to use my login app to confirm my login, I found myself logged out. And when I tried to log in again, I had to use the Authenticator, which I was logged out of, to use my authenticator, in order to log into the authenticator, in order to use the authenticator, in order to log into my authenticator (I could keep going like this forever)

  • Ravn@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    1 day ago

    My assumption was that the user sets the decryption password. Yes, if the decryption password is not your own then you may want your own password on top of that. The point was that there is in principle no reason for requiring the user to enter more than one personal password per session.

    • sylver_dragon@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      10 hours ago

      At most organizations I have worked at (both IT and cybersecurity), decryption keys will be centrally managed. With some technologies (e.g. Bitlocker), it’s possible to have multiple passwords which can be used to decrypt the drive, and it could be possible for the user to have one only they know. However, there isn’t a logging mechanism to verify which password was used to unlock the drive, leaving the issue of non-repudiation. This could probably be fixed by having some sort of system which logs which user unlocked the drive, but that would be a very hard thing to do securely. Any such log would need to be in a space the bootloader can reach and write to, and now that location needs to be secured in a way which prevents a malicious actor from modifying the log. At that point, we’re quickly arriving at having TPM and we might as well go whole hog and just do TPM and secure boot. Which is a great bit of technology; but, now only proves that the system hasn’t been tampered with.

      As a tangent, the reason most organizations centrally manage drive encryption keys is the need to unlock the drive, in the event the user is no longer able to. If you win the lottery, turn your laptop in and run off to parts unknown, the organization may want to unlock the laptop to recover anything you were working on. So, they need access to the decryption key.

      Ultimately the problem is that the encryption password and your user account password are solving different security problems and there isn’t a lot of good overlap between the two.