Secure Passwords

Secure Passwords

Passwords remain one of the most common authentication methods used by websites,
applications and online services. Although stronger authentication technologies
such as passkeys and multi-factor authentication are becoming increasingly
important, passwords are still widely used.

For cybersecurity professionals and developers, understanding how passwords
should be created, stored, verified and recovered is essential.

1. What Is a Password?

A password is a secret value supplied by a user to prove control of an account.
When a user logs into a system, the application compares the supplied password
against a securely stored representation of the user’s password.

A properly designed application should never need to know the user’s original
password after account creation.

2. Password Security Has Two Sides

Password security involves both the user’s behaviour and the application’s
implementation.

• Users should choose strong and unique passwords.
• Applications should store passwords securely.
• Applications should verify passwords safely.
• Password reset processes must also be protected.
• Authentication should be protected against automated attacks.

3. Hashing vs Encryption

Hashing and encryption are not the same thing.

Hashing

Hashing converts data into a value that is designed to be computationally
difficult to reverse.

Password storage should use a dedicated password hashing algorithm rather than
storing the original password.

Encryption

Encryption is designed to protect information that may need to be recovered
later using a key.

Passwords normally do not need to be recovered. They only need to be verified.
Therefore, passwords should normally be hashed rather than reversibly encrypted.

4. Never Store Passwords in Plaintext

Plaintext password storage means that the original password is stored directly
in the database.

This is extremely dangerous because anyone who obtains the database may
immediately obtain the users’ passwords.

If users reuse passwords on other websites, a database breach can also affect
their other accounts.

5. Password Hashing

A password hash is a specially generated representation of a password.
A secure password hashing function is intentionally designed to be expensive
enough to make large-scale password guessing more difficult.

Modern applications should use password-hashing APIs provided by their
programming language or framework instead of attempting to design their own
hashing algorithm.

6. Salts

A salt is a unique random value incorporated into password hashing.

Salts help prevent attackers from efficiently using precomputed password
tables against large collections of password hashes.

Modern password-hashing functions normally generate and manage salts
automatically. Developers should therefore use the standard password API
instead of manually implementing salt generation unless there is a specific
and well-understood reason.

7. Adaptive Password Hashing

Password hashing should be computationally expensive enough to slow down
automated guessing attacks.

Adaptive algorithms allow the computational cost to be adjusted as hardware
becomes more powerful.

Examples of password-hashing technologies include Argon2, bcrypt and the
password hashing mechanisms provided by modern programming languages.

8. PHP password_hash()

PHP provides password_hash() for securely generating password hashes.

The function automatically handles important details such as salts and
algorithm parameters.

<?php

$password = 'Example-Strong-Passphrase';

$stored_hash = password_hash(
    $password,
    PASSWORD_DEFAULT
);

9. Verifying Passwords with password_verify()

When a user logs in, the application should compare the supplied password
against the stored password hash.

PHP provides password_verify() for this purpose.

<?php

if ( password_verify( $submitted_password, $stored_hash ) ) {

    echo 'Authentication successful.';

} else {

    echo 'Authentication failed.';
}

Developers should not attempt to decrypt password hashes or compare password
strings manually.

10. password_needs_rehash()

Password hashing requirements can change over time.

PHP provides password_needs_rehash() so applications can determine whether
an existing password hash should be regenerated using updated parameters.

<?php

if ( password_needs_rehash( $stored_hash, PASSWORD_DEFAULT ) ) {

    $new_hash = password_hash(
        $submitted_password,
        PASSWORD_DEFAULT
    );

    // Store the new hash in the user's record.
}

11. Passwords Should Not Be Reversibly Encrypted for Database Storage

A common misunderstanding is that passwords should be encrypted so that the
application can decrypt them later.

This is generally unnecessary and dangerous.

The application should be able to verify whether the supplied password matches
the stored hash without recovering the original password.

12. Strong Passwords and Passphrases

