พบเว็บ Starbucks Thailand ไม่เข้ารหัสข้อมูลรหัสผ่านของลูกค้า

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

ทางผู้เขียนข่าวแนะนำให้ทำการเปลี่ยนรหัสผ่านที่ใช้งานร่วมกับเว็บ Starbucks Thailand (https://www.starbuckscard.in.th) เพื่อความปลอดภัยของบริการอื่นๆ ในอนาคต
ทางผู้เขียนจึงลองทดสอบดูตามข้อมูลที่ https://www.starbuckscard.in.th/cards/forgot-password.aspx

แล้วกรอกอีเมลที่ตัวเองได้ลงทะเบียนไว้แล้วพบว่ารหัสผ่านที่ส่งมานั้น ทาง Starbucks ส่งมาเป็น plain text จริงๆ ตามข้อมูลด้านล่างนี้ (ผมขอนำรหัสผ่านจริงๆ ออกเพื่อประกอบการนำเสนอ และใส่ข้อความอื่นๆ แทน)

แน่นอนว่าไม่ใช่แค่เว็บเท่านั้น เมื่อเกือบ 2 เดือนที่แล้ว Starbucks ก็ได้ทำพลาดแม้แต่ใน App ของตัวเองใน App Store เช่นกัน ตามรายการข่าวบางส่วน เช่น Starbucks: We Stored Your Passwords in Plaintext หรือ Starbucks App Saves Usernames, Passwords in Plain Text

ซึ่งในความเป็นจริงแล้ว ระบบเว็บ หรือซอฟต์แวร์ต่างๆ โดยทั่วไปที่ใส่ใจต่อข้อมูลรหัสผ่าน ซึ่งเป็นข้อมูลที่อ่อนไหวง่ายที่สุด มักจะนำรหัสผ่านผู้ใช้งานไปผ่านกรรมวิธี hash ทางเดียว (one-way hashing; หรือลายเซ็นของข้อมูล) และใช้ salt ร่วมด้วย (ชุดอักขระสุ่มเฉพาะ) เพื่อความปลอดภัยสูงสุด การที่เว็บแบรนด์ดังจัดเก็บรหัสผ่านแบบ plain text หรือแม้แต่จัดเก็บแบบเข้ารหัสแต่สามารถย้อนกลับรหัสผ่านใดๆ ให้เป็น plain text ได้ ถือเป็นเรื่องที่ยอมรับไม่ได้ในวงการ Security ในด้านระบบยืนยันสิทธิ์ในการเข้าใช้ระบบ โดยสำหรับใครที่ไม่เข้าใจกรรมวิธี hash และใช้ salt ร่วมด้วย แนะนำให้อ่าน Hash: ไม่รู้ว่ามันคืออะไรแต่มันใช่ เผื่อจะเข้าใจมากขึ้น ว่าสิ่งที่ Starbucks กำลังทำอยู่นั้นเป็นสิ่งที่ยอมรับไม่ได้ และสามารถดูตัวอย่างเว็บที่ไม่ใส่ใจกับข้อมูลอ่อนไหวเหล่านี้ได้ที่ Plain Text Offenders

จากเหตุการณ์นี้ หลายคนอาจจะยังไม่เข้าใจปัญหาที่อาจจะเกิดขึ้นในอนาคต ผมจึงขอยกตัวอย่างง่ายๆ ว่าในอนาคตหากเว็บ Starbucks ถูกแฮก และเหล่าผู้ไม่ประสงค์ดีได้ทำการ dump ข้อมูลลูกค้าพร้อมรหัสผ่านออกไป การไม่คงสภาพรหัสผ่านที่สามารถย้อนกลับมาเป็น plain text ได้ จะช่วยปกป้องให้รหัสผ่านต่างๆ ของลูกค้าของตัวเองยังคงปลอดภัยอยู่สักระยะจากการใช้วิศวกรรมย้อนกลับ เพราะต้องใช้เวลาในการคำนวณ และกู้สภาพย้อนกลับผ่าน rainbow table (หรือการทำ rainbow hash cracking) แน่นอนว่าการใช้ salt ร่วมด้วยก็ช่วยได้ในระดับที่น่าพอใจ ซึ่งดีกว่าการจัดเก็บรหัสผ่านเป็นข้อมูล plain text ซึ่งผู้ไม่ประสงค์ดีสามารถนำไปใช้ได้เลยโดยไม่จำเป็นต้องใช้เทคนิคพิเศษใดๆ

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

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