เราปกป้องรหัสผ่านของคุณอย่างไร

ในบทความก่อนหน้านี้ เราได้พูดถึงวิธีที่ HTTPS ปกป้องเส้นทางระหว่างแอปของคุณกับเซิร์ฟเวอร์ของเรา และวิธีที่ SSH รักษาความปลอดภัยให้เซิร์ฟเวอร์เอง ตอนนี้มาดูกันว่า Splync ปกป้องรหัสผ่านของคุณอย่างไรเมื่อมันไปถึงเซิร์ฟเวอร์ หากมีใครได้รหัสผ่านของคุณคนนั้นจะสามารถเข้าสู่บัญชีของคุณและเข้าถึงข้อมูลสำคัญ รวมถึงบันทึกค่าใช้จ่าย นั่นคือเหตุผลที่ Splync ไม่เคยบันทึกรหัสผ่านในรูปแบบข้อความ แต่จะเปลี่ยนรหัสผ่านเป็นแบบแฮชก่อนจะเก็บไว้ในฐานข้อมูล การแฮชคือการเปลี่ยนข้อมูลแบบทางเดียว เมื่อเปลี่ยนแล้วจะไม่สามารถกลับเป็นรหัสผ่านเดิมได้ วิธีนี้เป็นมาตรฐานทางอินเทอร์เน็ต ไม่ว่าจะเป็นธนาคารหรือบริการคลาวด์ใหญ่ ๆ แต่หลายคนอาจยังไม่รู้ว่ามันทำงานอย่างไร มาสำรวจผ่านตัวอย่างง่าย ๆ ในชีวิตประจำวันกัน

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

SHA-256 เป็นหนึ่งในอัลกอริธึมการแฮชที่พบได้บ่อยที่สุด เช่น รหัสผ่าน "splync1234" ถูกแฮชเป็น “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41” ในเวลาเพียงมิลลิวินาที ทุกครั้งที่ผู้ใช้ที่มีบัญชีอยู่แล้วใส่รหัสผ่านเข้าไป SHA-256 จะผลิตรหัสผ่านแฮชเดิมเสมอ แอปจะทำการแฮชรหัสผ่านที่ใส่เข้ามาอีกครั้งและตรวจสอบว่าตรงกับที่เก็บไว้หรือไม่ โดยที่ระบบจะไม่รู้รหัสผ่านเดิมของผู้ใช้เลย แต่ถ้ามีผู้โจมตีที่เตรียมรายชื่อรหัสผ่านทั่วไปและแฮชไว้ล่วงหน้า (ที่เรียกว่า rainbow table) เพื่อทายรหัสผ่านของผู้ใช้อย่างรวดเร็ว ความกังวลนี้เป็นเรื่องจริง นี่คือเหตุผลที่ระบบสมัยใหม่ รวมถึง Splync ไม่พึ่งพา SHA-256 แบบเดิม

Bcrypt ใช้ salt แบบสุ่มสำหรับผู้ใช้แต่ละคนและเข้ารหัส salt (รวมถึง cost factor) ลงในสายอักขระที่เก็บไว้ ลองคิดว่า bcrypt เป็นเครื่องปั่นที่มีเครื่องปรุงลับ (salt) และมอเตอร์ช้า (work factor) ซึ่งทำให้ทุกการผสมมีเอกลักษณ์และยากที่จะลอกเลียนแบบ เนื่องจาก salt มีขนาด 128 บิต (≈3×10³⁸ ความเป็นไปได้) รหัสผ่านเดียวกันสามารถแปลงเป็นแฮชที่เก็บไว้ได้หลายล้านแบบ ทำให้ rainbow tables ที่เตรียมไว้ล่วงหน้าไร้ประโยชน์ในระดับที่ใหญ่ ระหว่างการเข้าสู่ระบบ Splync อ่าน salt และ cost จาก bcrypt string ที่บันทึกไว้ แล้วทำการแฮชใหม่ตามพารามิเตอร์เหล่านั้น และเปรียบเทียบผลลัพธ์เพื่อดูว่าตรงกันหรือไม่ หากตรงกันรหัสผ่านถูกต้อง แต่เพราะ bcrypt ถูกออกแบบให้ช้าและ salt เป็นเอกลักษณ์ การโจมตีแบบ brute-force จะมีค่าใช้จ่ายสูงกว่าสำหรับผู้โจมตี

มาดูกันว่ามันเป็นอย่างไรในทางปฏิบัติ หากคุณแฮชรหัสผ่าน "splync1234" ด้วย bcrypt (ใช้ cost 12) คุณอาจได้สายอักขระแบบนี้: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O` ในสายอักขระ bcrypt นี้ `$2b` แสดงถึงเวอร์ชันของอัลกอริธึม `$12` แสดงถึง cost factor (จำนวนครั้งที่รหัสผ่านถูกประมวลผล) `gBeouKYdue9uvvuV0HtGgeV` คือ salt แบบสุ่มที่เป็นเอกลักษณ์ และ `PymnrojMqP/wcRw28HFlGEGIQbyw7O` คือรหัสผ่านแฮชสุดท้าย เพราะแฮชเองมีทั้ง salt และ cost Splync สามารถสร้างกระบวนการแฮชเดิมซ้ำเพื่อยืนยันโดยดึงค่าจากสายอักขระที่เก็บไว้และเปรียบเทียบผลลัพธ์ ในทางกลับกันหากผู้โจมตีไม่รู้ salt และ cost พวกเขาไม่สามารถสร้าง rainbow table เดียวที่ใช้ได้กับทุกผู้ใช้

วิธีนี้มีข้อดีที่สำคัญอีกประการหนึ่ง เพราะ Splync ไม่เคยเก็บรหัสผ่านในรูปแบบข้อความธรรมดา แม้ว่าฐานข้อมูลจะถูกเปิดเผยหรือถูกขโมย ผู้ใช้ก็ไม่ตกอยู่ในความเสี่ยงทันที ผู้โจมตีไม่สามารถเข้าสู่ระบบโดยตรงด้วยข้อมูลที่ถูกขโมย เพราะสิ่งที่พวกเขามีเป็นเพียงสายอักขระที่ถูกผสมไปแล้ว การออกแบบนี้ให้การป้องกันเพิ่มขึ้นอีกชั้นหนึ่ง นอกเหนือจากการรักษาความปลอดภัยที่มีอยู่แล้วรอบเซิร์ฟเวอร์ การแฮชรหัสผ่านไม่ใช่เรื่องใหม่สำหรับ Splync; มันเป็นมาตรฐานในอุตสาหกรรมเทคโนโลยี ที่ใช้โดยบริษัทใหญ่ ๆ อย่าง Google, Apple, และ Amazon Splync ถูกออกแบบมาให้ปลอดภัยมาก และจะปลอดภัยยิ่งขึ้นเมื่อเรายังคงพัฒนาความปลอดภัยด้วยฟีเจอร์ต่าง ๆ เช่น การยืนยันอีเมล การป้องกัน brute-force และการตรวจสอบอย่างต่อเนื่อง