bcrypt vs Argon2: เลือกการตั้งค่าการแฮชรหัสผ่าน

ปัญหาที่การแฮชรหัสผ่านแก้ไข

การแฮชรหัสผ่านช่วยให้แบ็กเอนด์เก็บรหัสผ่านโดยไม่ต้องเก็บรหัสผ่านจริง ตอนสมัคร ระบบจะนำรหัสผ่านผ่านฟังก์ชันทางเดียวแล้วเก็บผลลัพธ์ (แฮช) ไว้ เมื่อล็อกอิน ระบบก็แฮชสิ่งที่ผู้ใช้พิมพ์แล้วเทียบกับค่าที่เก็บไว้

แฮชไม่ใช่การเข้ารหัส ไม่มีวิธีถอดกลับได้ คุณสมบัติทางเดียวนี้เองคือเหตุผลที่ใช้แฮชกับรหัสผ่าน

แล้วทำไมไม่ใช้แฮชเร็วๆ อย่าง SHA-256? เพราะความเร็วคือสิ่งที่ผู้โจมตีต้องการ ถ้าฐานข้อมูลถูกขโมย ผู้โจมตีจะไม่เดารหัสผ่านแบบเข้าสู่ระบบทีละบันทึก แต่จะเดาแบบออฟไลน์จากลิสต์แฮชที่ขโมยมา ดันการเดาด้วยฮาร์ดแวร์ให้เร็วที่สุดเท่าที่จะทำได้ ด้วย GPU แฮชเร็วสามารถทดสอบได้ในระดับมหาศาล แม้มีซอลต์เฉพาะแต่แฮชที่เร็วก็ยังถูกเดาได้ถูก

รูปแบบความล้มเหลวที่เป็นจริง: เว็บแอปขนาดเล็กเสียตารางผู้ใช้ในการเจาะระบบ ผู้โจมตีได้อีเมลและแฮชรหัสผ่าน ถ้าแฮชถูกสร้างด้วยฟังก์ชันที่เร็ว รหัสผ่านทั่วไปและรูปแบบย่อมๆ จะถูกค้นพบเร็ว จากนั้นผู้โจมตีจะลองรหัสผ่านเดียวกันบนไซต์อื่นๆ (credential stuffing) หรือใช้มันเข้าถึงฟีเจอร์ที่มีสิทธิ์สูงขึ้นในแอปของคุณ

แฮชรหัสผ่านที่ดีทำให้การเดามีค่าใช้จ่ายสูง เป้าหมายไม่ใช่ “ไม่สามารถถอดได้” แต่คือ “ช้ามากจนไม่คุ้มค่า”

การตั้งค่าการแฮชควรมีคุณสมบัติ:

• ทางเดียว (ตรวจสอบ ไม่ย้อนกลับ)
• ช้าต่อการเดาแต่ละครั้ง
• มีต้นทุนสูงเมื่อรันแบบขนาน (โดยเฉพาะกับ GPU)
• ยังเร็วพอที่การล็อกอินจริงจะรู้สึกเป็นปกติ
• ปรับค่าได้เพื่อเพิ่มต้นทุนเมื่อเวลาผ่านไป

bcrypt และ Argon2 ในหนึ่งนาที

เมื่อเปรียบเทียบ bcrypt vs Argon2 คุณกำลังเลือกวิธีชะลอการเดารหัสผ่านหลังจากฐานข้อมูลรั่ว

bcrypt เป็นตัวเลือกเก่าที่สนับสนุนกว้าง โดยออกแบบให้มีต้นทุนด้าน CPU เป็นหลัก และมีปุ่มปรับหนึ่งตัวคือ cost factor มันยัง “น่าเชื่อถือ” ในแง่ดี: หาไลบรารีง่าย ติดตั้งง่าย และพฤติกรรมคาดเดาได้

Argon2 ใหม่กว่าและถูกออกแบบให้เป็น memory-hard มันสามารถบังคับให้การเดาแต่ละครั้งใช้ RAM ในปริมาณที่มีความหมาย ไม่ใช่แค่ CPU ซึ่งสำคัญเพราะผู้โจมตีมักรันการเดาจำนวนมากพร้อมกันบน GPU หรือฮาร์ดแวร์เฉพาะ Memory ยากและมีค่าใช้จ่ายมากกว่าที่จะขยายแบบขนาน

