Password Hashing แก้ 6 ความเชื่อผิดเรื่องการเก็บรหัสผ่าน

เรื่องการเก็บรหัสผ่านเป็นหัวข้อที่ทุกคนเคยได้ยินคำตอบที่ถูกมาแล้ว ("ให้ hash อย่า encrypt") แต่คำตอบที่ผิดก็ยังโผล่มาให้เห็นอยู่เรื่อย ๆ ไม่ว่าจะเป็นคอลัมน์ชื่อ password_encrypted, SHA-256 แบบไม่มี salt หรือบรรทัดใน config ของ router ที่ดูเหมือนถูกเข้ารหัสแต่จริง ๆ แล้วไม่ใช่ ข่าวดีคือแนวทางเรื่องนี้ชัดเจนมากและอ่านได้ฟรี ทั้ง OWASP Password Storage Cheat Sheet, NIST SP 800-63B-4 และ RFC อีกสองฉบับ ครอบคลุมเกือบทุกอย่างแล้วครับ

โพสต์นี้จึงหยิบความเชื่อที่พบบ่อยมาทีละข้อ แล้วตรวจกับแหล่งข้อมูลเหล่านั้น หก myth หก fact และปิดท้ายด้วยเรื่องอุปกรณ์เครือข่ายที่หลายคนดูแลกันอยู่ทุกวันครับ

Myth 1: "Hashing กับ encryption ก็คือเรื่องเดียวกัน"

Fact: ทั้งสองแก้ปัญหาคนละแบบ และสำหรับรหัสผ่านที่ใช้ login เราต้องการแบบที่ย้อนกลับไม่ได้

Encryption ถูกออกแบบให้ย้อนกลับได้ ใครถือ key ก็ได้ plaintext คืนมา ส่วน hash เป็น one-way function โดย OWASP อธิบายไว้ตรง ๆ ว่า hashing เป็นทางเดียว จึงเหมาะกับการตรวจรหัสผ่าน ขณะที่ encryption เป็นสองทาง และใช้กับรหัสผ่านได้เฉพาะกรณีพิเศษที่ระบบจำเป็นต้องได้ค่าเดิมกลับมาจริง ๆ (OWASP, Hashing vs Encryption)

ลองนึกว่าการตรวจ login ต้องการอะไรจริง ๆ server ไม่จำเป็นต้อง รู้ รหัสผ่านของเราเลย แค่ต้องยืนยันว่าสิ่งที่เราพิมพ์ตอนนี้ให้ผลเหมือนกับสิ่งที่เราพิมพ์ตอนสมัคร one-way function ให้สิ่งนั้นพอดีและไม่ให้อะไรเกินกว่านั้น ในทางกลับกัน ตารางรหัสผ่านที่ถูก encrypt ไว้ อยู่ห่างจากการเป็นตารางรหัสผ่าน plaintext แค่ key รั่วครั้งเดียวครับ

มีข้อยกเว้นจริงอยู่ข้อหนึ่ง และควรพูดถึงเพราะ network engineer เจอเป็นประจำ คือ secret บางอย่างต้องถูก ใช้ ไม่ใช่แค่ถูกตรวจ เช่น shared secret ของ RADIUS หรือ TACACS+ หรือ key ของ routing protocol ซึ่งอุปกรณ์ต้องถอดกลับเป็น plaintext เพื่อนำไปใช้ เอกสารของ Cisco เรื่อง secret ที่เก็บในอุปกรณ์เรียกสิ่งเหล่านี้ว่า credential แบบ reversible ต่างจากแบบ non-reversible อย่างรหัสผ่าน login ที่อุปกรณ์แค่ต้องตรวจ (Cisco, Protecting Secrets on Cisco Network Devices) กฎจึงไม่ใช่ "ห้าม encrypt" แต่เป็น "อย่า encrypt สิ่งที่เราแค่ต้องตรวจ" ครับ

Myth 2: "SHA-256 แข็งแรงอยู่แล้ว ใช้กับรหัสผ่านได้"

