จากกระทู้ต้นเรื่องใน Pantip.com หัวข้อ Starbucks Thailand ทำแบบนี้ได้ไง โดยสมาชิกชื่อ boatiso9002 ตรวจสอบพบว่า 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 ออกไป ซึ่งเกิดเหตุการณ์เหล่านี้กับบริการหลายๆ บริการอยู่เป็นประจำ
คำแนะนำสุดท้าย แม้ไม่ใช่ทางออกที่ดีที่สุดซึ่งควรเป็นความรับผิดชอบของผู้ให้บริการ แต่ทางแก้ไขที่ดีกว่าเพื่อปกป้องตัวเองจากการที่ผู้ให้บริการไร้ซึ่งจิตสำนึกต่อข้อมูลส่วนตัวสมาชิก คือการพยายามใช้รหัสผ่านแยกกันไปในแต่ละบริการ เพื่อมั่นใจในความปลอดภัยของบริการอื่นๆ ที่จะไม่ถูกนำรหัสผ่านไปอ้างอิงใช้งานได้ในอนาคต
Comments
ปรับแก้แล้วครับ แต่ข้อสุดท้ายลองปรับอีกแบบนึง
@ Virusfowl
I'm not a dev. not yet a user.
เอ ถ้าเป็น wp ลง plugin อะไรสักอย่าง
ตอนสมัครมันกะเมลระบบมันก็ส่งมาโต้งๆ
นะแต่ใน database ก็เข้ารหัส hash ปกติ
เชคกับแอดมินเขาก่อนดีไหมเป็นแบบที่ผมว่าจะเกิดอาการเงิบกันไปซะก่อน
Ton-Or
ถ้าส่งรหัสมาโต้งๆ ยังไงก็ต้องมีเก็บรหัสไม่ว่าจะแบบเข้าหรือไม่เข้ารหัสไว้นอกจาก hash ล่ะครับ
อันนี้คือ เค้าส่งมาตอน Forgot Password ครับ ซึ่งมันข้ามขั้นตอนที่จะเก็บรหัสไว้ใน ตัวแปร หรือ session ไปแล้ว
แต่ถ้าส่งตอน register อาจจะส่งมาได้ เพราะว่ามีการส่งเมลล์ทันที ก่อนจะเก็บเข้า database
อันนั้นน่าจะเป็น one-time-password ครับ มันสร้างแล้ว hash จากนั้นค่อย flag ว่าบังคับเปลี่ยนรหัส
จริงๆ ก็คล้ายๆ reset link ล่ะครับ แค่ใช้คนละแนวทางกัน
แต่ไม่สามารถกดลืมรหัสผ่านแล้วส่งกลับออกมาได้แน่ๆ
lewcpe.com, @wasonliw
รหัสผ่านของ WP ที่สร้างขึ้นหลังจากติดตั้ง เป็นรหัสผ่านที่ถูกสร้างขึ้นแบบ random และส่งมาทางอีเมล และในฐานข้อมูลได้ถูก hash ไว้ และไม่สามารถย้อนกลับได้ครับ
ส่วนในเคสด้านบนเป็นรหัสผ่านเป็นรหัสที่ผมตั้งขึ้นมาเอง ไม่ได้เกิดจากการ random ใดๆ ทั้งสิ้น ซึ่งผมเคยกรอกอะไรไว้ ซึ่งเมื่อผม forgor ก็ก็ส่งมาแบบที่เคยได้กรอกไว้ตอนสมัครครับ
เข้ามา edit อีกรอบไม่ทัน
พิมพ์ว่าผมเงิบเอง ที่ลืมพาสมันก็ยังส่งมา
55
Ton-Or
my.sony.co.th ด้วยครับ
ลองแล้วเหมือนจะเป็น otp link แล้วครับ ไม่ได้ส่งรหัสผ่านมาให้นะครับ
ขอบคุณสำหรับหรับข่าวมากๆ เลยนะครับ รีบเปลี่ยน Password ในบัดดล
แล้วก็ขอบคุณคุณ Ford AntiTrust ที่นอกจากอ่านเจอแล้วยังทดสอบยืนยันก่อนจะเผยแพร่ข้อมูลอีกด้วย และฝากขอบคุณไปถึงคุณ boatiso9002 (ถ้าเขาจะมีโอกาสเข้ามาอ่าน)จากเวปพันทิปด้วยนะครับ
นอกจากเรื่องนี้แล้ว .. ตอนนี้ถ้าจ่ายเงินด้วย Starbucks card จะพิมพ์ชื่อจริง + นามสกุลผู้ถือบัตร ลงในใบเสร็จด้วยครับ ก่อนทิ้งเลยต้องฉีกก่อน ลำบากเลย
เซ็งพวกพิมพ์ชื่อ-นามสกุลลงบนใบเสร็จเหมือนกันครับ
7-11 ก้อด้วย
เคยเจอกับ nationejobs ด้วยครับ ตอนนั้นหางานอยู่ พอได้งานแล้วไม่ได้เข้าไปอีก มีส่งเมล์มาเตือนแถมส่ง user+password มาให้ด้วย
อ้าว ถ้างั้น web ยื่นภาษี online ก็ไม่ปลอดภัยแล้วล่ะครับ มันบอก password ขึ้นหน้า web เลย โดย hack ขึ้นมาข้อมูลเงินเดือน ประวัติส่วนตัว ที่อยู่ คงหลุดหมด
ไม่ปลอดภัยครับ รายนั้นยิ่งแย่ ต้องระวังห้ามใช้รหัสผ่านซ้ำกับบริการใดๆ ทั้งสิ้น
lewcpe.com, @wasonliw
ใช่ครับ พวกนี้ผมใช้แยกรหัสไปเป็นส่วนๆ เลยไม่ใช่ปนกันเด็ดขาด
เหวอ
บางบริการมีการเช็คว่า พาสเวิร์ดใหม่ต้องต่างจากของเดิมอย่างน้อย xxx ตัวอักษร
ผมว่านี่ก็เซฟเป็น plain text เหมือนกัน
เออจริง ไม่งั้นจะเช็คได้ไง เพราะถ้า Hash แล้ว
พอเปลี่ยนพาส นิดๆ หน่อยๆ Hash มันก็จำหน้าตากันไม่ได้แล้ว XD
(ยกเว้นใช้พาสเดิมเป้ะๆ)
เหมือนมีที่ผมใช้อยู่นี่แหละ -_-
ถ้าต้องกรอกพาสเดิมด้วยตอนเปลี่ยนรหัส อาจจะเช็คจากตรงนั้นก็ได้นะครับ
ก็เอารหัสเดิมไปเข้ารหัสถ้าถูกมันก็ได้รหัสเก่ามาไงครับ
ต้องเป็นรหัสที่ไม่เคยใช้มาก่อนสามครั้งหลังสุด =_=
onedd.net
อันนี้เช็คจาก hash ได้นี่ครับ คงไม่ใช่ปัญหา
ของผมล็อกอินเข้ามาแล้ว พอจะเปลี่ยนพาสเวิด มันบอกว่าพาสเวิดเก่าผมผิด
มันคืออัลไล..
ผมก็เป็นครับ ตัดปัญหาเปลี่ยน mail เลย
เว็บของ 3bb ด้วยครับ
Warning: ociexecute(): ORA-01401: inserted value too large for column in C:\xampp\htdocs\iec3g\web\iec3g_editpassword_save.php
เดาได้ไม่ยากว่า Plain Text (เหมือนว่าจะ SQL Injection ได้ด้วย..)asiabooks ด้วยครับ
โทษบริษัทเจ้าของเว็บอย่าง Starbuck ไม่ได้ เพราะเขาไม่ได้เชี่ยวชาญด้าน IT โดยเฉพาะ
ต้องโทษ บริษัท Vendor ที่รับงานทำเว็บหรือทำระบบให้
เวลาส่งมอบงานเจ้าของก็ไม่มี skill พอที่จะตรวจสอบ
Starbuck และอื่นๆ นั่นแหละคือเหยื่อของบริษัทเหล่านี้
ต้องสืบว่าบริษัทไหนทำให้
แล้วเอารายชื่อบริษัทไร้จรรยาบรรณเหล่านี้มาขึ้นบัญชีดำซะให้เข็ด
ทำไมจะโทษไม่ได้ครับ ถือเป็นจำเลยแรกเสียด้วยซ้ำ เพราะระบบที่พัฒนาทำงานอยู่ภายใต้แบรนด์ของตน ฉะนั้น จะปัดความรับผิดชอบไม่ได้ และในความเป็นจริง ปรกติบริษัทพวกนี้ถ้าไม่ถนัดงานด้านใด ก็มักจ้าง consult หรือ audit เพิ่มเติมอยู่แล้ว การใช้หลักคิดแบบนี้อาจไม่ถูกต้องและเป็นการปัดความรับผิดชอบ
เปิดถุงขนมมา เจอเชื้อรา จะโทษบริษัทขนมเจ้านั้นหรือโทษ "ชาวไร่ปลูกมันฝรั่ง,บริษัทที่ขายเครื่องจักร," ครับ?
โอเคครับ โทษได้ พอดีผมพิมไม่หมด
กะจะบอกว่า "โทษ starbuck อย่างเดียว ไม่ได้"
ผมแค่ต้องการจะสื่อว่า vendor จะอยู่หลังฉาก
และแทบไม่เคยมีชื่ออยู่ในข่าวเวลาเกิดความเสียหายเสมอ
และเขาก็ยังรับงานอื่นๆได้เรื่อยๆ แถมยังได้ profile ถ้าพัฒนาให้กับบริษัทดังๆ
vendor ที่มีจรรยาบรรณ ควรจะทำให้ดีมาตั้งแต่แรก
ไม่ใช่รอให้ audit แล้วค่อยแก้งาน
จะโทษจะว่าบริษัทเจ้าของ ก็โอเคอยู่
แต่อย่าลืมโทษ "เบื้องหลัง" ของความเสียหายด้วยครับ
ที่ผมพูดถึงประเด็นนี้เพราะเจอมากับตัว คือบริษัทผมจ้าง vendor พัฒนา
กว่าจะมาให้ผมเห็น code ข้างในก็สายไปเสียแล้ว
แค่ content web ธรรมดา กลับจ่ายไปหลักแสนโดยที่ระบบหลังบ้านยังใช้งานไม่ได้
จ่ายเงิน ปิดงาน อะไรไปเรียบร้อยแล้ว ทำอะไรไม่ได้เลย แถมหนีอีก
เลยคิดว่าหลายๆบริษัทคงเจอปัญหาเดียวกับบริษัทผม
สทศ. ก็ใช่ย่อย วันนั้นผมโทรไปเรื่องลืมรหัส พี่แกดันบอกรหัสผ่านมาให้เลย