Argon2 มีสามแบบย่อย:

• Argon2i: เน้นการต้านการโจมตีด้านช่องทางข้อมูลบางประเภท
• Argon2d: เน้นการต้าน GPU โดยมีการพิจารณาด้านช่องทางข้อมูลน้อยกว่า
• Argon2id: ผสมผสานที่ใช้งานได้จริงและเป็นค่าเริ่มต้นที่พบบ่อยสำหรับการแฮชรหัสผ่าน

ถ้าสต็อกของคุณรองรับ Argon2id และคุณปรับหน่วยความจำได้อย่างปลอดภัย มักจะเป็นค่าเริ่มต้นที่ดีที่สุดสมัยใหม่ หากต้องการความเข้ากันได้กับระบบเก่า bcrypt ยังเป็นตัวเลือกที่แข็งแรงเมื่อกำหนด cost factor ให้สูงพอ

คุณสมบัติด้านความปลอดภัยที่สำคัญ

คำถามหลักง่ายๆ คือ: ถ้าผู้โจมตีขโมยฐานข้อมูลรหัสผ่าน จะมีต้นทุนเท่าไรในการเดารหัสผ่านเป็นจำนวนมาก?

กับ bcrypt คุณควบคุม cost (work factor) ได้ ค่า cost สูงขึ้นหมายถึงการเดาแต่ละครั้งใช้เวลานานขึ้น นั่นทำให้ผู้โจมตีช้าลง แต่ก็ชะลอการตรวจสอบล็อกอินของคุณเองด้วย ดังนั้นต้องปรับให้เป็นจุดที่ทำให้ผู้โจมตีเจ็บปวดแต่ผู้ใช้ยอมรับได้

กับ Argon2id คุณเพิ่มความยากด้านหน่วยความจำเข้ามานอกเหนือจากเวลา การเดาแต่ละครั้งต้องใช้ทั้งเวลา CPU และการเข้าถึง RAM ตามรูปแบบที่กำหนด GPU เร็วมากกับงานที่เน้นการคำนวณ แต่เสียเปรียบเมื่อการเดาแต่ละงานต้องการหน่วยความจำมาก

ซอลต์ เป็นสิ่งที่ต้องมี ซอลต์สุ่มและไม่ซ้ำต่อรหัสผ่านแต่ละรายการ:

• ป้องกันไม่ให้ตารางคำนวณล่วงหน้าใช้ซ้ำได้ทั่วทั้งฐานข้อมูล
• ทำให้รหัสผ่านเหมือนกันไม่ให้ค่าแฮชเหมือนกันระหว่างผู้ใช้

ซอลต์ไม่ทำให้รหัสผ่านอ่อนแอกลายเป็นแข็งแรง มันช่วยปกป้องหลังการรั่วของฐานข้อมูลโดยบังคับให้ผู้โจมตีต้องทำงานจริงต่อแต่ละผู้ใช้

ข้อดีและข้อจำกัดของ bcrypt ที่ควรรู้

bcrypt ยังคงถูกใช้อย่างแพร่หลาย ส่วนมากเพราะติดตั้งได้ทุกที่ง่าย มันเหมาะเมื่อคุณต้องการความเข้ากันได้กว้าง เมื่อสแตกมีตัวเลือกคริปโตจำกัด หรือเมื่อคุณต้องการคันโยกการปรับแต่งเดียว

ข้อควรระวังใหญ่คือ ข้อจำกัด 72 ไบต์ bcrypt ใช้เพียง 72 ไบต์แรกของรหัสผ่านและไม่สนใจส่วนที่เหลือ ซึ่งอาจทำให้คนใช้วลีผ่าน (passphrase) ยาวหรือผู้ใช้ที่ใช้ตัวจัดการรหัสผ่านสับสน

ถ้าเลือก bcrypt ให้ชี้แจงพฤติกรรมความยาวของรหัสผ่านอย่างชัดเจน เลือกบังคับความยาวสูงสุด (เป็นไบต์ ไม่ใช่ตัวอักษร) หรือจัดการอินพุตยาวในทางที่สอดคล้องกันข้ามบริการ เป้าหมายคือหลีกเลี่ยงการตัดทอนเงียบที่เปลี่ยนสิ่งที่ผู้ใช้คิดว่าเป็นรหัสผ่านของพวกเขา