Users should use passwords that are difficult for attackers to guess.
Length is an important factor.

Long passphrases can be easier for humans to remember while still providing
strong resistance to guessing.

Applications should avoid unnecessarily restrictive password rules that force
users into predictable patterns.

13. Password Reuse

Password reuse is dangerous because one compromised service can expose the
user’s other accounts.

Users should use unique passwords for important services.

Password managers make this practical because users do not have to remember
every unique password manually.

14. Password Managers

A password manager can generate and store unique passwords.

A good password manager can help users avoid:

• Password reuse.
• Short predictable passwords.
• Writing passwords in insecure locations.
• Using the same password across multiple services.

15. Breached and Common Password Screening

Applications can prevent users from choosing passwords that are known to be
extremely common or compromised.

Examples include passwords based on:

• Common words.
• Names.
• Dates.
• Popular passwords.
• Previously breached credentials.

Password screening should be implemented carefully so that it does not expose
the user’s password to unnecessary third parties.

16. Multi-Factor Authentication

A password is only one authentication factor.

Multi-factor authentication adds another independent factor, such as:

• Something the user knows.
• Something the user has.
• Something the user is.

Examples include authenticator applications, security keys and biometric
authentication.

MFA significantly improves account security because stealing the password alone
may not be enough to gain access.

17. Password Reset Security

A secure password system must also provide a secure password-reset process.

The password-reset mechanism should not become an easier way to take over an
account.

Reset links should use unpredictable, single-use tokens with appropriate
expiration.

Applications should avoid revealing whether a particular email address or
username exists.

18. Security Questions

Traditional security questions can be weak because answers may be publicly
discoverable or easy to guess.

For example, questions about a user’s birthplace, favourite colour or pet may
have answers available through social media or other public sources.

Modern account recovery should prefer stronger verification methods.

19. Recovery Codes

Recovery codes can provide users with a backup authentication mechanism when
they lose access to their primary MFA device.

Recovery codes should be treated as sensitive secrets and stored securely.

20. Rate Limiting

Authentication endpoints should be protected against automated password
guessing.

• Rate limiting.
• Progressive delays.
• Login attempt monitoring.
• Bot detection where appropriate.
• Multi-factor authentication.

Security controls should be designed carefully so that attackers cannot easily
use them to deny service to legitimate users.

21. Never Log Passwords

Passwords should never appear in application logs, debugging output,
analytics systems or error reports.

Developers should review logging systems carefully because sensitive information
can accidentally remain in production logs.

22. Service Accounts and API Secrets

Applications may also use credentials that are not associated with normal
human users.

• API keys.
• Database passwords.
• Cloud service credentials.
• Application secrets.
• Third-party integration tokens.

These secrets should not be hard-coded into public source code.

Environment variables or secure secret-management systems should be used where
appropriate.

23. PHP Application Password Flow

A secure PHP authentication process generally follows this pattern:

1. User submits a username and password over HTTPS.
2. The server identifies the account.
3. The server retrieves the stored password hash.
4. password_verify() checks the submitted password.
5. The application establishes an authenticated session if verification succeeds.
6. The application may rehash the password when necessary.

24. Secure Login Flow

• HTTPS.
• Secure session cookies.
• HttpOnly cookies.
• SameSite cookie settings.
• Session regeneration after authentication.
• Rate limiting.
• MFA.
• Secure logout.

25. WordPress Password Security

WordPress provides its own password APIs and authentication mechanisms.
Developers should use the WordPress APIs instead of creating custom password
storage mechanisms.

For example, WordPress provides functions such as wp_hash_password() and
wp_check_password() for password handling.

Custom plugins should avoid directly storing plaintext passwords.

26. Secure Password Checklist

