No, I'm saying you just say just search, and even those searches have to be manually sorted through. I'm simply pointing out even with filters you have to manually pick through the results to have a real filter. There are plenty below the top row that have open sides too.
If I could have gotten the boring cases that HP, Dell, and the others make, I would have. But other than system integrators, you can't really find stand alone plane cases.
When I put my new machine together not too long ago I actually went with the Define R5. The only part I couldn't get away from LEDs completely was the MB. I don't think I could find the solid Define7 at the time.
Looks like a test instance. URLs are read from the end to the beginning, so enterprise.lemmy.ml is a domain controlled by lemmy.ml. As that is the instance that the main developers control, it would follow they have a testing environment. In addition. Almost all the posts, users, and communities seem to have "test" as part of their name. It being the instance controlled by the developers is why lemmy.ml is always a link, while lemmy.world would need to be formatted as a link to get a link.
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.
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.
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.
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.
All I know is the mortgage servicing company I use seems to have started ~3 month interval, that they don't say (no second factor available either). When I went to pay my internet bill, I get greeted with a message "you're passwords been reset". I'm stubborn and I was just using those sites to pay bills, so now I just don't log in to those anymore.
Insurance, and government need to catch up to the research. For sites that support them, I really like the Yubikey as a second factor.
I don't think I've gotten past finding the correct length video. Getting that to work with everything else and keeping what's his face alive is just too much.
Mine went to once a year for most systems. There is probably an external requirement somewhere that says they need to be changed periodically and once a year is the lowest frequency they can do.
l_b_i @ l_b_i @yiffit.net Posts 6Comments 144Joined 2 yr. ago 
They used to.