Find my iPhone ไม่ต้องใช้ Two-step verification สำหรับเข้าใช้งานบน iCloud.com แม้จะเปิดใช้งาน Two-step verification ใน Apple ID

แม้เราจะเปิด Two-step verification ใน Apple ID แล้ว แต่ยังมีความสามารถหนึ่งที่ชื่อ Find my iPhone ที่สามารถเข้าถึงได้ทันทีโดยไม่ต้อง verify ผ่าน Two-step verification ได้ ทำให้เข้าไปดูว่าเครื่องที่ใช้กับ account นั้นอยู่ที่ไหน (Locate) ใช้เล่นเสียง (Play Sound), เข้าโหมดแจ้งหาย (Lost Mode) และแม้แต่ลบข้อมูล (Erase iPhone) ได้

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

ซึ่งแตกต่างจากค่ายอื่นๆ ที่ใช้อีเมล หมายเลขโทรศัพท์สำรอง รวมไปถึง recovery code ในการเข้าใช้งานแทน verification code ที่จะส่งมาให้กับ trusted device ที่อาจจะทำหายไปแทน ซึ่งดูแล้วไม่รัดกุมเท่าไหร่นัก

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

หมายเหตุ ไม่รู้ว่าหาไม่เจอ หรือว่ามันเป็นแบบนี้อยู่แล้วนะ คือผมพยายามหาที่เปิดใช้ Two-step verification ในส่วนของ Find my iPhone แต่หาไม่เจอ ใครทราบเม้นไว้ก็ได้ครับ

2015-09-26_231445

ปิดความสามารถที่ทำตัวเสมือน keylogger ใน Windows 10 ที่จะส่งข้อมูลให้ Microsoft

ซอฟต์แวร์ในปัจจุบันมักมีการส่งข้อมูลพฤติกรรมการใช้งานของลูกค้ากลับไปยังผู้ผลิต เพื่อปรับปรุงตัวซอฟต์แวร์ และสร้างประสบการณ์ที่ดีในรุ่นถัดไปจนเป็นเรื่องปรกติ และใน Windows 10 นั้น มีการเก็บข้อมูลพฤติกรรมบางอย่างที่สุ่มเสี่ยงต่อการเก็บข้อมูลสำคัญ เช่น รหัสผ่าน หมายเลขบัตรเครดิต หรือข้อมูลธุรกรรมทางการเงินที่สำคัญ ซึ่งดักจับผ่านการพิมพ์บนคีย์บอร์ด (keylogger) แล้วนำส่งไปที่ Microsoft ซึ่งยังไม่มีรายงานว่าการเก็บข้อมูลที่พิมพ์ไปนั้น มีอะไร เก็บรักษาอย่างไร ปลอดภัยและไว้ใจได้แค่ไหน

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

ขั้นตอนมีดังนี้

1. ไปที่ Start menu เลือก Settings

image

2. เลือกหัวข้อ Privacy

image

3. ในหัวข้อ General ที่ตัวเลือก Send Microsoft info about how I write to help us improve typing and writeing in the future ให้เลือกเป็น Off

2015-09-09_211214

4. ที่หัวข้อ Speech, inking, & typing ให้กดปุ่ม Stop Getting to know me เพื่อปิดการรับข้อมูลของ Cortana

2015-09-09_211247

ขั้นตอนไม่ได้ยุ่งยากซับซ้อนแต่อย่างใด โดยส่วนตัวแล้วแนะนำให้ปิดครับ

DNSSEC และ DANE ช่วยป้องกันการโดน Pharming และป้องกันการออก Certficate ปลอมหรือซ้ำซ้อน

การทำ DNSSEC ช่วยป้องกันการโดน Pharming (หรือเรียก DNS spoofing หรือ DNS cache poisoning) เพราะเป็นการ signed ตัว DNS Server ที่ใช้งานคู่กับ domain name ที่จดกับผู้รับจด domain เวลาตรวจสอบคำตอบที่ Resolver จะเช็คว่ามาจาก Name server ตัวจริงหรือไม่ ช่วยให้การได้รับ IP ส่งให้ client มีความถูกต้องเสมอ (ทดสอบแบบง่ายๆ คือแก้ไขไฟล์ hosts บนเครื่องให้วิ่งไปอีกเครื่องหนึ่งที่มีข้อมูลเหมือนกันทุกประกาศ ทำตัวเหมือนโดน trojan มาเปลี่ยนบนเครื่องให้ไปเครื่องปลอมเพื่อหลอกเอาข้อมูล)

