How a Complete PHP Account Workflow Works

Registration, email verification and password recovery are connected parts of one account system. Registration validates the submitted identity, creates a password hash and inserts a user. Verification proves that the user controls the submitted email address. Password recovery allows the owner to set a new password without knowing the old one.

Each stage has a different security boundary. A registration form must prevent duplicate identities. A verification link must activate only the intended account. A password-reset link must not expose whether a user exists, remain valid forever or work more than once.

Database Uniqueness Must Protect Registration

Checking for an existing email before insertion improves the message shown to the user, but the SELECT is not the final protection. Two requests can run the same check before either request inserts its row.

A UNIQUE key on the canonical identity column makes the database the final authority:

UNIQUE KEY uq_users_email_canonical (
    email_canonical
)

The PHP code should catch the duplicate-key error and return a controlled response. Do not remove the UNIQUE key merely because the application received a duplicate-entry error. The error proves that the database prevented inconsistent account data.

Define One Email Comparison Policy

Preserve the address entered by the user for display and email delivery. Use a separate canonical value for comparisons when the project needs consistent lookup behavior.

Lowercasing the domain portion is a predictable basic policy. Provider-specific transformations such as removing dots or plus tags can incorrectly merge addresses when they are applied outside a provider the project controls.

function canonicalizeEmail(string $email): string
{
    $email = trim($email);
    $position = strrpos($email, "@");

    if ($position === false) {
        return $email;
    }

    $local = substr($email, 0, $position);
    $domain = substr($email, $position + 1);

    return $local . "@" . strtolower($domain);
}

Apply the same policy during registration, login, verification, password recovery and email-change workflows. Different normalization rules in different pages can make one account appear to be several identities.

Create Password Hashes, Not Password Encryption

Passwords should be checked later, not recovered and displayed. Registration and password-reset code should create a one-way password hash:

$passwordHash = password_hash(
    $password,
    PASSWORD_DEFAULT
);

Login should verify the submitted password against the stored hash:

if (
    password_verify(
        $submittedPassword,
        $storedPasswordHash
    )
) {
    // Password is correct.
}

Do not generate a second hash during login and compare the two hash strings. Modern password hashes include per-password data, so two valid hashes created from the same password do not need to be equal.

A password column such as VARCHAR(255) gives PASSWORD_DEFAULT room to change formats over time. A hash saved into a 32-character or 40-character legacy column may be truncated, making every later verification fail.

Use Random, Expiring and Single-Use Tokens

A verification or reset token acts like a temporary credential. Knowing the token should be sufficient to complete the specific account action, so it must not be predictable.

$rawToken = bin2hex(
    random_bytes(32)
);

Thirty-two random bytes become a 64-character hexadecimal token. The raw token goes into the email URL. A SHA-256 hash of that value goes into the database:

$tokenHash = hash(
    "sha256",
    $rawToken
);

When the link is opened, PHP hashes the submitted raw token using the same algorithm and queries for the resulting hash. A stolen token table then does not immediately reveal the working email links.

A valid token row should also include:

• The user ID it belongs to
• A purpose such as verification or password reset
• An expiration time
• A used timestamp or deletion policy
• A creation timestamp for abuse monitoring

Why a Token Can Exist but Never Match

The most common cause is comparing different representations. The email contains the raw 64-character token, but the database stores its 64-character SHA-256 hash. The endpoint must hash the URL value before querying.

Other common causes include:

• The URL uses code while PHP reads token.
• The token column truncates the stored hash.
• The verification endpoint searches for the reset purpose.
• The token was replaced by a newer request.
• The row is already marked as used.
• The expiry timezone differs from the query timezone.
• The email software modified a malformed URL.

Verification and Reset Tokens Need Different Purposes

Both workflows can use the same token table, but the row should include a purpose and every query should require it.

WHERE token_hash = :token_hash
  AND purpose = "password_reset"
  AND used_at IS NULL
  AND expires_at > UTC_TIMESTAMP()

Without the purpose condition, a token created merely to verify an email address could accidentally be accepted by a password-reset endpoint.

Do Not Reveal Whether a Recovery Account Exists

A forgot-password form should normally return the same public response whether the submitted email exists or not:

A response such as “No account uses this email” allows automated users to build a list of valid account identities. The application can still log internal outcomes and send an email only when an eligible account exists.

Recovery and resend endpoints also need rate limiting or cooldown controls. A public endpoint without limits can flood a user’s inbox and repeatedly replace a previously valid token.

Account Activation Should Match the Verification Rule

When verification is required, registration should not create a user who is already fully active. The project can use an account status or an email_verified_at timestamp.

email_verified_at DATETIME NULL,
status ENUM(
    "pending",
    "active",
    "disabled"
) NOT NULL DEFAULT "pending"

Login should require the appropriate verified or active state. The verification endpoint should update that state in the same transaction that consumes the token.

Password Reset Should Consume the Token Atomically

A reset endpoint should not update the password and leave the token valid. The token row should be locked, checked and consumed in the same transaction as the password update.

1. Validate the raw token structure.
2. Hash the token.
3. Begin a transaction.
4. Select the unused and unexpired reset row for update.
5. Validate the new password and confirmation.
6. Create a new password hash.
7. Update the user and increment an authentication version.
8. Mark the token used and invalidate other reset tokens.
9. Commit the transaction.

The user should then sign in through the normal login flow. Existing remember-me credentials and sensitive sessions should follow the project’s session-invalidation policy.

Send Links From a Configured Application URL

An email sent from XAMPP may contain a link such as http://localhost/project/reset-password.php. That address works only on the computer running the local server.

Store the deployment URL in private application configuration:

APP_URL=https://example.com

Build email links from that trusted value. Do not construct sensitive links directly from an unvalidated request Host header.

Registration and Email Delivery Are Separate Results

The user and verification token may be successfully stored even when the email provider temporarily fails. Treating those outcomes as one invisible operation can create confusing pending accounts.

A practical design commits the valid account and token, then attempts or queues the email. If delivery fails, the application logs the technical problem and provides a controlled resend-verification flow. Do not create duplicate user records every time email delivery is retried.

Safe Account Workflow Debugging Order

1. Inspect the exact submitted form names and request method.
2. Validate and canonicalize the email consistently.
3. Confirm the database UNIQUE email constraint.
4. Check the executed prepared insert and affected result.
5. Inspect the full stored password hash length.
6. Log the token length without logging the token itself.
7. Confirm raw-token versus token-hash handling.
8. Check purpose, expiry and used state in the token query.
9. Inspect the complete email URL and configured base domain.
10. Test verification and reset links once, twice and after expiry.
11. Test duplicate and simultaneous registration requests.
12. Verify session behavior after a successful password reset.

Continue Your CodeZips Project Workflow

Technical References

• PHP Manual: password_hash()
• PHP Manual: password_verify()
• PHP Manual: random_bytes()
• PHP Manual: bin2hex()
• PHP Manual: filter_var()
• PHP Manual: PDO::prepare()
• OWASP Forgot Password Cheat Sheet
• OWASP Email Validation and Verification Cheat Sheet
• MySQL Manual: CREATE TABLE and UNIQUE Keys