• Never store plaintext passwords.
• Use a modern password hashing API.
• Use unique salts through the standard password API.
• Use adaptive password hashing.
• Use password_verify() for verification.
• Use password_needs_rehash() when appropriate.
• Encourage unique passwords.
• Support password managers.
• Consider breached-password screening.
• Use MFA.
• Secure password-reset processes.
• Rate-limit authentication attempts.
• Never log passwords.
• Protect API keys and service credentials.
• Use HTTPS for authentication.

27. Practical Authorized Lab

For this exercise, create a small PHP authentication demonstration on your
local development machine.

The objective is to understand secure password hashing and verification.
Do not test authentication attacks against systems that you do not own or
do not have explicit permission to test.

Create a test password, hash it with password_hash(), store the resulting hash,
and verify the password with password_verify().

Then test an incorrect password and confirm that authentication fails.

28. Common Password Security Mistakes

• Storing passwords in plaintext.
• Using reversible encryption instead of password hashing.
• Using fast general-purpose hashes for password storage.
• Creating custom password hashing algorithms.
• Logging passwords.
• Reusing passwords across services.
• Using predictable password-reset tokens.
• Failing to protect login endpoints against automation.
• Hard-coding API secrets in source code.
• Ignoring MFA.

29. Secure Password Example

<?php

$password = 'Example-Strong-Passphrase';

$stored_hash = password_hash(
    $password,
    PASSWORD_DEFAULT
);

$submitted_password = 'Example-Strong-Passphrase';

if ( password_verify( $submitted_password, $stored_hash ) ) {

    if ( password_needs_rehash( $stored_hash, PASSWORD_DEFAULT ) ) {

        $new_hash = password_hash(
            $submitted_password,
            PASSWORD_DEFAULT
        );

        /*
         * Store $new_hash in the user's record.
         */
    }

    echo 'Authentication successful.';

} else {

    echo 'Authentication failed.';
}

30. Key Takeaways

• Passwords should never be stored in plaintext.
• Password hashing is different from encryption.
• Modern password APIs handle salts and hashing parameters.
• Adaptive password hashing makes brute-force attacks more expensive.
• password_hash() should be used to create password hashes in PHP.
• password_verify() should be used to verify passwords.
• password_needs_rehash() can help applications upgrade old hashes.
• Users should avoid password reuse.
• Password managers help users maintain unique passwords.
• MFA provides additional protection beyond passwords.
• Password-reset systems must be secured carefully.
• Passwords should never be written to logs.
• API keys and service credentials must also be protected.
• Authentication should be performed over HTTPS.

31. Knowledge Check

1. Why should passwords not be stored in plaintext?
2. What is the difference between hashing and encryption?
3. What is the purpose of a salt?
4. Why should password hashing be computationally expensive?
5. What does password_hash() do?
6. What does password_verify() do?
7. Why might password_needs_rehash() be useful?
8. Why is password reuse dangerous?
9. How does MFA improve account security?
10. Why should passwords never be logged?

32. Practical Exercise

Build a simple local PHP login demonstration that:

1. Accepts a test password.
2. Hashes the password using password_hash().
3. Stores the hash in a local test variable or database record.
4. Accepts another password attempt.
5. Verifies it with password_verify().
6. Displays a successful authentication message for a correct password.
7. Displays an authentication failure message for an incorrect password.
8. Tests password_needs_rehash().

Perform the exercise only on your own local development environment or another
system where you have explicit authorization.

33. Summary

Secure password handling is one of the fundamental responsibilities of modern
web developers and cybersecurity professionals.

A secure application does not simply require users to create complicated
passwords. It must also protect password storage, verification, authentication,
sessions, password recovery and related secrets.

Developers should rely on trusted password APIs instead of inventing custom
cryptographic systems.

34. Final Principle

A password should be treated as a secret that the application verifies,
not a secret that the application needs to recover.

Secure password handling protects users even when attackers obtain application
data. Combined with MFA, secure sessions, rate limiting, secure recovery and
good development practices, password security becomes an important part of a
defence-in-depth strategy.