Asklemmy

47854 readers

809 users here now

A loosely moderated place to ask open-ended questions

Search asklemmy 🔍

If your post meets the following criteria, it's welcome here!

Open-ended question
Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
Not ad nauseam inducing: please make sure it is a question that would be new to most members
An actual topic of discussion

Looking for support?

Looking for a community?

Lemmyverse: community search
sub.rehab: maps old subreddits to fediverse options, marks official as such
!lemmy411@lemmy.ca: a community for finding communities

~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~

founded 6 years ago

MODERATORS

If you had to ruin an entire app/website by integrating automatic logout, which app would you choose to achieve maximum damage? (lemmy.ml)

submitted 4 days ago by Luffy879@lemmy.ml to c/asklemmy@lemmy.ml

33 comments fedilink hide all child comments

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)

you are viewing a single comment's thread
view the rest of the comments

[–] BassTurd@lemmy.world 2 points 3 days ago (6 children)

I'm gonna have to disagree even though it is an annoying process listed above.

In this case there was a drive encryption password to prevent data theft if the device is stolen, OS login for user level access, a password keeper login at the application level, and MFA on a different app. That is 5 different auths (drive, os, pw keeper, email, MFA) for 5 unassociated objects managed by potentially 5 different entities. The only reason this was an issue was the dead phone for MFA, which is a user error. It super sucks that this is best practice because of bad actors, but this is baseline auth.

I am curious how you would do this differently though if you've got ideas. In this case, assuming the OS is Windows and email is Outlook, this could have all been handled with SSO, which would have only required the first two passwords, which is my daily work experience. However, I then get into Bitwarden and log into any not SSO apps I need and have MFA configured for all that support. I work remote a lot and my company is looking at an always VPN connection for everything. That would require me to go through another level or two of auth.

[–] sudoreboot@lemmy.ml 0 points 3 days ago (5 children)

If the device is encrypted and single-user there is no good reason to require further login after the first. If user is AFK then it locks, but then they should only need to type in that password. All this inconvenience is due to overlapping security practices that aren't designed together.

[–] sylver_dragon@lemmy.world 1 points 3 days ago (4 children)

If the device is encrypted and single-user there is no good reason to require further login after the first.

The reason is non-repudation. Ignoring the fact that the drive's encryption should have been handled by TPM and not be bothering the user, the drive encryption password does not establish who is using the laptop, only that they know the unlock password. Unfortunately, those unlock password are usually centrally assigned and managed, which means that they are not something that only the user knows. Also, it doesn't have a good second factor. If the laptop is stolen, there is nothing keeping an attacker out, if they know the password. Their account, on the other hand, should have a password only the user knows. Yes, central IT can reset the password, but this creates logs which show the reset and can be used to prove that the password was reset, and who reset it. And the user's password can be backed up with a second factor. So, a stolen laptop isn't an easy on-ramp to the organization's network.

As for logins after that, it gets harder to justify. OS, email and most web portal logins should be handled via SSO. For most users, this should mean that their drive gets decrypted via TPM, they type their password into the OS login prompt, deal with 2FA and that's it. For users with admin access to stuff, there will be a separate login step when they need to elevate permissions, but that should largely be limited to IT staff and developers. For the original poster, it sounds like their organization's IT is being run on a shoestring by someone who either doesn't know or isn't allowed to do it well.

[–] thepreciousboar@lemm.ee 0 points 3 days ago (1 children)

If a password is centrally assigned and managed it is not a safe passqword, regardless of other security measures

[–] sylver_dragon@lemmy.world 1 points 2 days ago

That depends on the use case. For drive encryption, a centrally assigned and managed password is fine. It provides for protection of data at rest while also ensuring that a single point of failure (the user) won't remove access to the data contained on the encrypted volume. Since it's not intended to prove identity, that risk needs to be mitigated by a different control.

load more comments (2 replies)