Security

บั๊ก Heartbleed และความใส่ใจต่อการใช้ TLS/SSL ในเว็บคนไทย

by

ว่ากันตามจริง เว็บคนไทยส่วนใหญ่ไม่ได้รับผลกระทบจากบั๊ก Heartbleed กันเสียเท่าไหร่นัก เพราะ “ส่วนใหญ่ไม่ใช้ TLS/SSL” ซึ่งแม้แต่เว็บอันดับต้นๆ ของไทยเท่าที่ตรวจสอบก็ไม่ได้ใช้แม้จะมีการรับ-ส่งข้อมูลสำคัญเช่น ชื่อสมาชิก และรหัสผ่าน อย่าเป็นเรื่องปรกติ

ในความคิดเห็นส่วนตัวแล้วอยากให้มีการออกประกาศ เพื่อสร้างความใส่ใจต่อการคุ้มครองข้อมูลส่วนตัวว่า “เว็บไทยที่มีการรับข้อมูลที่สำคัญ จำพวกชื่อสมาชิก และรหัสผ่าน ควรใช้ TLS/SSL ในการติอต่อสื่อสารข้อมูลอย่างยิ่ง” เพราะเว็บคนไทยเราน้อยมากที่จะใช้ TLS/SSL ซึ่งหากเว็บที่ไม่ได้ใช้ TLS/SSL ในขั้นตอนการรับ-ส่งข้อมูลสำคัญเหล่านั้นเป็นปัญหาที่หนักหนาสาหัสกว่าบั๊กของ Heartbleed มากนัก เพราะปัญหาบั๊ก Heartbleed นั้นตั้งถูกตั้งบนสมมติฐานว่า private key อาจจะถูกขโมยไป ทำให้การดักฟังข้อมูลระหว่างเว็บและสมาชิกที่สื่อสารบน TLS/SSL ถูกดักฟังได้จากการใช้ private key ที่ถูกขโมยไปนำมาถอดรหัสเพื่อดักฟัง แต่เว็บที่ไม่มี TLS/SSL เพื่อบริการให้กับสมาชิกโดยป้องกันการถูกดักฟังนั้น คนดักฟังไม่ต้องสนใจว่าจะหาอะไรมาถอดรหัสออดแต่อย่างใด เพราะข้อมูลที่สื่อสารไปมานั้นมันเปลื่อยโล่งทั้งหมด ใครดักฟังก็เห็นได้ทันที และมันเป็นปัญหาที่ใหญ่กว่ามาก

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

หมายเหตุเพิ่มเติม: Heartbleed เป็นบั๊กที่เป็นข้อผิดพลาดของซอฟต์แวร์สำหรับการติดต่อสื่อสารที่ชื่อ OpenSSL ซึ่งเป็นเพียงซอฟต์แวร์ยอดนิยมสูงมากตัวหนึ่งในกลุ่มใช้ open souce software ที่ใช้เป็นมาตรฐานสำหรับการติดต่อสื่อสารแบบ TLS/SSL ซึ่งมีผลกระทบต่อระบบที่ใช้งาน TLS/SSL เป็นวงกว้างมาก แต่กระนั้นในตลาดก็ยังมีซอฟต์แวรเข้ารหัสในรูปแบบเดียวกันตัวอื่นๆ ที่ไม่ได้รับผลกระทบเช่นระบบ IIS ของ Microsoft (ที่ธนาคารไทยส่วนใหญ่ใช้) หรือซอฟต์แวร์เข้ารหัสการสื่อสารตัวอื่นๆ ที่ไม่ได้ใช้ OpenSSL เป็นตัวเข้ารหัสการติดต่อสื่อสารด้วย TLS/SSL

ต่อไปรหัสผ่านอาจจะไม่จำเป็นสำหรับทุกๆ เว็บ

by

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

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

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

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

by

จากกระทู้ต้นเรื่อง Starbucks Thailand ทำแบบนี้ได้ไง

ผมเลยลองทดสอบดูตามข้อมูลที่ https://www.starbuckscard.in.th/cards/forgot-password.aspx

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

2014-03-04_101432แน่นอนว่าไม่ใช่แค่เว็บเท่านั้น เมื่อเกือบ 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 ถูก hack และเหล่าผู้ไม่ประสงค์ดีได้ทำการ dump ข้อมูลลูกค้าพร้อมรหัสผ่านออกไป การไม่คงสภาพรหัสผ่านที่สามารถย้อนกลับมาเป็น plain text ได้ จะช่วยปกป้องให้รหัสผ่านต่างๆ ของลูกค้าของตัวเองยังคงปลอดภัยอยู่สักระยะจากการใช้วิศวกรรมย้อนกลับ เพราะต้องใช้เวลาในการคำนวณ และกู้สภาพย้อนกลับผ่าน rainbow table (หรือการทำ rainbow hash cracking) แน่นอนว่าการใช้ salt ร่วมด้วยก็ช่วยได้ในระดับที่น่าพอใจ ซึ่งดีกว่าการจัดเก็บรหัสผ่านเป็นข้อมูล plain text ซึ่งผู้ไม่ประสงค์ดีสามารถนำไปใช้ได้เลยโดยไม่จำเป็นต้องใช้เทคนิคพิเศษใดๆ

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

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

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

