Zerethon IDE
Sign in

Authentication and passwords

Intermediate 12 min read

Sign users in safely: hashed passwords, sessions or tokens, and checks on every request.

Why it matters

A leaked password table or a missing permission check is one of the most damaging and most common backend failures. The safe patterns are well known — the mistakes come from writing them from scratch.

Where it fits

  1. Plan & Design
  2. ● Develop › Backend
  3. Version control
  4. Verify
  5. Build & Package
  6. CI/CD
  7. Deploy
  8. Operate

What you will learn

  • Tell authentication (who you are) from authorization (what you may do).
  • Store passwords only as slow, salted hashes.
  • Check permission on the server for every request.

Before you start

Two different checks

  • Authentication — proving who the user is: password, a sign-in provider, a passkey.
  • Authorization — deciding what that user may do: "may this user read order 42?". Checked on the server, for every request, every time.
Example 
<?php
// Store: a slow, salted hash — never the password itself
$hash = password_hash($password, PASSWORD_DEFAULT);

// Verify at sign-in
if (! password_verify($attempt, $hash)) {
    // same message for unknown user and wrong password
}
PHP's built-in functions; every major language has an equivalent. Never invent your own hashing.
  • Passwords are hashed with a password-hashing algorithm (bcrypt, Argon2, scrypt), never MD5 or SHA-1.
  • Sign-in is rate-limited, and errors do not reveal whether an account exists.
  • Session cookies are HttpOnly, Secure and SameSite.
  • Every endpoint checks that the signed-in user may access that specific record.

Tip: Use your framework's authentication, or a single sign-on provider, before writing your own.

Official documentation and references

Documentation

Practise in Zerethon IDE

Learn next

Related topics

Done with this topic?

Reviewed 2026-10-23. Links go to the official documentation unless marked otherwise.