Fact: SHA-256 เป็น hash ที่ดีสำหรับงานหลายอย่าง แต่การเก็บรหัสผ่านไม่ใช่หนึ่งในนั้น เพราะมันเร็ว

OWASP เขียนไว้ตรง ๆ ว่า hashing algorithm ที่เร็วอย่าง SHA-256 ไม่เหมาะกับการเก็บรหัสผ่าน และ password hash ควรช้า ต่างจาก MD5 และ SHA-1 ที่ถูกออกแบบมาให้เร็ว (OWASP, Introduction และ Password Hashing Algorithms)

ถ้า hash ย้อนกลับไม่ได้ ทำไมความเร็วถึงสำคัญ? เพราะผู้โจมตีไม่ได้ย้อน hash แต่ใช้วิธี เดา OWASP อธิบายวงจรนี้ไว้ว่า หยิบคำจาก wordlist, จากรายการรหัสผ่านที่รั่วจากเว็บอื่น หรือจากการ brute force มา hash แล้วเทียบกับ hash ที่ขโมยมา ทำซ้ำไปเรื่อย ๆ ทุกขั้นของวงจรนี้ถูกจำกัดด้วยความเร็วในการคำนวณ hash หนึ่งครั้ง hash ที่ออกแบบมาให้เร็ว ซึ่งก็คือสิ่งที่ hash ทั่วไปตั้งใจให้เป็น จึงเป็นของขวัญชั้นดีสำหรับวงจรนี้ครับ

         same time budget, very different cost per guess        
                                                                
 ┌─────────────────────────────┐ ┌────────────────────────────┐ 
 │ fast hash  (SHA-256)        │ │ memory-hard  (Argon2id)    │ 
 │                             │ │                            │ 
 │ one guess:                  │ │  ························  │ 
 │ █░░░░░░░░░░░░░░░░░░░░░░░░░  │ │  ························  │ 
 │                             │ │  ························  │ 
 │ guesses tried:              │ │  ························  │ 
 │                             │ │  ························  │ 
 │                             │ │  ························  │ 
 │                             │ │                            │ 
 │                             │ │ guesses tried: 0           │ 
 └─────────────────────────────┘ └────────────────────────────┘ 
                                                                
 time ●──────────────────────────────────────────────────────── 
                                                                
 crack>                             (illustrative, not to scale)

