this post was submitted on 06 Dec 2023
151 points (96.9% liked)

[Outdated, please look at pinned post] Casual Conversation

6590 readers
1 users here now

Share a story, ask a question, or start a conversation about (almost) anything you desire. Maybe you'll make some friends in the process.


RULES

Related discussion-focused communities

founded 1 year ago
MODERATORS
 

These are the same companies that don't support second factors, only have their app as a second factor, or only SMS second factor. Is it too much to ask for smart card or token (yubikey) support?

you are viewing a single comment's thread
view the rest of the comments
[–] l_b_i@yiffit.net 6 points 11 months ago (2 children)

A password manager does nothing to stop Social engineering and human factors on the provider side.

[–] lurch@sh.itjust.works 1 points 11 months ago (1 children)

wdym by "provider side" in this context?

[–] l_b_i@yiffit.net 0 points 11 months ago (1 children)

As an example, if you have an online account with some bank. That bank would be the provider.

[–] lurch@sh.itjust.works 1 points 11 months ago (1 children)

Well yes, me and the bank employees using a password manager does not stop social engeneering and human factors, but it limits the access of the attacker to the time period of the forced password change. If the attacker changes it, he is found out immediately, because the bank employee loses access. When the password expires the bank employee generates a new random password and the attacker loses access. Of course, using OTP features or a security token is better and narrows the attack window even more.

[–] l_b_i@yiffit.net 0 points 11 months ago (1 children)

I don't think you're following.
First, you are an account holder in my answer not an employee.
Second, the reason its an issue has nothing to do with the actual password or password security. Frequent changes lead to simpler passwords. Someone is likely just to increment a number, so a new password is barley a hindrance if the previous one is compromised. Frequent changes are going to lead to more password resets, service personnel who have to deal with people forgetting passwords due to frequent resets/ changes are more likely to be complacent allowing an attacker to gain access through a reset. For company based passwords, frequent changes and high complexity requirements are more likely to lead to someone writing a password down near where that password is used.

[–] lurch@sh.itjust.works 0 points 11 months ago

No, you're not following. (I assumed I was an account holder in that example, but it's not important.)

Someone is likely just to increment a number, so a new password is barley a hindrance if the previous one is compromised.

Not if they use a password manager and click a button to completely randomize a new password. They do not have to worry they forget it, because they only have to memorize their master password.

KeePass Password Generation Options

Why would someone who was told to hit that button by IT increment a number instead?

[–] aodhsishaj@lemmy.world 0 points 11 months ago (1 children)

Just automate it and gate it behind a strong passphrase and 2 factor the vault you use

https://github.com/Bubka/2FAuth

https://www.makeuseof.com/what-is-password-vault/

https://nerdschalk.com/8-best-self-hosted-password-managers/

https://www.hashicorp.com/resources/painless-password-rotation-hashicorp-vault

I know hashicorp has ruffled some feathers with the new terraform licensing but vault is still free and self hosted.

[–] l_b_i@yiffit.net 3 points 11 months ago (1 children)

I think your missing the point. It doesn't matter how good an individuals security practices are if the system itself has bad security architecture.

[–] lurch@sh.itjust.works 1 points 11 months ago (1 children)

So in your post you refer to, for example, an admin at microsoft headquarters having to change his password, not the user of one of microsofts services being forced to change their password?

[–] l_b_i@yiffit.net 1 points 11 months ago (1 children)

I am generally more annoyed at the second bit, the user having to change their password. Both are problems, but internal policies for changes are usually documented and communicated.

[–] lurch@sh.itjust.works 1 points 11 months ago (1 children)

Having to change the services password is just a few buttons in the password manager, but it helps mitigating brute force attacks and limits the attackers access to the validity period of the password. So that's very beneficial.

[–] l_b_i@yiffit.net 1 points 11 months ago

It doesn't matter how good an individuals security is, its the system that's a problem. Passwords are not often compromised through brute force. Password resets are a much more efficient entry method.

https://pages.nist.gov/800-63-FAQ/#q-b05

Q-B05: Is password expiration no longer recommended? A-B05:

SP 800-63B Section 5.1.1.2 paragraph 9 states:

“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.

Q-B06: Are password composition rules no longer recommended? A-B06:

SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets. These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a ! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack.

Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize.