ทำไมคุณควรกังวลเมื่อมีการรั่วไหลของฐานข้อมูลรหัสผ่านของบริการ
“ ฐานข้อมูลรหัสผ่านของเราถูกขโมยเมื่อวานนี้ แต่ไม่ต้องกังวลรหัสผ่านของคุณถูกเข้ารหัส” เราเห็นข้อความเช่นนี้ออนไลน์เป็นประจำรวมถึงเมื่อวานนี้จาก Yahoo แต่เราควรจะรับรองสิ่งเหล่านี้ด้วยมูลค่าที่แท้จริง?
ความจริงก็คือฐานข้อมูลรหัสผ่านประนีประนอม เป็น ข้อกังวลไม่ว่า บริษัท จะพยายามหมุนมันอย่างไร แต่มีบางสิ่งที่คุณสามารถทำได้เพื่อป้องกันตัวเองไม่ว่าวิธีปฏิบัติด้านความปลอดภัยของ บริษัท จะแย่แค่ไหน.
รหัสผ่านควรเก็บไว้อย่างไร
นี่คือวิธีที่ บริษัท ควรเก็บรหัสผ่านในโลกอุดมคติ: คุณสร้างบัญชีและระบุรหัสผ่าน แทนที่จะเก็บรหัสผ่านเองบริการจะสร้าง "แฮช" จากรหัสผ่าน นี่คือลายนิ้วมือที่ไม่ซ้ำกันซึ่งไม่สามารถย้อนกลับได้ ตัวอย่างเช่นรหัสผ่าน“ รหัสผ่าน” อาจกลายเป็นสิ่งที่ดูเหมือน“ 4jfh75to4sud7gh93247g …” เมื่อคุณป้อนรหัสผ่านเพื่อเข้าสู่ระบบบริการจะสร้างแฮชจากมันและตรวจสอบว่าค่าแฮชตรงกับค่าที่เก็บไว้ในฐานข้อมูลหรือไม่ บริการไม่เคยบันทึกรหัสผ่านของคุณเองลงในดิสก์.
ในการกำหนดรหัสผ่านจริงของคุณผู้โจมตีที่มีสิทธิ์เข้าถึงฐานข้อมูลจะต้องคำนวณแฮชล่วงหน้าสำหรับรหัสผ่านทั่วไปจากนั้นตรวจสอบว่ามีอยู่ในฐานข้อมูลหรือไม่ ผู้โจมตีทำเช่นนี้กับรายการแฮชของตารางขนาดใหญ่ที่ตรงกับรหัสผ่าน hashes นั้นสามารถเปรียบเทียบกับฐานข้อมูล ตัวอย่างเช่นผู้โจมตีจะรู้จักแฮชสำหรับ“ รหัสผ่าน 1” จากนั้นดูว่าบัญชีใด ๆ ในฐานข้อมูลกำลังใช้แฮชนั้นหรือไม่ หากพวกเขาเป็นผู้โจมตีรู้รหัสผ่านของพวกเขาคือ“ password1”.
เพื่อป้องกันสิ่งนี้บริการควร "เกลือ" แฮชของพวกเขา แทนที่จะสร้างแฮชจากรหัสผ่านเองพวกมันจะเพิ่มสตริงแบบสุ่มไปที่ส่วนหน้าหรือส่วนท้ายของรหัสผ่านก่อนที่จะทำการแฮช กล่าวอีกนัยหนึ่งผู้ใช้จะต้องป้อนรหัสผ่าน“ รหัสผ่าน” และบริการจะเพิ่มรหัสผ่านและแฮชรหัสที่ดูเหมือน“ รหัสผ่าน 35s2dg” บัญชีผู้ใช้แต่ละบัญชีควรมีเกลือเฉพาะตัวของตัวเอง จะมีค่าแฮชที่แตกต่างกันสำหรับรหัสผ่านในฐานข้อมูล แม้ว่าบัญชีหลายบัญชีจะใช้รหัสผ่าน“ รหัสผ่าน 1” แต่บัญชีเหล่านั้นจะมีแฮชต่างกันเนื่องจากค่าเกลือต่างกัน สิ่งนี้จะกำจัดผู้โจมตีที่พยายามแฮชรหัสผ่านล่วงหน้า แทนที่จะสามารถสร้างแฮชที่ใช้กับบัญชีผู้ใช้ทุกบัญชีในฐานข้อมูลทั้งหมดในครั้งเดียวพวกเขาจะต้องสร้างแฮชที่ไม่ซ้ำกันสำหรับแต่ละบัญชีผู้ใช้และแต่ละบัญชี การคำนวณนี้จะใช้เวลาและหน่วยความจำมากขึ้น.
นี่คือเหตุผลที่บริการมักจะพูดว่าไม่ต้องกังวล บริการที่ใช้ขั้นตอนการรักษาความปลอดภัยที่เหมาะสมควรบอกว่าพวกเขาใช้แฮชรหัสผ่านที่ผ่านการชำระเงินแล้ว หากพวกเขาเพียงแค่บอกว่ารหัสผ่าน "แฮช" นั่นเป็นเรื่องที่น่าเป็นห่วงมากกว่า ตัวอย่างเช่น LinkedIn แฮรหัสผ่านของพวกเขา แต่พวกเขาไม่ได้เกลือพวกเขาดังนั้นมันจึงเป็นเรื่องใหญ่เมื่อ LinkedIn สูญเสียรหัสผ่านแฮช 6.5 ล้านในปี 2012.
แนวทางปฏิบัติเกี่ยวกับรหัสผ่านไม่ถูกต้อง
สิ่งนี้ไม่ใช่สิ่งที่ยากที่สุดในการติดตั้ง แต่เว็บไซต์จำนวนมากยังคงจัดการกับความยุ่งเหยิงได้หลายวิธี:
- การจัดเก็บรหัสผ่านในรูปแบบข้อความล้วน: แทนที่จะรำคาญกับการแฮชผู้กระทำความผิดที่เลวร้ายที่สุดบางคนอาจทิ้งรหัสผ่านในรูปแบบข้อความธรรมดาไปยังฐานข้อมูล หากฐานข้อมูลดังกล่าวถูกบุกรุกรหัสผ่านของคุณจะถูกเปิดเผยอย่างชัดเจน ไม่สำคัญหรอกว่าพวกเขาแข็งแกร่งแค่ไหน.
- การใส่รหัสผ่านโดยไม่ทำลายพวกเขา: บริการบางอย่างอาจแฮรหัสผ่านและให้มีการเลือกที่จะไม่ใช้เกลือ ฐานข้อมูลรหัสผ่านดังกล่าวจะมีความเสี่ยงต่อการค้นหาตาราง ผู้โจมตีสามารถสร้างแฮชสำหรับรหัสผ่านจำนวนมากแล้วตรวจสอบว่ามีอยู่ในฐานข้อมูลหรือไม่ - พวกเขาสามารถทำสิ่งนี้กับทุกบัญชีพร้อมกันหากไม่มีการใช้เกลือ.
- การนำเกลือกลับมาใช้ซ้ำ: บริการบางอย่างอาจใช้เกลือ แต่อาจใช้เกลือเดียวกันซ้ำสำหรับรหัสผ่านบัญชีผู้ใช้ทุกบัญชี นี่คือไม่มีจุดหมาย - หากใช้เกลือเดียวกันสำหรับผู้ใช้ทุกคนผู้ใช้สองคนที่มีรหัสผ่านเดียวกันจะมีแฮชเดียวกัน.
- ใช้เกลือสั้น ๆ: หากใช้เกลือเพียงไม่กี่หลักก็เป็นไปได้ที่จะสร้างตารางการค้นหาที่รวมทุกเกลือที่เป็นไปได้ ตัวอย่างเช่นหากใช้ตัวเลขหนึ่งตัวเป็นเกลือผู้โจมตีสามารถสร้างรายการของแฮชที่รวมเอาเกลือที่เป็นไปได้ทั้งหมดไว้ได้อย่างง่ายดาย.
บริษัท ต่างๆจะไม่บอกเรื่องทั้งหมดเสมอไปแม้ว่าพวกเขาจะบอกว่ารหัสผ่านถูกแฮช (หรือถูกแฮชและใส่เกลือ) พวกเขาอาจไม่ได้ใช้แนวปฏิบัติที่ดีที่สุด ทำผิดพลาดเสมอในด้านของความระมัดระวัง.
ข้อกังวลอื่น ๆ
มีความเป็นไปได้ว่าค่าความเค็มนั้นมีอยู่ในฐานข้อมูลรหัสผ่านด้วย นี่ไม่ใช่เรื่องเลวร้ายหากใช้ค่าเกลือที่ไม่ซ้ำกันสำหรับผู้ใช้แต่ละคนผู้โจมตีจะต้องใช้พลังงาน CPU จำนวนมหาศาลซึ่งทำลายรหัสผ่านทั้งหมดเหล่านั้น.
ในทางปฏิบัติผู้คนจำนวนมากใช้รหัสผ่านที่ชัดเจนซึ่งอาจเป็นเรื่องง่ายในการกำหนดรหัสผ่านของบัญชีผู้ใช้จำนวนมาก ตัวอย่างเช่นหากผู้โจมตีรู้แฮชของคุณและพวกเขารู้ว่าเกลือของคุณพวกเขาสามารถตรวจสอบได้อย่างง่ายดายเพื่อดูว่าคุณกำลังใช้รหัสผ่านที่พบบ่อยที่สุดบางส่วน.
หากผู้โจมตีออกมาให้คุณและต้องการถอดรหัสรหัสผ่านของคุณพวกเขาสามารถทำได้โดยใช้กำลังดุร้ายตราบใดที่พวกเขารู้คุณค่าของเกลือที่พวกเขาอาจทำ ด้วยการเข้าถึงฐานข้อมูลรหัสผ่านในท้องถิ่นและออฟไลน์ผู้โจมตีสามารถใช้การโจมตีแบบเดรัจฉานที่ต้องการได้.
ข้อมูลส่วนบุคคลอื่น ๆ อาจรั่วเมื่อฐานข้อมูลรหัสผ่านถูกขโมย: ชื่อผู้ใช้ที่อยู่อีเมลและอื่น ๆ ในกรณีของการรั่วไหลของ Yahoo คำถามและคำตอบเพื่อความปลอดภัยก็รั่วไหลออกไปซึ่งในขณะที่เราทุกคนรู้กันดีว่าเป็นการขโมยบัญชีของใครบางคนได้ง่ายขึ้น.
ช่วยเหลือฉันควรทำอย่างไร?
สิ่งที่บริการบอกว่าเมื่อฐานข้อมูลรหัสผ่านถูกขโมยจะเป็นการดีที่สุดที่จะสมมติว่าบริการทุกอย่างไม่สามารถใช้งานได้และดำเนินการตามนั้น.
ก่อนอื่นอย่านำรหัสผ่านมาใช้ซ้ำในเว็บไซต์หลายแห่ง ใช้เครื่องมือจัดการรหัสผ่านที่สร้างรหัสผ่านที่ไม่ซ้ำสำหรับแต่ละเว็บไซต์ หากผู้โจมตีจัดการพบว่ารหัสผ่านสำหรับบริการของคุณคือ“ 43 ^ tSd% 7uho2 # 3” และคุณใช้รหัสผ่านนั้นบนเว็บไซต์หนึ่งเท่านั้นพวกเขาไม่ได้เรียนรู้อะไรที่มีประโยชน์ หากคุณใช้รหัสผ่านเดียวกันทุกที่พวกเขาสามารถเข้าถึงบัญชีอื่นของคุณ นี่คือจำนวนบัญชีของผู้ที่ถูก“ แฮ็ก”
หากบริการไม่ปลอดภัยโปรดเปลี่ยนรหัสผ่านที่คุณใช้ที่นั่น คุณควรเปลี่ยนรหัสผ่านในเว็บไซต์อื่นหากคุณนำรหัสนั้นกลับมาใช้ใหม่ - แต่คุณไม่ควรทำเช่นนั้นในตอนแรก.
คุณควรพิจารณาใช้การรับรองความถูกต้องด้วยสองปัจจัยซึ่งจะปกป้องคุณแม้ว่าผู้โจมตีจะเรียนรู้รหัสผ่านของคุณ.
สิ่งที่สำคัญที่สุดคือการไม่ใช้รหัสผ่านซ้ำ ฐานข้อมูลรหัสผ่านที่ถูกบุกรุกไม่สามารถทำร้ายคุณได้หากคุณใช้รหัสผ่านที่ไม่ซ้ำกันทุกที่ยกเว้นว่าพวกเขาเก็บสิ่งอื่นที่สำคัญในฐานข้อมูลเช่นหมายเลขบัตรเครดิตของคุณ.
เครดิตภาพ: Marc Falardeau บน Flickr, Wikimedia Commons