bcrypt ยังทนต่อฮาร์ดแวร์การแคร็กแบบขนานสมัยใหม่ได้น้อยกว่าออปชันที่เป็น memory-hard การป้องกันยังมีค่าแต่มันขึ้นกับการเลือก cost factor ที่ทำให้การเดาแต่ละครั้งมีค่าใช้จ่ายสูง

ถ้าคุณกำลังสร้างระบบใหม่หรือมีบัญชีมูลค่าสูง (แผนชำระเงิน บทบาทผู้ดูแล) การย้ายแฮชใหม่ไปเป็น Argon2id พร้อมรับแฮช bcrypt เดิมจนกว่าผู้ใช้จะล็อกอินเป็นแนวทางที่สะดวกและความเสี่ยงต่ำ

ข้อดีและการแลกเปลี่ยนของ Argon2

Argon2 ถูกสร้างมาเพื่อการแฮชรหัสผ่าน Argon2id เป็นแบบที่ทีมส่วนใหญ่เลือกเพราะสมดุลระหว่างการต้าน GPU และการป้องกันช่องทางข้อมูล

Argon2id ให้พารามิเตอร์สามอย่าง:

• Memory (m): ปริมาณ RAM ที่แต่ละแฮชจะใช้ขณะทำงาน
• Time/iterations (t): จำนวนรอบที่ทำผ่านหน่วยความจำนั้น
• Parallelism (p): จำนวนเลนที่ใช้ (ช่วยบน CPU หลายคอร์)

หน่วยความจำคือข้อได้เปรียบหลัก ถ้าการเดาแต่ละครั้งต้องการ RAM ในปริมาณที่มีความหมาย ผู้โจมตีจะไม่สามารถรันการเดาจำนวนมากพร้อมกันได้โดยไม่ต้องจ่ายค่า RAM และแบนด์วิดท์มาก

ข้อเสียคือทางปฏิบัติการ: หน่วยความจำต่อแฮชมากขึ้นหมายถึงล็อกอินพร้อมกันได้น้อยลงก่อนที่เซิร์ฟเวอร์ของคุณจะเริ่มมีแรงกดดัน ถ้าคุณตั้งหน่วยความจำสูงเกินไป คลื่นการล็อกอินอาจทำให้คิว งานหมดเวลา หรือแม้แต่เกิด out-of-memory ได้ คุณยังต้องคิดถึงการใช้งานที่เป็นการโจมตี: การพยายามล็อกอินพร้อมกันจำนวนมากสามารถเป็นปัญหาทรัพยากรได้ถ้าคุณไม่จำกัดงาน

เพื่อให้ Argon2id ปลอดภัยและใช้งานได้ ให้ปรับแต่งเหมือนฟีเจอร์ด้านประสิทธิภาพ:

• เบนช์มาร์กบนฮาร์ดแวร์ที่ใกล้เคียง production
• จำกัดงานการแฮชพร้อมกัน (จำกัด worker, คิว)
• จำกัดอัตราการลองล็อกอินและล็อกเอาต์การพยายามซ้ำ
• เก็บการตั้งค่าให้สอดคล้องกันข้ามบริการเพื่อไม่ให้จุดอ่อนจุดเดียวกลายเป็นเป้า

ต้นทุนประสิทธิภาพในเว็บแบ็กเอนด์จริง

กับการแฮชรหัสผ่าน เป้าหมาย "เร็วขึ้นย่อมดีกว่า" มักเป็นเป้าหมายที่ผิด คุณต้องการให้การเดาแต่ละครั้งมีต้นทุนสำหรับผู้โจมตี ในขณะที่การล็อกอินจริงยังรู้สึกรวดเร็วสำหรับผู้ใช้

วิธีปฏิบัติคือกำหนดงบเวลาแต่ละการยืนยันบนฮาร์ดแวร์ production ของคุณ หลายทีมตั้งเป้าราว 100 ถึง 300 ms ต่อการตรวจสอบ แต่ตัวเลขที่ถูกต้องขึ้นกับทราฟิกและเซิร์ฟเวอร์ของคุณ ความแตกต่างระหว่าง bcrypt และ Argon2 คือสิ่งที่คุณจ่าย: bcrypt เป็นเวลา CPU ส่วน Argon2 อาจจองหน่วยความจำด้วย

