Passwords, passkeys, API keys, session tokens, recovery codes, and private keys are all used to prove identity or authorize access, but they are not interchangeable. Their security properties, lifetime, scope, and recovery options differ. Treating every credential as if it were just a password can lead to unnecessary exposure.
Passwords
A password is a reusable secret known by the user and verified by a service. Passwords are easy to understand but vulnerable to reuse, phishing, credential stuffing, and accidental disclosure. Unique passwords and multi-factor authentication reduce these risks. Persistent passwords belong in a password manager rather than chat history or personal notes.
Passkeys
Passkeys use public-key cryptography. The service stores a public key while the private key remains on the user's device or synchronized credential provider. The user normally unlocks the credential using the device's local authentication method. Because the private credential is not typed into a website, passkeys are designed to resist traditional phishing more effectively than passwords.
Passkeys are not something users should copy and send to another person. Access should be provisioned to each authorized identity instead.
One-time passwords and verification codes
Time-based codes and one-time verification codes are short-lived authentication values. Their brief lifetime reduces the window for misuse, but they can still be captured by phishing or social engineering. Never share a verification code with someone who unexpectedly asks for it.
Recovery codes
Recovery codes are often created as a fallback when a normal second factor is unavailable. They may bypass part of the normal sign-in flow, which makes them high-value credentials. Store unused recovery codes securely and share only the minimum required code if business recovery procedures require transfer.
See How to Share Recovery Codes and Backup Codes Safely.
API keys
An API key commonly identifies an application or authorizes programmatic access. Some keys have broad privileges and long lifetimes. Others can be scoped to specific services, actions, IP ranges, or environments. API keys should not be committed to source code or pasted into tickets. Use environment-specific secrets storage and rotate keys after suspected exposure.
Access tokens
Access tokens are commonly issued after authentication and used by an application to call an API. Many tokens expire automatically and may be limited to a defined set of permissions. A short-lived token can still be powerful while it is valid, so it should be protected from logs, browser history, debugging output, and chat systems.
Refresh tokens
Refresh tokens can be more sensitive than short-lived access tokens because they may be used to obtain new access tokens. A password change does not always invalidate every refresh token or active session, so incident response may require explicit session or token revocation.
Private keys
SSH keys, signing keys, and other private cryptographic keys should normally remain on controlled devices or in secure key-management systems. Copying private keys between people weakens accountability. Prefer separate keys for separate users and revoke individual keys when access changes.
Choose controls based on the credential type
Long-lived reusable secrets require strong storage and rotation. Short-lived codes require protection against real-time phishing. Device-bound credentials should not be exported unnecessarily. Application credentials should be scoped and kept out of repositories and logs. The common principle is to reduce who can use the credential, what it can do, and how long it remains useful.