Safeguard
Application Security•

What are login credentials and how should they be protected?

Login credentials are what you use to prove who you are, usually a username and a secret. See NIST's current rules for passwords, MFA and storage.

Safeguard Security Team
4 min read

Login credentials are the information you present to prove your identity to a system: usually a username plus one or more authenticators such as a password, a code from an app, or a hardware key. Protect them with long unique passwords, multifactor authentication, phishing resistant options for important accounts, and safe storage on the server side.

What counts as a credential?

A credential has an identifier, such as a username or email address, and an authenticator, the secret or device that proves you control it. NIST SP 800-63B, the US digital identity guideline for authentication, organizes authenticators and sets assurance levels. At the second level it requires proof of possession and control of two distinct authentication factors, and requires that applications at that level offer a phishing resistant option. At the third level, it requires proof of possession of a key through a public-key cryptographic protocol.

What are the current password rules?

They differ from older habits, which is why many sites still get them wrong. In the NIST text I read, verifiers must require passwords used as a single factor to be at least 15 characters. Passwords used only as part of multifactor authentication may be shorter but must be at least eight. Verifiers should permit a maximum length of at least 64 characters and should accept all printing ASCII characters and Unicode.

Verifiers must not impose other composition rules, such as requiring a mix of character types, and must not require users to change passwords periodically, though they must force a change if there is evidence of compromise. NIST explains that analyses of breached password databases show the benefit of composition rules is less than once thought, with severe effects on usability and memorability. Passwords must be checked against a blocklist of commonly used, expected or compromised values. Verifiers must allow password managers and autofill, and should allow paste.

How should a service store them?

NIST requires that verifiers store passwords in a form resistant to offline attacks: salted and hashed using a suitable password hashing scheme. Passwords must be requested only over an authenticated, protected channel. The practical point for developers: never store a password in plain text, never log it, and never email it back.

Why is a password alone not enough?

Because credentials get stolen in ways password strength does not stop. CISA's small business guidance says phishing is consistently the most cost effective way for attackers to compromise systems, that any form of MFA is better than none, and that FIDO authentication is the widely available phishing resistant option, since it blocks a login attempt on an imposter site. A strong password typed into a fake page is still stolen.

A constructed example

A software company reviews its sign up form. It currently requires eight characters with a symbol, a number and a capital letter, and forces a change every 90 days. Users respond with "Summer2026!" and then "Autumn2026!". The team changes the policy to follow NIST: a 15 character minimum for password-only accounts, no composition rules, no scheduled changes, a check against a list of known compromised passwords, paste allowed, and a prompt to use a password manager. They also add passkey and security key sign in for administrators. Support tickets about forgotten passwords fall, and the passwords that do get set are longer.

How to check or apply this

  1. Use a password manager and a unique password for every account.
  2. Turn on MFA everywhere, starting with email, finance and administrator accounts.
  3. Use FIDO security keys or passkeys for the most exposed accounts.
  4. If you build login systems, follow NIST SP 800-63B: minimum length, no composition rules, blocklist checks, no forced rotation, allow paste.
  5. Store passwords with a salted, slow password hashing function, never plain or fast hashes.
  6. Force a reset when you have evidence of compromise.
  7. Look for credentials in code, logs and config files. Rotate any you find.
  8. Monitor for impossible travel and repeated failed logins, and rate limit login attempts.

Safeguard's dependency scanning covers the authentication libraries you ship.

Quick check

Should passwords expire every 90 days?

Not under NIST SP 800-63B. Verifiers must not require periodic changes, but must force a change if there is evidence of compromise.

Is SMS MFA better than nothing?

Yes, per CISA, which says any MFA is better than none. For high risk accounts, choose a phishing resistant method such as FIDO.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.