ตั้งเป้าทางเวลา แล้ววัด

เลือกเป้าหมายเวลาต่อการแฮชและทดสอบในสภาพที่ใกล้เคียง production วัดทั้งการสมัคร/เปลี่ยนรหัสผ่านและการยืนยันล็อกอิน แต่ถือว่าการล็อกอินคือเส้นทางร้อน

แผนการวัดแบบเบา:

• ทดสอบ 1, 10, และ 50 การตรวจสอบล็อกอินพร้อมกัน แล้วบันทึก p50 และ p95 ของ latency
• ทำซ้ำหลายรอบเพื่อลดเสียงรบกวนจากการแคชและการบูสท์ CPU
• วัดการเรียกฐานข้อมูลแยกต่างหากเพื่อรู้ว่าการแฮชใช้ค่าใช้จ่ายเท่าไรจริง
• ทดสอบกับคอนเทนเนอร์และข้อจำกัด CPU เดียวกับที่คุณจะปรับใช้

การกระแทกมีความสำคัญมากกว่าค่าเฉลี่ย

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

ถ้าการตรวจสอบหนึ่งครั้งใช้ 250 ms และเซิร์ฟเวอร์ของคุณรับได้ 40 งานพร้อมกันก่อนเกิดคิว การระเบิดของ 500 การล็อกอินสามารถทำให้เกิดความหน่วงหลายวินาที ในสถานการณ์นั้น การลดค่าเล็กน้อยพร้อมกับการจำกัดอัตราที่เข้มแข็ง อาจทำให้ความปลอดภัยในโลกจริงดีขึ้นมากกว่าการดันพารามิเตอร์จนทำให้ endpoint การล็อกอินเปราะบาง

ทำให้การล็อกอินแบบโต้ตอบคาดเดาได้

ไม่ใช่ทุกการดำเนินการเกี่ยวกับรหัสผ่านต้องการความเร่งด่วนเท่ากัน รักษาค่าใช้จ่ายในการล็อกอินแบบโต้ตอบให้เสถียร แล้วย้ายงานหนักออกนอกเส้นทางวิกฤต รูปแบบที่ใช้กันทั่วไปคือ rehash-on-login (อัปเกรดแฮชของผู้ใช้ทันทีหลังล็อกอินสำเร็จ) หรือใช้งานแบ็กกราวด์สำหรับการย้ายข้อมูลและการนำเข้า

วิธีเลือกพารามิเตอร์ทีละขั้นตอน

การปรับพารามิเตอร์คือการเพิ่มต้นทุนต่อการเดาของผู้โจมตีโดยไม่ทำให้การลงชื่อเข้าใช้ช้าหรือทำให้เซิร์ฟเวอร์ไม่เสถียร

1. เลือกอัลกอริทึมที่สแต็กของคุณรองรับได้ดี. ถ้า Argon2id มีและรองรับดี มักเป็นตัวเลือกเริ่มต้น ถ้าต้องการความเข้ากันได้กว้าง bcrypt ก็ยังโอเค
2. กำหนดเวลาเป้าหมายต่อแฮชบนฮาร์ดแวร์ที่คล้าย production. เลือกค่าที่ทำให้การล็อกอินลื่นไหลในช่วงพีค
3. ปรับแต่งให้ได้เวลานั้น. กับ bcrypt ปรับ cost factor; กับ Argon2id จัดบาลานซ์หน่วยความจำ, รอบ, และความขนาน หน่วยความจำเป็นคันโยกที่เปลี่ยนเศรษฐศาสตร์ของผู้โจมตีได้มากที่สุด
4. เก็บอัลกอริทึมและการตั้งค่ากับแฮช. ฟอร์แมตรหัสผ่านมาตรฐานส่วนใหญ่ฝังรายละเอียดเหล่านี้ไว้ ตรวจสอบด้วยว่าเขตข้อมูลฐานข้อมูลยาวพอไม่ให้แฮชถูกตัด
5. วางแผนการอัปเกรดด้วย rehash-on-login. เมื่อผู้ใช้ล็อกอิน ถ้าแฮชเก่ากว่าให้คำนวณใหม่ด้วยการตั้งค่าปัจจุบัน