image 

image

image

image

 

สำหรับการทำ DANE ป้องกันการถูก fake certificate หรือเจอ Certification Authority ออกใบ certificate ซ้ำซ้อน เพราะเราจะเอา fingerprint ของ certificate ใส่ลงใน TLSA record บน DNS Server ทำให้ตอนตัว browser เรียกเว็บ จะมีการตรวจสอบว่า certificate ที่ได้มา มี fingerprint ตรงกับที่อยู่ใน TLSA record หรือไม่

image 

image

 

ซึ่งทั้งสองอย่างยังไม่ค่อยเจอเว็บทั่วไปทำสักเท่าไหร่ และ browser ทั้ง 3 อันดับแรก ถ้าไม่ลง plugins ก็ยังตรวจสอบไม่ได้ครับ แต่เชื่อว่าอีกสักพักคงทยอยค่อยๆ ปรับกันมาแล้ว และเว็บในไทยที่เท่าที่เจอยังไม่ค่อยมีใครทำขนาด Google, Facebook, Micorosft ยังไม่ทำเลย

การทำให้เว็บรองรับ DNSSEC และ DANE ช่วยเพิ่มระบบในการป้องกันการที่ผู้ใช้งานเข้าใช้บริการของเว็บต่างๆ ได้ปลอดภัยมากขึ้นจากการทำ Man-in-The-Middle attacks ได้

วิดีโออธิบายการทำงานของ DNSSEC และ DANE

Tutorial on DANE and DNSSEC

ตัวอย่างเว็บที่ implement DNSSEC หรือ DANE

อ้างอิง

คำแนะนำในการเก็บรหัสผ่านในระบบสำหรับนักพัฒนาซอฟต์แวร์ และผู้ดูแลระบบไอที

คำแนะนำนี้เหมาะสำหรับนักพัฒนาซอฟต์แวร์ และผู้ดูแลระบบไอทีเป็นสำคัญ สำหรับบุคคลทั่วไปแนะนำให้อ่าน ตั้งรหัสผ่านอย่างไรให้ปลอดภัย แทนนะครับ

จริงๆ เจอเคสในการเก็บรหัสผ่านเป็นแบบ plaintext หรือเก็บรหัสผ่านแล้วสามารถย้อนกลับเป็น plaintext เดิมๆ ได้โดยง่าย ซึ่งผมเจอเคสแบบนี้บ่อยค่อนข้างมาก และคิดว่าควรจะเขียนเรื่องนี้สักครั้งหนึ่ง

หลักของการเก็บรหัสผ่านในฐานข้อมูลนั้น

1. ไม่ใช่การเก็บตัวรหัสผ่านจริงๆ ลงไป

2. ไม่ควรใช้การจัดเก็บรหัสผ่านที่สามารถย้อนกลับมาเป็นรหัสผ่านต้นทางได้ ไม่ว่าจะทางใดก็ทางหนึ่ง