แนวคิดนี้เก่ากว่าเครื่องมือส่วนใหญ่ที่เราใช้ทุกวันนี้ ในปี พ.ศ. 2542 Niels Provos และ David Mazières เปิดตัว bcrypt ในบทความ A Future-Adaptable Password Scheme โดยให้เหตุผลว่ารหัสผ่านที่ผู้ใช้ตั้งเองไม่ได้แข็งแรงขึ้นตามเวลา แต่ฮาร์ดแวร์เร็วขึ้นเรื่อย ๆ ต้นทุนของ password scheme จึงต้องปรับเพิ่มได้ตามฮาร์ดแวร์ (USENIX ATC '99) ต้นทุนที่ปรับได้นี้คือ work factor ซึ่งเป็นหัวใจของเรื่อง OWASP ระบุว่า work factor มักถูกเก็บไว้ใน hash output ด้วย จึงเพิ่มค่าภายหลังได้โดยไม่ทำให้ record เดิมใช้ไม่ได้ (OWASP, Work Factors)

Memory-hard function ไปไกลกว่านั้นอีกขั้น การทำให้การเดาแต่ละครั้งช้าบน CPU ก็ดีอยู่แล้ว แต่ถ้าการเดาแต่ละครั้ง ต้องใช้ RAM ก้อนใหญ่ ด้วย การรันการเดาหลายพันครั้งพร้อมกันบนฮาร์ดแวร์เฉพาะทางก็จะแพงขึ้นมาก RFC ของ scrypt อธิบายว่า function นี้สร้างบน memory-hard function ซึ่งให้การป้องกันเพิ่มเติมต่อการโจมตีด้วย custom hardware (RFC 7914, Abstract) และ RFC 9106 อธิบาย Argon2 ว่าเป็น memory-hard function ที่มุ่งเติม memory ให้เร็วที่สุด (RFC 9106, Section 1)

Myth 3: "Salt เป็นส่วนผสมลับ ต้องซ่อนไว้"

Fact: salt ไม่ใช่ความลับ หน้าที่ของมันคือทำให้ hash ที่เก็บไว้แต่ละอันไม่ซ้ำกัน

Salt คือค่าสุ่มที่สร้างขึ้นต่อรหัสผ่านหนึ่งอัน และเก็บไว้ข้าง ๆ hash เลย มันทำสองอย่าง ตามที่ OWASP อธิบาย คือกันไม่ให้ผู้โจมตีใช้ตารางที่คำนวณไว้ล่วงหน้า (rainbow table และ lookup database) และทำให้ไม่สามารถรู้ได้ว่าผู้ใช้สองคนใช้รหัสผ่านเดียวกันหรือไม่ จนกว่าจะ crack hash ทั้งสองได้ (OWASP, Salting)

       same password  +  different salt  =  different hash      
                                                                
                                                                
 user A                                                         
 pw   "S3cret!"─┬                         stored hash           
 salt 9f2c41d7──┤                       ┌─····················  
                │                       │                       
                │     ┌─────────────┐   │                       
                └─────│   Argon2id  │───┘                       
                      │             │                           
                ┌─────│   ◐  ◓  ◑   │───┐                       
                │     └─────────────┘   │                       
                │                       │                       
 user B         │                       │ stored hash           
 pw   "S3cret!"─┼                       └─····················  
 salt a71e0b3c──┘                                               
                                                                
 db>                                 (digests are illustrative) 

กฎของ NIST สำหรับ verifier กำหนดให้รหัสผ่านต้องถูก salt และ hash ด้วย password hashing scheme ที่เหมาะสม โดย salt ต้องยาวอย่างน้อย 32 bit เลือกให้ชนกันน้อยที่สุด และเก็บไว้คู่กับ hash (SP 800-63B-4, Sec. 3.1.1.2) ส่วน RFC 9106 แนะนำมากกว่านั้นสำหรับ Argon2 คือ 128 bit เพียงพอสำหรับทุกการใช้งาน และลดเหลือ 64 bit ได้ถ้าพื้นที่จำกัด (RFC 9106, Section 4)

ในทางปฏิบัติ เราแทบไม่ต้องจัดการ salt เอง OWASP ชี้ว่า algorithm สมัยใหม่บังคับให้มี salt และ library ที่ใช้กันแพร่หลายส่วนใหญ่สร้างและจัดการ salt ให้ภายใน (OWASP, Salting) ถ้าเจอโค้ดที่เขียน sha256(salt + password) เอง นั่นเป็นสัญญาณว่าทางแก้จริงคือเปลี่ยนไปใช้ password hashing library ที่ถูกต้อง ไม่ใช่หา salt ที่ดีกว่าเดิมครับ

Myth 4: "มี pepper แล้ว ไม่ต้องสนใจ hashing ที่ดีก็ได้"

Fact: pepper เป็นชั้นป้องกันเสริมที่มีประโยชน์ และเป็นแค่นั้น

Pepper คือความลับที่ใช้ร่วมกันกับทุกรหัสผ่าน และต่างจาก salt ตรงที่ต้องเก็บไว้ ห่าง จาก database OWASP บอกว่าไม่ควรเก็บไว้กับ hash และแนะนำให้ใช้ secrets vault หรือ HSM โดยใส่ pepper ได้ทั้งก่อน hash หรือหลัง hash ด้วยการนำ hash ที่ได้ไปผ่าน HMAC ที่ใช้ pepper เป็น key ประเด็นคือ ผู้โจมตีที่ขโมยได้แค่ database (เช่นผ่าน SQL injection) จะเริ่มเดาไม่ได้เลยถ้าไม่ได้ pepper ไปด้วย (OWASP, Peppering)

NIST อธิบายแนวคิดเดียวกันโดยไม่ใช้คำว่า pepper คือ verifier SHOULD เพิ่มขั้น keyed hashing หรือ encryption ด้วย secret key ที่ verifier รู้เพียงผู้เดียว สร้างจาก approved random bit generator เก็บแยกจาก hash และควรอยู่ในฮาร์ดแวร์อย่าง HSM, TEE หรือ TPM (SP 800-63B-4, Sec. 3.1.1.2)

OWASP มีข้อควรระวังสองข้อที่ช่วยให้มอง pepper ได้ถูกที่ ข้อแรก pepper เป็นชั้น defence in depth เสริม และถ้าใช้ pepper เพียงอย่างเดียวจะไม่ได้คุณสมบัติด้านความปลอดภัยเพิ่มขึ้น ข้อสอง การ rotate pepper ลำบาก เพราะการเปลี่ยน pepper หมายถึงต้องบังคับให้ผู้ใช้ทุกคนที่รหัสผ่านถูกป้องกันด้วย pepper เก่า reset รหัสผ่าน (OWASP, Peppering) วางแผนเรื่อง key management ให้เรียบร้อยก่อน ship นะครับ

Myth 5: "Algorithm ไหนก็ได้ที่ 'ช้า' ตั้งค่าอะไรก็ได้"

Fact: ทั้ง algorithm และพารามิเตอร์สำคัญ นี่คือจุดที่แนวทางปัจจุบันวางไว้

ค่าทั้งหมดในตารางมาจาก OWASP cheat sheet ซึ่งให้ชุดค่า Argon2id หลายแบบที่ระบุว่าป้องกันได้เท่ากัน ต่างกันแค่การแลก CPU กับ RAM ครับ

ตัว specification เองตั้งมาตรฐานสูงกว่านั้นถ้าเรารับไหว RFC 9106 ซึ่งเผยแพร่เมื่อกันยายน พ.ศ. 2564 โดย Crypto Forum Research Group ของ IRTF ระบุว่าทุก implementation MUST รองรับ Argon2id และให้ค่าที่แนะนำสองชุด คือ t = 1, p = 4, m = 2 GiB เป็นตัวเลือกแรก และ t = 3, p = 4, m = 64 MiB เมื่อมี memory น้อยกว่ามาก ทั้งสองชุดใช้ salt 128 bit และ tag 256 bit (RFC 9106, Sections 1 และ 4) ขั้นตอนการ tune ใน RFC ก็ใช้ได้จริง คือหาก่อนว่าการเรียกแต่ละครั้งใช้ memory ได้เท่าไร แล้วหาค่า t สูงสุดที่ยังอยู่ในงบเวลา ถ้าแม้แต่ t = 1 ยังช้าเกินก็ลด memory ลง ส่วน scrypt นั้น RFC 7914 ระบุว่า r = 8 และ p = 1 "appears to yield good results" (RFC 7914, Section 2)

มีสองเรื่องในทางปฏิบัติที่ควรพูดถึง:

• อย่า tune จนระบบล่ม OWASP ให้หลักคร่าว ๆ ว่า hash หนึ่งครั้งควรใช้เวลาน้อยกว่าหนึ่งวินาที และเตือนว่า work factor ที่สูงเกินไปอาจเปิดช่องให้ผู้โจมตีใช้ login attempt ทำให้ CPU หมด (OWASP, Work Factors)
• 72 byte ของ bcrypt OWASP แนะนำให้บังคับความยาวสูงสุด 72 byte และเรียกการ pre-hash ก่อน bcrypt ว่าอันตราย เพราะปัญหา null-byte truncation และ "password shucking" ถ้าจำเป็นจริง ๆ ก็มีโครงสร้างเฉพาะที่ใช้ HMAC-SHA384 กับ base64 โดยเก็บ pepper ไว้นอก database (OWASP, bcrypt)

PBKDF2 อยู่ตรงไหนในมุมของ NIST? SP 800-63B-4 ระบุว่า SHOULD ใช้ scheme ที่ได้รับอนุมัติจาก SP 800-132 ฉบับล่าสุด (SP 800-63B-4) ส่วน SP 800-132 ออกเมื่อธันวาคม พ.ศ. 2553 และ NIST แจ้งไว้เมื่อ พ.ศ. 2566 ว่ามีแผนจะปรับปรุง นี่คือเหตุผลที่ PBKDF2 มักเป็นตัวเลือกในสภาพแวดล้อมที่ผูกกับ FIPS

ระหว่างที่เปิด SP 800-63B-4 อยู่ (เป็นฉบับ final ตั้งแต่กรกฎาคม พ.ศ. 2568 ตามหน้า NIST CSRC) กฎของ verifier ที่อยู่รอบ ๆ เรื่อง hashing ก็น่าอ่านด้วย คือรหัสผ่านที่ใช้เดี่ยว ๆ ต้องยาวอย่างน้อย 15 ตัวอักษร (8 ตัวถ้าเป็นส่วนหนึ่งของ MFA) ต้องรับได้อย่างน้อย 64 ตัว ห้ามมี composition rule ห้ามบังคับเปลี่ยนตามรอบเวลา ต้องมี blocklist ของรหัสผ่านที่ใช้กันบ่อยหรือรั่วแล้ว และต้องมี rate limiting สำหรับการพยายามที่ล้มเหลว (SP 800-63B-4, Sec. 3.1.1.2) hashing ปกป้องรหัสผ่านตอนเก็บ ส่วนกฎเหล่านี้กำหนดว่ารหัสผ่านจะเดายากแค่ไหนตั้งแต่ต้นครับ

Myth 6: "อัปเกรด hash เก่าไม่ได้ ถ้าไม่ reset ทุกคน"

Fact: ส่วนใหญ่ทำได้ แบบค่อยเป็นค่อยไป

OWASP อธิบายวิธีที่ใช้กันทั่วไปไว้ดังนี้ (OWASP, Upgrading Legacy Hashes):

1. Rehash ตอน login เมื่อผู้ใช้ login สำเร็จ เราจะมี plaintext อยู่ชั่วขณะ ตรวจกับ hash เก่าก่อน แล้ว hash ใหม่ด้วย algorithm ใหม่และบันทึกไว้
2. ห่อ hash เก่าไว้ตอนนี้เลย สำหรับบัญชีที่ยังไม่น่าจะ login เร็ว ๆ นี้ ให้นำ hash เดิมไป hash ซ้ำด้วย algorithm ที่แข็งแรง (เช่น bcrypt ครอบ MD5) วิธีนี้ไม่ต้องใช้ plaintext แต่ OWASP เตือนว่า hash ที่ซ้อนกันอาจ crack ง่ายขึ้น จึงควรแทนที่ด้วย hash ตรง ๆ เมื่อผู้ใช้ login ครั้งถัดไป
3. ให้บัญชีที่ค้างอยู่หมดอายุ สำหรับบัญชีที่ไม่ได้ใช้มานาน ให้ลบ hash เก่าและบังคับ reset

ทั้งหมดนี้ง่ายขึ้นมากถ้าแต่ละ record บอกได้ว่าถูกสร้างมาอย่างไร OWASP แนะนำให้เก็บ algorithm และ work factor ไว้กับ hash ในรูปแบบมาตรฐาน เช่น PHC string format (OWASP) PHC string spec เก็บชื่อ function, version, พารามิเตอร์, salt และ hash ไว้ในบรรทัดเดียว เช่น $argon2id$v=19$m=65536,t=2,p=1$<salt>$<hash> เมื่อมี prefix นี้ โค้ด login ก็มองออกว่า record ไหนอ่อน และอัปเกรดให้ทีละคนตอนที่เขา login ครับ

อุปกรณ์เครือข่ายอยู่ตรงไหนในเรื่องนี้

ทุกอย่างข้างบนใช้กับอุปกรณ์ในตู้ rack ของเราด้วย เอกสารของ Cisco แสดงรายการ credential "type" ที่เห็นใน config ของ IOS XE, IOS XR และ NX-OS ไว้ดังนี้ (Cisco, Protecting Secrets on Cisco Network Devices):

เอกสารเดียวกันยังเล่าตัวอย่างจริงของวิธี "ห่อ hash เก่า" ใน Myth 6 ไว้อย่างน่าสนใจ ตั้งแต่ IOS XE 16.12.x secret แบบ type 5 จะถูกแปลงเป็น type 9 อัตโนมัติ โดยนำ scrypt ไปครอบค่า MD5 เดิม และตอน login อุปกรณ์จะทำ MD5 ก่อนแล้วตามด้วย scrypt เอกสารยังระบุว่า type 9 โดยทั่วไปถือว่าแข็งแรงกว่า type 8 แม้บางองค์กรเลือก type 8 ด้วยเหตุผลด้าน regulation และวางแผนถอดการเก็บ secret แบบ reversible ในรูป type 0 และ type 7 ออกใน IOS XE รุ่นถัด ๆ ไป

สำหรับผม ข้อสรุปเชิงปฏิบัติเวลา review config มีสั้น ๆ ดังนี้ครับ

• บรรทัด password 7 คือรหัสผ่านที่อ่านออก config ที่มีบรรทัดแบบนี้ต้องถือเป็นข้อมูลอ่อนไหว
• บัญชี local ให้ใช้ type 9 (หรือ type 8 ถ้า policy กำหนด) และใช้ type 6 กับ master key ที่มีการจัดการ สำหรับ secret ที่อุปกรณ์ต้องนำกลับไปใช้
• ก่อน downgrade หรือ RMA ให้ตรวจว่า release ปลายทางรองรับ type ใดบ้าง และ master key เก็บไว้ที่ไหน เอกสารของ Cisco อธิบายทั้งสองกรณีไว้

Checklist สั้น ๆ

• รหัสผ่าน login: hash ด้วย Argon2id (หรือ scrypt, bcrypt หรือ PBKDF2 เมื่อจำเป็น) ห้าม encrypt
• Salt: ไม่ซ้ำกันในแต่ละรหัสผ่าน ให้ library สร้างให้
• Pepper หรือขั้น keyed: ใส่หรือไม่ก็ได้ เก็บไว้นอก database และมีแผน rotate
• พารามิเตอร์: เท่ากับหรือสูงกว่าค่าขั้นต่ำของ OWASP ทดสอบบน server จริง และเก็บไว้กับ hash ทุกอัน
• Hash เก่า: rehash ตอน login ห่อส่วนที่เหลือ และให้บัญชีที่ไม่ใช้งานหมดอายุ
• อุปกรณ์: ไม่มี type 0, 5 หรือ 7 เหลืออยู่ใน config ของ production

ไม่มีอะไรในนี้ที่แปลกใหม่ และนั่นคือส่วนที่น่าดีใจ งานคิดยาก ๆ มีคนทำและเขียนไว้ให้แล้ว หน้าที่ของเราส่วนใหญ่คืออ่านแล้วนำไปใช้ครับ

แหล่งอ้างอิง

• OWASP Password Storage Cheat Sheet
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
• NIST CSRC, หน้าเผยแพร่ SP 800-63B-4
• NIST SP 800-132, Recommendation for Password-Based Key Derivation, Part 1
• RFC 9106, Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications
• RFC 9106 บน IETF Datatracker
• RFC 7914, The scrypt Password-Based Key Derivation Function
• Provos และ Mazières, A Future-Adaptable Password Scheme (USENIX ATC '99)
• C2SP, PHC string format
• Cisco, Protecting Secrets on Cisco Network Devices (PDF)