Logins and paid memberships

The goal#

The tools site needed paid Pro memberships. We compared three approaches, reviewed the existing login system, chose to build on it in a way that can later be moved to WordPress, and created the first admin account with an editable profile and password recovery.

Part 1: storing passwords properly#

Never store a password. Store a hash: a one-way scramble. At login, hash what the person typed and compare.

The old system used PBKDF2 (150,000 rounds): secure, but stored in a custom format. New accounts use PHP's built-in password_hash() (bcrypt), because it's standard and WordPress can read it, which matters for migration.

$hash = password_hash($password, PASSWORD_DEFAULT);   // store this
password_verify($typed, $hash);                       // true / false at login

Part 2: login tokens#

After login, the server gives the browser a token so it doesn't need the password again. Ours look like:

base64(payload) . base64(signature)
payload = { sub, role, plan, exp, ... }
signature = HMAC-SHA256(payload, SERVER_SECRET)

• The signature proves the server issued it: change one character of the payload and the signature no longer matches.
• exp makes it expire (30 days for members).
• A token_version stored per member lets us log someone out everywhere: bump the number and every old token stops working. We do this automatically when a password changes.

Part 3: where is "Pro" decided?#

This was the most important finding of the review.

// in the browser
if (SGAuth.isPro()) showProTool();

The browser decided Pro from data stored in the browser. Anyone comfortable with developer tools could edit that and unlock Pro features without paying. Meanwhile the AI proxy was correctly checked on the server.

Part 4: payments without touching cards#

Never handle card details yourself. Stripe Checkout takes the card on Stripe's own page; your server only stores "this person is Pro until this date".

"Go Pro" ──► Stripe Checkout (card handled by Stripe)
                 │ webhook: "payment succeeded"
                 ▼
          your server: plan = pro, pro_until = end of period
"Manage billing" ──► Stripe Customer Portal (cancel, change card, invoices)

A webhook is Stripe calling your server when something happens (paid, renewed, cancelled). Your server must verify the webhook's signature, so nobody can fake a "paid" message.

Part 5: three ways to build memberships#

We chose A, built "migration-ready", so moving to B later is a data import, not a rebuild:

1. Email is the login name, which WordPress plugins expect.
2. Standard bcrypt hashes, which WordPress can read.
3. Billing lives in Stripe: store the customer and subscription IDs, so the same subscriptions keep working after a move.
4. Few simple plans: free, pro monthly, pro yearly.
5. One gate function, sgai_member_is_pro(): a migration changes only this.
6. CSV export of members from day one.

Part 6: password recovery done right#

• Same answer whether or not the email exists, so the form can't be used to discover who has an account.
• The reset link holds a long random token; the database stores only its hash, so a database leak doesn't expose working links.
• Links work once and expire in an hour.
• Rate-limited per IP so it can't be used to spam.

Key takeaways#

• Store slow, salted hashes (bcrypt), never passwords.
• Signed tokens prove who issued them; they don't hide their contents.
• Paid features: server decides, browser only displays.
• Let Stripe hold the cards; verify every webhook.
• Design for migration from day one: standard formats, one gate function, exportable data.

Quick quiz#

Try it yourself#