หลักง่ายๆ ก่อน 2 ข้อนี้ ทำให้เกิดวิธีคิดในการเก็บรหัสผ่านเพียงแค่ hash (หรือบางเอกสารเรียก fingerprint หรือค่า message digest) ของรหัสผ่านนั้นๆ กล่าวคือ การกระทำใดๆ ในตัวระบบ ต้องไม่มีความสามารถที่สามารถย้อนกลับวิธีการได้มาซึ่งข้อมูล hash ได้ (Non-invertibleเพื่อเป็นการป้องกันรหัสผ่านที่แท้จริงจากการนำไปใช้งานได้ทันทีหลังจากระบบถูก hack แล้วถูก dump ข้อมูลเหล่านี้ออกไป เพราะแม้ว่ารหัสผ่านที่ถูกนำออกไปจะเป็นเพียงแค่ hash ของข้อมูล แต่การโจมตีแบบ rainbow table attacks ก็สามารถถอดรหัสผ่านใดๆ ที่เป็นเพียงแค่ค่า hash ย้อนกลับมาเป็นรหัสผ่านเดิมได้ไม่ช้าก็เร็ว เพราะแม้มีความเป็นไปได้น้อยมากๆ แต่ก็ถือว่ามีความเสี่ยง

หลักการขอ rainbow table attacks คล้ายๆ การ brute force รหัสผ่านโดยทั่วไป แต่เป็นการกระทำต่อ hash เป็นหลัก โดยสุ่มชุดข้อมูลที่คิดว่าเป็นรหัสผ่าน มาเข้าขั้นตอน hash ที่เป็นที่นิยมใช้ให้ได้ซึ่งค่า hash แล้วเอาชุดข้อมูลดังกล่าว ใส่ลงในฐานข้อมูล rainbow tableไว้ แล้วเมื่อมีการ hack ระบบเกิดขึ้นแล้วได้ชุดข้อมูล hash ที่ dump ออกมา ก็เอาไปทดสอบเทียบกับชุดข้อมูลในฐานข้อมูลที่สร้างไว้ก่อนหน้านี้ ก็จะย้อนกลับมาได้ว่า ข้อมูล plaintext ที่เป็นส่วนย้อนกลับของ hash มีค่าใด

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

โดยด้านล่างเป็นลักษณะของฟังค์ชั่นโดยทั่วไปที่มักใช้กัน

[hash] = [salt] + [hash_function([salt] + [password])]

[salt] = เป็นการสุ่มจากวิธีการสุ่มใดๆ ที่ปลอดภัยที่สุดเท่าที่ทำได้ คำแนะนำคือควรใช้วิธีการสุ่มจากฟังค์ชั่นแบบ Cryptographically Secure Pseudo-Random Number Generator (CSPRNG)

[hash_function] ก็เลือกว่าจะเอาตัวไหนก็ได้ แต่ที่ใช้ๆ กันก็ แต่พวก MD5 หรือ SHA-1 ที่มันหาง่าย แต่มันก็แข็งแรงน้อยลงมากๆ ไม่แนะนำ และเดี่ยวนี้มันพูดกันที่ระดับ SHA-2 กันไปแล้ว (SHA-2 = SHA-256 หรือ SHA-512)

จริงๆ สูตรฟังค์ชันด้านบนนั้น มีชุดคำสั่งสำเร็จรูปที่นิยมกันที่ชื่อ PBKDF2 เพราะมีการกำหนดชุดการฟังคัชันในการ hash, จำนวนรอบในการสุ่ม และกำหนดความยาวของ hash ได้หลากหลาย ทำให้ยากมากขึ้นในการได้มากซึ่ง plaintext ที่แท้จริงจาก rainbow table

hash= PBKDF2(hash_function_name, password, salt, iterations, length)

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

โดยการทำแบบนี้ “ช่วยให้ผู้ใช้งานทั้งระบบยังพอมีเวลาในการปรับเปลี่ยนรหัสผ่านชุดใหม่ได้ใน ระยะเวลาที่น่าจะปลอดภัยมากที่สุด” เพราะหากว่ากันตามความเป็นจริงแล้ว ในวงการด้านการเข้ารหัสข้อมูลนั้น ทราบกันดีว่า ไม่มีวิธีการใดอะไรที่สามารถเข้ารหัสข้อมูลได้ปลอดภัยที่สุดไปตลอดกาล เพราะเทคโนโลยีด้านการคำนวนของ CPU/GPU นั้นเร็วมากขึ้นทุกวัน การจัดเก็บข้อมูลที่ปลอดภัยในช่วงเวลาหนึ่งอาจไม่ปลอดภัยในอีกไม่กี่ปีต่อมา เพราะเราสามารถแกะ และคำนวนหาค่าต่างๆ หรือสุ่มชุดข้อมูลต่างๆ ได้เร็วและหลายหลากขึ้น ตาม CPU/GPU ที่เร็วขึ้นเพื่อมาสร้าง rainbow table ได้ทุกขณะ

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

อ้างอิง

Ref: https://www.flickr.com/photos/nyuhuhuu/4443886636

เว็บ se-ed.com เก็บรหัสผ่านสมาชิกของร้านเป็น plaintext!

เมื่อวานนั่งหาหนังสือ กะว่าจะสั่งหนังสือสัก 2-3 เล่ม แต่ลืมรหัสผ่าน se-ed.com เลยเข้า https://www.se-ed.com/forgot-password.aspx เพื่อขอขั้นตอนการปลดล็อคผ่านทางอีเมลเพื่อเข้าระบบ

2014-09-08_110337

 

แต่สิ่งที่ได้กลับมาทำให้ตกใจไม่น้อยเพราะ….

2014-09-08_110831

 

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

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