ระบบรักษาความปลอดภัยในเครื่องที่ผมใช้

by

DSC_6603

เครื่องโน๊ตบุ๊ค Lenovo/IBM ThinkPad ที่ผมใช้มา 3 เครื่องนั้นสามารถตั้งรหัสผ่านก่อนที่จะเข้าสู่ OS Mode อยู่ 3 ส่วนคือ

image Power On Password (POP)

image Hard Disk Password (HDP)

image Supervisor Password (SVP)

โดยทั้ง 3 ส่วนนั้นรหัสผ่านถูกเก็บรักษาและหรือ Encrytion Key อยู่บน Trusted Platform Module (TPM) โดยในปัจจุบัน เครื่องที่ผมใช้คือ ThinkPad T420 นั้นมาตรฐาน TCG Ver.1.2 Compliant chip (ผมไม่รู้ขั้นตอนแน่ชัดในการเก็บว่ามันเก็บแค่ Key หรือเก็บ Passphrase ทั้งหมด)

image
รูปจาก tabletkiosk.com

เพราะฉะนั้นถ้าผมดันไปลืมรหัสผ่านทั้ง 3 ตัวด้านบน หรือมีคนพยายามเข้าสู่เครื่องผมจะไม่สามารถใช้การ reset ด้วยวิธีเอา Backup Battery บน M/B ออกและใส่กลับไปใหม่ได้ เพราะรหัสนั้นอยู่บน Trusted Platform Module (TPM) โดยเป็น chip ที่สามารถคงสภาพรหัสไว้ได้แม้จะไม่มีไฟฟ้าเลี้ยงอยู่เลย ถ้าลืมก็มีอย่างเดียวคือเปลี่ยน M/B ในกรณีที่ลืม Power On Password (POP) หรือ Supervisor Password (SVP) และเปลี่ยน HDD ในกรณีที่ลืม Hard Disk Password (HDP) กันไปเลย

ส่วนวิธีใต้ดินในการ Hard Reset ตัว Trusted Platform Module (TPM) ก็มีให้เห็นอยู่บ้าง แต่ใช้ไม่ได้กับทุกๆ System เพราะฉะนั้นก็ต้องเสี่ยงดวงเอากันเอง (มีคนทำได้แต่รุ่นเก่าๆ เมื่อ 3-4 ปีก่อน ยังไม่เห็นรุ่นใหม่ๆ ทำได้ แต่ในอนาคตไม่แน่)

เมื่อผ่าน 2 รหัสผ่านด้านบนได้ (อีก 1 ตัวคือ SVP เป็นรหัสจัดการ BIOS และระบบอื่นๆ เป็นหลัก ไม่ค่อยได้ใช้) ก็มาถึงตอนเข้า OS กัน ส่วนตัวแล้วใช้ Windows 7 และใช้ Biometric Device ในส่วนของ Fringerprint ในการเข้าระบบ โดยผมตั้งให้มัน override ตัวรหัสผ่าน 2 ตัวก่อนหน้านี้ทั้งหมด ถ้าผมเปิดเครื่องผ่านการแสกนลายนิ้วมือผมได้ และเมื่อเข้าถึง Windows 7 ก็ให้ login เข้าตัว Windows ผ่านไปได้เลย ไม่งั้นผมต้องใส่รหัสผ่านทั้งหมด 3 ครั้ง Power On Password, Hard Disk Password และ Windows Authentication

2011-12-30_102139

เข้าใช้งานได้ ตัวที่รักษาความปลอดภัยระหว่างทำงานตลอดเวลาป้องกัน การติด Malware ก็คือ Norton AntiVirus 2012 ตัวนี้ เมื่อก่อนผมว่าใช้ ESET NOD32 แต่เพิ่งเปลี่ยนมาใช้ได้ไม่นาน เพราะเบากว่า กินทรัพยากรน้อยกว่า และมีระบบตรวจจับรุ่นใหม่ที่ทันสมัยกว่า รวมไปถึงมี Feature ที่คุ้มค่าตัวอีกด้วย

2011-12-30_102235

เมื่อป้องกัน Realtime ในส่วนของ Process แล้ว ก็มีป้องกันส่วนของ Network กัน ส่วนตัวแล้วใช้ COMODO Firewall เป็นหลักในการป้องกัน เมื่อช่วงแรกๆ ที่ใช้ Windows 7 ผมจะใช้ Windows Firewall with Advanced Security แต่มาตอนหลังผมกลับมาใช้ COMODO Firewall อีกครั้ง เพราะชินกับตัวนี้มากกว่า และก็ป้องกันได้ดีในระดับที่น่าพอใจอีกด้วย