จุดเริ่มต้นเชิงปฏิบัติ

ถ้าคุณต้องการค่าเริ่มต้นก่อนวัด ให้เริ่มอย่างระมัดระวังแล้วปรับตามการวัด

• สำหรับ bcrypt หลายทีมเริ่มที่ cost 12 แล้วปรับตามการวัดจริง
• สำหรับ Argon2id ค่าเริ่มต้นทั่วไปคือหน่วยความจำตั้งแต่หลักสิบถึงหลักร้อย MB, time cost 2 ถึง 4, และ parallelism 1 ถึง 2

ถือว่านี่คือจุดเริ่มต้น ไม่ใช่กฎ การตั้งค่าที่ถูกต้องคือสิ่งที่เหมาะกับทราฟิก ฮาร์ดแวร์ และการระเบิดการล็อกอินของคุณ

ความผิดพลาดทั่วไปที่ทำให้การเก็บรหัสผ่านอ่อนแอลง

ความล้มเหลวส่วนใหญ่เกิดจากช่องว่างการตั้งค่า ไม่ใช่อัลกอริทึมที่พัง

ข้อผิดพลาดซอลต์ เป็นเรื่องใหญ่ แต่ละรหัสผ่านต้องมีซอลต์สุ่มเฉพาะและเก็บคู่กับแฮช การใช้ซอลต์ซ้ำหรือซอลต์เดียวทั้งระบบทำให้ผู้โจมตีใช้ผลงานที่คำนวณแล้วซ้ำและเปรียบเทียบบัญชีได้ง่ายขึ้น

ละเลยค่า cost ก็อีกเรื่อง ทีมมักปล่อยค่าเริ่มต้นต่ำเพราะล็อกอินเร็ว แล้วไม่เคยทบทวน ฮาร์ดแวร์พัฒนา ผู้โจมตีขยายตัว แล้วการตั้งค่าที่เคยพอใช้กลับถูกทำให้ไม่แพง

การตั้ง Argon2 เกินจริง ก็พบได้บ่อย การตั้งหน่วยความจำสูงมากในกระดาษอาจทำให้ล็อกอินช้า คิวงานสะสม หรือเกิด OOM ในช่วงพีคจริง

การจัดการความยาวรหัสผ่าน สำคัญ โดยเฉพาะพฤติกรรม 72 ไบต์ของ bcrypt ถ้าคุณอนุญาตรหัสผ่านยาวแต่ตัดทอนเงียบ คุณจะสร้างพฤติกรรมที่สับสนและลดความปลอดภัย

นิสัยปฏิบัติที่ป้องกันได้มาก:

• ใช้ซอลต์ไม่ซ้ำต่อรหัสผ่าน (ให้ไลบรารีสร้าง)
• โหลดเทสต์และทบทวนการตั้งค่าเป็นระยะ
• จูนหน่วยความจำ Argon2 ให้เหมาะกับทราฟิกพีค ไม่ใช่แค่เบนช์มาร์กเดี่ยว
• กำหนดขีดจำกัดความยาวรหัสผ่านอย่างชัดเจนและสอดคล้อง
• ใส่ขีดจำกัดความพร้อมกันและมอนิเตอร์รอบๆ endpoint การล็อกอิน

เช็คลิสต์ด่วนเพื่อการตั้งค่าที่ปลอดภัยขึ้น

เก็บรายการสั้นนี้ไว้ใกล้เมื่อส่งของและเมื่อเปลี่ยนโครงสร้างพื้นฐาน:

• ซอลต์ไม่ซ้ำต่อรหัสผ่าน สร้างแบบสุ่มและเก็บกับแฮช
• ค่าแฮชที่ทนต่อการจราจรพีค ยืนยันด้วยโหลดเทสต์บนฮาร์ดแวร์ที่คล้าย production
• เก็บพารามิเตอร์กับแฮช เพื่อให้คุณยืนยันบัญชีเก่าและเพิ่มค่าได้ต่อไป
• การควบคุมการโจมตีออนไลน์ รวมจำกัดอัตราและการล็อกสั้นสำหรับความล้มเหลวซ้ำๆ
• เส้นทางการอัปเกรด โดยปกติคือ rehash-on-login

