In software development and device administration, several best practices are often, perhaps due to ignorance, overlooked or avoided. Here are the issues we've observed recently:

When designing applications for clients or any public audience, storing passwords in BCrypt hashes with salt is advisable. Additionally, encrypt them based on available resources.

Here's a suitable security protocol to consider:

1. Validate passwords using the PwnedPasswords API.
2. Enforce a minimum security standard for passwords to prevent the use of dictionary words.
3. Utilize BCrypt, potentially with a strength greater than 10 (the default), especially if handling susceptible data.
4. Encrypt the resulting string using daily-generated keys stored separately.
5. Implement a two-factor authentication system that is manageable on email accounts, which can be easily compromised.

We encourage users to use a password manager. Consider a password logbook kept securely in a desk drawer for older individuals working solo at home.

Regarding system and device administrators: avoid changing passwords every three months! It's a flawed practice. I've seen even major corporations where administrators enforce such policies.

In cases where an account has been compromised and credentials exposed, attackers likely use that password immediately. Even if the credentials are exposed on day 89 since the last reset, it may save one user but confuses the rest.

A password should only be changed if there's suspicion of it being compromised. As previously noted, developers can assist in this matter by implementing an API like PwnedPasswords. If a password is found to be compromised, the system can suggest or force a password change or flag the account for closer monitoring.

Users not accustomed to storing sensitive information, like account credentials, in password vaults are most likely to:

1. Reuse passwords across accounts.
2. Generate similar passwords with minor character alterations.
3. Quickly revert to their original password, assuming policies allow older password reuse.

The U.S. Department of Commerce's National Institute of Standards and Technology rightly highlighted password guidelines in Special Publication 800-63B, updated in June 2017:

• Discourage periodic password changes unless a breach is suspected or at the account holder's discretion.
• Reevaluate complexity requirements (special characters, uppercase, and lowercase letters, numbers). I only partially agree with this.
• Enforce new password checks against a known list or dictionary. I suggest using a service like PwnedPasswords.

Avoid using the same password across multiple platforms. Using the same password for Facebook, iCloud, Instagram, etc., may seem convenient, but it's unsafe. If one account's credentials are compromised, it increases the risk for your other accounts. Generate a unique, complex password for each account and stick to it.

Activate two-factor authentication wherever it's offered.

If you suspect one of your passwords or accounts has been breached, confidently use the web application HaveIBeenPwned.

Application security and account protection are paramount for public-facing applications and should be addressed during the application's architecture design phase, not its conclusion.

In the decision-making process, it's essential to involve external perspectives beyond the "bubble" in which software developers/architects, or testers typically operate. For instance, public or limited-access beta sessions often provide invaluable feedback for improving user account security.

I wish you success in all your endeavors!