Why Do News Headlines Always Say "XX Company User Data Leaked"?

When you've learned how to create databases and JOIN data to generate reports, you might feel invincible, ready to take on client projects to build websites with membership systems.

Wait a minute!

If at this point, you simply add a column called password to your users table and store users' passwords (e.g., 123456 or iloveyou) in plain text, you'll be committing one of the most severe and unforgivable security sins in software engineering!

Imagine if your database gets hacked, or an internal employee (or even a recently departed engineer) peeks at the users table. They could directly see all users' passwords. Even scarier, about 80% of people use the same password for your website as they do for their Gmail, Facebook, and bank accounts. Once your site is breached, hackers can use these credentials to hijack all their online assets.

This is why we must never store "plaintext passwords" in databases.

The Magic of Passwords: One-Way Hash Functions

To solve this problem, cybersecurity experts worldwide invented a superpower called "One-way Hashing."

Here's how it works: When a user registers and enters a password like 123456, your website (e.g., Node.js or Python) won't store it directly in the database. Instead, the program throws this password into a "super blender" (a Hash Function, commonly using algorithms like bcrypt or SHA-256) to shred it.

After shredding, the output becomes a random, 60-character string like: $2b$12$eKx/n1Q1...

At this point, only this random string is stored in the database.

Why is it called "One-Way"?

Because this blender is irreversible. Even if the world's smartest hacker steals the $2b$12$eKx/n... string, they can't use any mathematical formula to revert it to the original 123456. (Just like you can't turn apple juice back into a whole apple.)

Then how do you verify passwords during login?

When the user returns to your site and enters 123456 to log in:

Your website fires up the blender again to shred the newly entered 123456.
Since the blender is designed so that "the same apple always produces identical juice."
Your website simply compares: Does this freshly blended juice match the one stored in the database?
If they match, the password is correct, and login is granted!

Throughout this process, your database never knows the user's actual password. This is the golden rule of modern authentication.

Hands-On: Implementing Bcrypt Password Encryption with Vibe Coding

If you were to build this blender from scratch, you'd need deep expertise in cryptography and mathematics. But in the world of Vibe Coding, it takes just one command.

Suppose you're developing a backend API with Node.js/Express. In Cursor, cast this spell:

【User Registration & Encryption Prompt】 I'm developing a user registration API. Please write a function to handle the registration logic. The flow is:

Receive email and password from the frontend.

Use the bcrypt library to add salt (salt rounds = 10) and hash the password.

Store the hashed string along with the email in PostgreSQL's users table.

Include full Try-Catch error handling and Chinese comments explaining Bcrypt's workings.

AI-Generated Fortress-Level Secure Code:

const bcrypt = require('bcrypt');
const db = require('./db'); // Assume this is your DB connection module

async function registerUser(email, plainPassword) {
  try {
    // Step 1: Set salt strength (Salt Rounds). Higher = more secure but slower. 10 is industry standard.
    const saltRounds = 10;
    
    // Step 2: Toss the plaintext password into the blender! This async operation returns the hashed string.
    const hashedPassword = await bcrypt.hash(plainPassword, saltRounds);

    // Step 3: Store ONLY the "hashed gibberish" in the DB—never the plainPassword!
    const insertQuery = 'INSERT INTO users (email, password_hash) VALUES ($1, $2) RETURNING id';
    const result = await db.query(insertQuery, [email, hashedPassword]);

    console.log(`Registration successful! User ID: ${result.rows[0].id}`);
    return { success: true, message: 'User registered successfully' };

  } catch (error) {
    console.error('Registration error:', error);
    return { success: false, message: 'Registration failed' };
  }
}

This AI-generated code meets the strictest industry security standards! Even if hackers steal your entire database, they'll only find useless $2b$12... gibberish.

JWT (JSON Web Token): The Post-Login Passport

After a user successfully logs in by matching their "blended" password, what happens next?

Should they re-enter their password for every action (e.g., accessing their cart or profile)? Of course not. Upon successful login, your server issues a "VIP Digital Pass". In modern web development, the dominant technology for this is JWT (JSON Web Token).

This pass is quietly stored in a browser corner (e.g., LocalStorage or Cookie). Thereafter, whenever the user makes a request (e.g., "Show me my cart"), the browser automatically attaches this pass to the request. The server simply verifies the pass is genuine (not forged or expired) and grants access, returning the cart data.

In Vibe Coding practice, you don't need to manually construct JWT strings either.

【Vibe Spell Prompt】: "Use the jsonwebtoken package to implement a login verification middleware. Issue a JWT token valid for 7 days upon successful login."

With password hashing and JWT passports, these two security moats form the foundation of all commercial full-stack apps. But in the final chapter, we'll introduce Supabase's ultimate defense weapon: RLS (Row-Level Security). It will completely redefine your understanding of database security!