2011-12-30_102254

สุดท้าย ก็เป็นระบบ AutoLock ของ ThinkPad เอง

เป็นการใช้ Webcam ที่มีอยู่ในทุกๆ เครื่อของ ThinkPad ในปัจจุบันมาทำการตรวจสอบว่ามีผู้ใช้งานอยู่ที่หน้าเครื่องตามเวลาที่กำหนดหรือไม่ โดยมันจะเปิด Webcam แอบมองโดยใช้ Face Detection ในการตรวจสอบ ถ้าในระยะเวลาที่ตั้ง Keyboard/Mouse ไม่ได้ถูกใช้งาน จะเปิด Webcam ตรวจสอบ ถ้ามีคนอยู่มันจะไม่ Lock เครื่อง แต่ถ้าไม่มีคนอยู่ ก็จะทำการ Lock เครื่องให้ทันที แทนที่จะรอให้ Screensaver Password ทำงานตามเวลาที่กำหนดไว้ตายตั ก็ทำงานตัดหน้าก่อนไปเลยนั้นเอง

2011-12-30_102044

ดูเหมือนเยอะ แต่ถ้าข้อมูลคุณสำคัญก็แนะนำให้ทำไว้ครับ จริงๆ ถ้าทำ Full Encrytion จะเยอะกว่านี้อีกนะ แต่นี่ยังไม่ได้ทำทั้งหมด เหลืออีกหลายส่วน และคิดว่าคงไม่ทำ เพราะมันทำให้ OS/HW ช้าลงไปอีก เอาแค่นี้ก็เพียงพอสำหรับผมแล้ว ;)

ใหม่!!! Firefox 1.0.3 ปิดช่องโหว่อันตราย

by

เมื่อวานเพิ่งอัพเกรดไปหยกๆๆ

ใหม่!!! Firefox 1.0.3 ปิดช่องโหว่อันตราย
โดย กองบรรณาธิการเว็บไซต์ ARiP.co.th อัพเดต 17 เมษายน 2005 เวลา 9:26 น.

รายงานข่าแจ้งว่า Mozilla Foundation ออกบราวเซอร์ Firefox และชุดซอฟต์แวร์ Mozilla เวอร์ชันใหม่แล้ว โดยเป็นเวอร์ชันที่ได้รับการแก้ไขช่องโหว่ต่างๆ ที่ได้เคยรายงานข่าวไปแล้ว ก่อนหน้านี้ ได้มีการรายงานข่าวถึงช่องโหว่ของความปลอดภัยในกลไกการทำงานของ JavaScript ล่าสุดช่องโหว่ดังกล่าวได้มีการแก้ไขเรียบร้อยแล้ว โดยในเวอร์ชั่นใหม่ได้มีการแก้ไขช่องโหว่วิกฤติที่พบ 3 แห่งใน Firefox แต่ก็จะพบช่องโหว่ดังกล่าวด้วยใน Mozilla ถึง 2 แห่ง ช่องโหว่ทั้งหมดยังจะได้มีการแก้ไขเข้าไปในชุดซอฟต์แวร์อัพเกรด Firefox ด้วย ส่วนเมล์ไคลเอ็นต์อย่าง Thunderbird ยังไม่มีรายงานการปรับปรุงใดๆ ทั้งสิ้น
สำหรับ 3 ช่องโหว่วิกฤติที่แก้ไขไปแล้วนั้น มี 2 ช่องโหว่ที่เกิดจากการรันโค้ดที่ไม่ปกติ เพื่อนำไปสู่การได้รับสิทธิ์ในการเข้าถึงระบบ
ช่องโหว่แรกเป็นข้อผิดพลาดของการสนับสนุนการทำงานกับ favicons (ไอคอนเล็กๆ ที่อยู่หน้า URL ในช่อง Address ของบราวเซอร์) ที่ผู้บุกรุกสามารถรันสคริปท์ เพื่อยกระดับสิทธิ์ในการเข้าถึง และติดตั้ง หรือสั่งรันซอฟต์แวร์ได้ตามอำเภอใจ
ช่องโหว่ที่ 2 จะเกิดกับ Firefox โดยเฉพาะ โดยจะยอมให้สคริปท์อันตรายเปิดหน้า privilege ที่อยู่ด้านข้าง (sidebar) เพื่อส่งสคริปท์ที่สามารถใช้ในการติดตั้งโค้ดอันตราย หรือขโมยข้อมูลก็ได้
ช่องโหว่ที่ 3 จะมีลักษณะแตกต่างออกไป โดยพบจะอยู่ในส่วนของโค้ด UI ที่ใช้ในการรันสคริปท์ของผู้ใช้ ซึ่งทาง Mozilla ยังไม่ได้เปิดเผยรายละเอียดเกี่ยวกับบั๊กตัวนี้จนกว่าจะถึงวันที่ 25 เมษายน

ดาวน์โหลด Firefox 1.0.3 คลิกที่นี่