เช็คลิสต์ง่าย: รันการทดสอบในสเตจที่มีการระเบิดการล็อกอิน (สำเร็จและล้มเหลว) แล้วสังเกตความหน่วงปลายทาง CPU และ RAM หากเส้นทางล็อกอินมีปัญหา ให้ปรับค่าและเข้มงวดการจำกัดอัตรา อย่าแก้ด้วยการตัดสิ่งจำเป็นอย่างซอลต์

ตัวอย่างสมจริง: จูนสำหรับเว็บแอปขนาดเล็ก

นึกภาพ SaaS ขนาดเล็กที่มีผู้ใช้ไม่กี่พันคน ส่วนใหญ่วันเป็นทราฟิกคงที่ แต่มีคลื่นล็อกอินสั้นๆ หลังจดหมายข่าวหรือตอนเริ่มวันทำงาน นี่คือที่การเลือกกลายเป็นการวางแผนความจุ

คุณเลือก Argon2id เพื่อเพิ่มต้นทุนการแคร็กแบบออฟไลน์ กำหนดเวลาเป้าหมายการยืนยันบนเซิร์ฟเวอร์จริงของคุณ (เช่น 100–250 ms) แล้วจูนพารามิเตอร์ให้ได้เป้าหมายนั้นโดยสังเกต RAM เพราะการตั้งหน่วยความจำจำกัดจำนวนล็อกอินพร้อมกัน

ลูปการจูนปฏิบัติ:

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

ถ้าคุณมีแฮชเก่าที่อ่อนกว่า ให้ยังคงตรวจสอบพวกมันและอัปเกรดอย่างเงียบ ๆ เมื่อผู้ใช้ล็อกอินสำเร็จ ค่อยๆ ย้ายผู้ใช้ที่ใช้งานไปสู่แฮชที่แข็งแรงกว่าโดยไม่ต้องบังคับรีเซ็ต

หลังปล่อย ให้มอนิเตอร์การล็อกอินเหมือน endpoint สำคัญอื่น ๆ: latency p95/p99, CPU และ RAM ในช่วงคลื่น, สถิติการล็อกอินล้มเหลว และความเร็วที่แฮชเก่ากำลังถูกแทนที่

ขั้นตอนถัดไป: ส่งของอย่างปลอดภัยและปรับปรุงต่อเนื่อง

จดนโยบายของคุณแล้วถือเป็นการตั้งค่าที่มีชีวิต เช่น: “Argon2id พร้อมหน่วยความจำ X, รอบ Y, ความขนาน Z” หรือ “bcrypt cost factor N” พร้อมวันที่ที่คุณเลือกและกำหนดเวลาทบทวน (ทุก 6–12 เดือนเป็นจุดเริ่มต้นที่ดี)

เก็บเส้นทางการอัปเกรดไว้เพื่อไม่ให้ติดกับแฮชเก่า rehash-on-login ทำได้ง่ายและใช้ได้ดีในระบบส่วนใหญ่

แฮชที่แข็งแรงช่วยได้มาก แต่ไม่ทดแทนการควบคุมการโจมตีออนไลน์ การจำกัดอัตรา การล็อก และการออกแบบการรีเซ็ตรหัสผ่านอย่างรอบคอบก็สำคัญไม่แพ้กัน

ถ้าคุณสร้างแบ็กเอนด์ด้วยแพลตฟอร์มแบบ no-code อย่าง AppMaster ควรตรวจสอบว่าโมดูลการยืนยันตัวตนนั้นใช้การแฮชรหัสผ่านที่แข็งแรงเป็นค่าปริยายและว่าค่าแฮชถูกจูนบนฮาร์ดแวร์ชนิดเดียวกับที่คุณจะปรับใช้ การทดสอบล่วงหน้าเพียงเล็กน้อยมักเป็นสิ่งที่แยกระหว่าง “ปลอดภัยและลื่นไหล” กับ “ปลอดภัยแต่ใช้งานไม่ได้ภายใต้โหลด"