Files
Jiscuss/src/main/resources/db/migration/V2__security_updates.sql
T
2026-04-29 19:04:48 +08:00

34 lines
1.9 KiB
SQL
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
-- ─────────────────────────────────────────────────────────────────────────────
-- V2: Security hardening — password column expansion + BCrypt migration.
--
-- BACKGROUND:
-- The original schema used VARCHAR(20) for the password column, which is too
-- short to store BCrypt hashes (6068 characters). This migration:
-- 1. Expands the column to VARCHAR(255).
-- 2. Provides UPDATE statements to replace any remaining plaintext passwords
-- with BCrypt hashes (useful when applying this migration to an existing
-- database that has not yet been migrated).
--
-- NOTE: The example BCrypt hash below encodes the string '123456'.
-- For a real production migration, generate individual hashes per user
-- using a one-off script and run this migration during a maintenance window.
-- ─────────────────────────────────────────────────────────────────────────────
-- Step 1: Expand the password column so it can hold BCrypt hashes
ALTER TABLE user
MODIFY COLUMN password VARCHAR(255);
-- Step 2: Identify and log any users whose passwords look like plaintext
-- (BCrypt hashes always start with '$2a$' or '$2b$')
-- Run this SELECT manually before Step 3 to audit affected rows:
--
-- SELECT id, username FROM user WHERE password NOT LIKE '$2%';
-- Step 3: Replace all non-BCrypt passwords with the hash of a known reset value
-- ('changeme123' hashed below) and force a password reset via application logic.
-- Replace the hash value with one generated by your BCryptPasswordEncoder.
--
-- UPDATE user
-- SET password = '$2a$10$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
-- WHERE password NOT LIKE '$2%';