ฉันเพิ่งมีเวลาคิดอีกครั้งว่าฟีเจอร์การรีเซ็ตรหัสผ่านที่ปลอดภัยควรทำงานอย่างไร อันดับแรกเมื่อฉันสร้างฟังก์ชันนี้เข้าไป แล้วพอเขาช่วยทำสิ่งที่คล้ายกับบุคคลอื่น ในกรณีที่สอง ฉันต้องการให้ลิงก์ไปยังทรัพยากร Canonical พร้อมรายละเอียดทั้งหมดเกี่ยวกับการใช้งานฟังก์ชันรีเซ็ตอย่างปลอดภัย อย่างไรก็ตาม ปัญหาคือไม่มีทรัพยากรดังกล่าว อย่างน้อยก็ไม่มีทรัพยากรที่อธิบายทุกสิ่งที่ดูเหมือนสำคัญสำหรับฉัน ฉันจึงตัดสินใจเขียนมันเอง
คุณเห็นไหมว่าโลกแห่งการลืมรหัสผ่านนั้นค่อนข้างลึกลับจริงๆ มีมุมมองที่แตกต่างกันและเป็นที่ยอมรับได้มากมายและมีมุมมองที่ค่อนข้างอันตรายอีกมากมาย เป็นไปได้ว่าคุณจะได้พบกับแต่ละอันหลายครั้งในฐานะผู้ใช้ปลายทาง ดังนั้นฉันจะลองใช้ตัวอย่างเหล่านี้เพื่อแสดงให้เห็นว่าใครทำถูกต้อง ใครทำไม่ได้ และสิ่งที่คุณต้องมุ่งเน้นเพื่อให้ฟีเจอร์นี้ถูกต้องในแอปของคุณ
การจัดเก็บรหัสผ่าน: การแฮช การเข้ารหัส และข้อความธรรมดา (โอ้!)
เราไม่สามารถพูดคุยได้ว่าจะทำอย่างไรกับรหัสผ่านที่ลืม ก่อนที่จะหารือเกี่ยวกับวิธีจัดเก็บรหัสผ่าน รหัสผ่านจะถูกจัดเก็บไว้ในฐานข้อมูลโดยเป็นหนึ่งในสามประเภทหลัก:
- ข้อความธรรมดา. มีคอลัมน์พร้อมรหัสผ่านซึ่งจัดเก็บไว้ในข้อความธรรมดา
- เข้ารหัส โดยปกติแล้วจะใช้การเข้ารหัสแบบสมมาตร (ใช้คีย์เดียวสำหรับทั้งการเข้ารหัสและการถอดรหัส) และรหัสผ่านที่เข้ารหัสจะถูกจัดเก็บไว้ในคอลัมน์เดียวกันด้วย
- แฮช กระบวนการทางเดียว (รหัสผ่านสามารถถูกแฮชได้ แต่ไม่สามารถถูกแฮชได้) รหัสผ่าน, หวังว่าตามด้วยเกลือ และแต่ละอันจะอยู่ในคอลัมน์ของตัวเอง
มาตรงไปที่คำถามที่ง่ายที่สุด: อย่าเก็บรหัสผ่านเป็นข้อความธรรมดา! ไม่เคย. ช่องโหว่เดียว สำเนาสำรองหนึ่งชุดที่ทำโดยประมาทหรือข้อผิดพลาดง่ายๆ อีกหลายสิบข้อ - และนั่นคือการจบเกม รหัสผ่านทั้งหมดของคุณ - นั่นคือขอโทษ รหัสผ่านสำหรับลูกค้าของคุณทั้งหมด จะกลายเป็นสมบัติสาธารณะ แน่นอนว่านี่จะหมายถึงความเป็นไปได้อย่างมาก จากบัญชีทั้งหมดในระบบอื่น และมันจะเป็นความผิดของคุณ
การเข้ารหัสดีกว่า แต่ก็มีจุดอ่อน ปัญหาของการเข้ารหัสอยู่ในการถอดรหัส เราสามารถนำรหัสที่ดูประหลาดๆ พวกนี้ไปแปลงกลับเป็นข้อความธรรมดา และเมื่อสิ่งนั้นเกิดขึ้น เราก็กลับไปสู่สถานการณ์เดิมด้วยรหัสผ่านที่อ่านได้ สิ่งนี้เกิดขึ้นได้อย่างไร? รหัสที่ถอดรหัสรหัสผ่านมีข้อบกพร่องเล็กน้อยทำให้เปิดเผยต่อสาธารณะ - นี่เป็นวิธีหนึ่ง การเข้าถึงเครื่องที่แฮกเกอร์เก็บข้อมูลที่เข้ารหัสไว้ - นี่เป็นวิธีที่สอง อีกวิธีหนึ่งคือการขโมยข้อมูลสำรองของฐานข้อมูล และบางคนก็ได้รับคีย์เข้ารหัสซึ่งมักจะถูกเก็บไว้อย่างไม่ปลอดภัยมาก
และนั่นนำเราไปสู่การคร่ำครวญ แนวคิดเบื้องหลังการแฮชคือทำด้วยวิธีเดียว วิธีเดียวที่จะเปรียบเทียบรหัสผ่านที่ผู้ใช้ป้อนกับเวอร์ชันที่แฮชคือการแฮชรหัสผ่านที่ป้อนและเปรียบเทียบ เพื่อป้องกันการโจมตีโดยใช้เครื่องมือเช่นตารางสายรุ้ง เราใช้เกลือเพื่อเพิ่มการสุ่มให้กับกระบวนการ (สำหรับภาพรวม โปรดอ่าน my เกี่ยวกับการจัดเก็บการเข้ารหัส) ท้ายที่สุด หากนำไปใช้อย่างถูกต้อง เราสามารถสรุปได้อย่างปลอดภัยว่ารหัสผ่านที่แฮชจะไม่กลายเป็นข้อความธรรมดาอีกต่อไป (ฉันจะพูดถึงประโยชน์ของอัลกอริธึมการแฮชต่างๆ ในโพสต์อื่น)
ข้อโต้แย้งอย่างรวดเร็วเกี่ยวกับการแฮชและการเข้ารหัส: เหตุผลเดียวที่คุณจะต้องเข้ารหัสแทนที่จะแฮชรหัสผ่านคือเมื่อคุณต้องการเห็นรหัสผ่านในรูปแบบข้อความธรรมดาแทนที่จะเป็น คุณไม่ควรต้องการสิ่งนี้อย่างน้อยก็ในสถานการณ์ของเว็บไซต์มาตรฐาน หากคุณต้องการสิ่งนี้ เป็นไปได้มากว่าคุณกำลังทำอะไรผิด!
คำเตือน!
ต่อไปอีกเล็กน้อยในข้อความของโพสต์นั้นเป็นส่วนหนึ่งของภาพหน้าจอของเว็บไซต์ลามกอนาจาร AlotPorn มันถูกครอบตัดไว้อย่างเรียบร้อย ดังนั้นจึงไม่มีอะไรที่ไม่สามารถมองเห็นได้บนชายหาด แต่หากยังคงเกิดปัญหาอยู่ ก็อย่าเลื่อนหน้าลง
รีเซ็ตรหัสผ่านของคุณเสมอ ไม่เคย อย่าเตือนเขา
คุณเคยถูกขอให้สร้างฟังก์ชั่นหรือไม่ เตือนความจำ รหัสผ่าน? ย้อนกลับไปและคิดย้อนกลับเกี่ยวกับคำขอนี้: เหตุใดจึงจำเป็นต้องมี "คำเตือน" นี้ เนื่องจากผู้ใช้ลืมรหัสผ่าน จริงๆแล้วเราต้องการทำอะไร? ช่วยเขาเข้าสู่ระบบอีกครั้ง
ฉันเข้าใจว่าคำว่า "เตือนความจำ" ถูกใช้ (บ่อยครั้ง) เรียกขาน แต่สิ่งที่เราพยายามทำจริงๆ คือ ช่วยให้ผู้ใช้ออนไลน์ได้อย่างปลอดภัยอีกครั้ง. เนื่องจากเราต้องการความปลอดภัย มีเหตุผลสองประการที่ทำให้การแจ้งเตือน (เช่น การส่งรหัสผ่านให้กับผู้ใช้) จึงไม่เหมาะสม:
- อีเมลเป็นช่องทางที่ไม่ปลอดภัย เช่นเดียวกับที่เราจะไม่ส่งสิ่งที่ละเอียดอ่อนผ่าน HTTP (เราใช้ HTTPS) เราไม่ควรส่งสิ่งที่ละเอียดอ่อนทางอีเมลเนื่องจากเลเยอร์การขนส่งไม่ปลอดภัย ในความเป็นจริง สิ่งนี้แย่กว่าการส่งข้อมูลผ่านโปรโตคอลการขนส่งที่ไม่ปลอดภัย เนื่องจากเมลมักถูกจัดเก็บไว้ในอุปกรณ์จัดเก็บข้อมูล ผู้ดูแลระบบเข้าถึงได้ ส่งต่อและแจกจ่าย มัลแวร์เข้าถึงได้ และอื่นๆ อีเมลที่ไม่ได้เข้ารหัสเป็นช่องทางที่ไม่ปลอดภัยอย่างยิ่ง
- คุณไม่ควรมีการเข้าถึงรหัสผ่านอยู่แล้ว อ่านหัวข้อที่แล้วเกี่ยวกับการจัดเก็บอีกครั้ง คุณควรมีแฮชของรหัสผ่าน (โดยใส่เกลือที่เข้มข้นพอสมควร) ซึ่งหมายความว่าคุณไม่ควรดึงรหัสผ่านและส่งทางไปรษณีย์ไม่ว่าด้วยวิธีใดก็ตาม
ผมขอแสดงปัญหาด้วยตัวอย่าง : นี่คือหน้าเข้าสู่ระบบทั่วไป:
แน่นอนว่าปัญหาแรกคือหน้าเข้าสู่ระบบไม่โหลดผ่าน HTTPS แต่ไซต์ยังเสนอให้ส่งรหัสผ่านด้วย ("ส่งรหัสผ่าน") บางทีนี่อาจเป็นตัวอย่างหนึ่งของการใช้คำที่กล่าวถึงข้างต้นในเชิงภาษา ดังนั้นเรามาดูกันดีกว่าว่าจะเกิดอะไรขึ้น:
น่าเสียดาย มันไม่ได้ดูดีขึ้นมากนัก และอีเมลยืนยันว่ามีปัญหา:
ข้อมูลนี้บอกเราเกี่ยวกับประเด็นสำคัญสองประการของ usoutdoor.com:
- เว็บไซต์ไม่มีรหัสผ่านแฮช อย่างดีที่สุด ข้อมูลเหล่านี้จะถูกเข้ารหัส แต่มีแนวโน้มว่าข้อมูลเหล่านั้นจะถูกจัดเก็บไว้ในข้อความธรรมดา เราไม่เห็นหลักฐานที่ตรงกันข้าม
- ไซต์ส่งรหัสผ่านระยะยาว (เราสามารถกลับไปใช้ซ้ำแล้วซ้ำอีก) ผ่านช่องทางที่ไม่ปลอดภัย
เราต้องตรวจสอบว่ากระบวนการรีเซ็ตทำงานในลักษณะที่ปลอดภัยหรือไม่ ขั้นตอนแรกที่ต้องทำคือตรวจสอบให้แน่ใจว่าผู้ขอมีสิทธิ์ทำการรีเซ็ต กล่าวอีกนัยหนึ่ง ก่อนหน้านั้นเราจำเป็นต้องมีการตรวจสอบตัวตน มาดูว่าจะเกิดอะไรขึ้นเมื่อมีการยืนยันตัวตนโดยไม่ได้ตรวจสอบก่อนว่าผู้ขอเป็นเจ้าของบัญชีจริงๆ
การแสดงรายการชื่อผู้ใช้และผลกระทบต่อการไม่เปิดเผยตัวตน
ปัญหานี้แสดงให้เห็นได้ดีที่สุดด้วยภาพ ปัญหา:
ดู? โปรดใส่ใจกับข้อความ "ไม่มีผู้ใช้ที่ลงทะเบียนด้วยที่อยู่อีเมลนี้" ปัญหาเกิดขึ้นอย่างเห็นได้ชัดหากไซต์ที่คล้ายกันยืนยัน ห้องว่าง ผู้ใช้ที่ลงทะเบียนด้วยที่อยู่อีเมลดังกล่าว Bingo - คุณเพิ่งค้นพบเครื่องรางโป๊ของสามี/เจ้านาย/เพื่อนบ้านของคุณ!
แน่นอนว่าสื่อลามกเป็นตัวอย่างที่เป็นที่ยอมรับของความสำคัญของความเป็นส่วนตัว แต่อันตรายจากการจับคู่กับเว็บไซต์ใดเว็บไซต์หนึ่งนั้นมีมากกว่าสถานการณ์ที่น่าอับอายที่อธิบายไว้ข้างต้นมาก อันตรายประการหนึ่งคือวิศวกรรมสังคม หากผู้โจมตีสามารถจับคู่บุคคลกับบริการได้ เขาจะมีข้อมูลที่สามารถเริ่มใช้งานได้ ตัวอย่างเช่น เขาอาจติดต่อบุคคลที่สวมรอยเป็นตัวแทนของเว็บไซต์และขอข้อมูลเพิ่มเติมเพื่อพยายามดำเนินการ .
การปฏิบัติดังกล่าวยังก่อให้เกิดอันตรายจาก "การแจงนับชื่อผู้ใช้" ซึ่งสามารถตรวจสอบการมีอยู่ของชื่อผู้ใช้หรือที่อยู่อีเมลทั้งหมดบนเว็บไซต์ได้โดยการสืบค้นเป็นกลุ่มง่ายๆ และตรวจสอบการตอบกลับ คุณมีรายชื่อที่อยู่อีเมลของพนักงานทั้งหมดและมีเวลาเขียนสคริปต์สักสองสามนาทีหรือไม่? แล้วคุณจะเห็นว่าปัญหาคืออะไร!
ทางเลือกคืออะไร? ในความเป็นจริงมันค่อนข้างง่ายและนำไปใช้ได้อย่างน่าทึ่ง :
ที่นี่ Entropay จะไม่เปิดเผยสิ่งใดเกี่ยวกับการมีอยู่ของที่อยู่อีเมลในระบบของตนเลย ถึงบุคคลที่ไม่ได้เป็นเจ้าของที่อยู่นี้. ถ้าคุณ เป็นเจ้าของ ที่อยู่และไม่มีอยู่ในระบบ คุณจะได้รับอีเมล์ดังนี้:
แน่นอนว่ามีสถานการณ์ที่ใครบางคนยอมรับได้ คิดว่าที่ลงทะเบียนไว้บนเว็บไซต์ แต่นี่ไม่ใช่กรณี หรือทำจากที่อยู่อีเมลอื่น ตัวอย่างข้างต้นสามารถจัดการทั้งสองสถานการณ์ได้สำเร็จ แน่นอนว่าหากที่อยู่ตรงกัน คุณจะได้รับอีเมลที่ทำให้การรีเซ็ตรหัสผ่านของคุณเป็นเรื่องง่าย
ความละเอียดอ่อนของโซลูชันที่เลือกโดย Entropay คือการยืนยันตัวตนดำเนินการโดย อีเมล ก่อนที่จะมีการตรวจสอบออนไลน์ บางไซต์ขอให้ผู้ใช้ตอบคำถามเพื่อความปลอดภัย (เพิ่มเติมด้านล่างนี้) ไปยัง การรีเซ็ตสามารถเริ่มต้นได้อย่างไร อย่างไรก็ตาม ปัญหาคือคุณต้องตอบคำถามในขณะที่ระบุรูปแบบการระบุตัวตน (อีเมลหรือชื่อผู้ใช้) ซึ่งทำให้แทบเป็นไปไม่ได้เลยที่จะตอบโดยสัญชาตญาณโดยไม่เปิดเผยการมีอยู่ของบัญชีผู้ใช้ที่ไม่ระบุชื่อ
ด้วยแนวทางนี้นั่นเอง เล็ก การใช้งานลดลงเนื่องจากหากคุณพยายามรีเซ็ตบัญชีที่ไม่มีอยู่จริง จะไม่มีการตอบรับทันที แน่นอนว่านั่นคือจุดรวมของการส่งอีเมล แต่จากมุมมองของผู้ใช้จริง หากพวกเขาป้อนที่อยู่ผิด พวกเขาจะรู้เพียงครั้งแรกเมื่อได้รับอีเมลเท่านั้น นี่อาจทำให้เกิดความตึงเครียดในส่วนของเขา แต่นี่เป็นราคาเล็กน้อยที่ต้องจ่ายสำหรับกระบวนการที่หายากเช่นนี้
หมายเหตุอีกประการหนึ่ง ซึ่งอยู่นอกหัวข้อเล็กน้อย: ฟังก์ชั่นช่วยเหลือในการเข้าสู่ระบบที่เปิดเผยว่าชื่อผู้ใช้หรือที่อยู่อีเมลถูกต้องนั้นมีปัญหาเดียวกันหรือไม่ ตอบกลับผู้ใช้ด้วยข้อความ “ชื่อผู้ใช้และรหัสผ่านของคุณไม่ถูกต้อง” เสมอ แทนที่จะยืนยันการมีอยู่ของข้อมูลประจำตัวอย่างชัดเจน (เช่น “ชื่อผู้ใช้ถูกต้อง แต่รหัสผ่านไม่ถูกต้อง”)
การส่งรีเซ็ตรหัสผ่านเทียบกับการส่ง URL รีเซ็ต
แนวคิดถัดไปที่เราจำเป็นต้องพูดคุยนั้นเกี่ยวข้องกับวิธีการรีเซ็ตรหัสผ่าน มีสองโซลูชั่นยอดนิยม:
- การสร้างรหัสผ่านใหม่บนเซิร์ฟเวอร์และส่งทางอีเมล
- ส่งอีเมลพร้อม URL เฉพาะเพื่อให้กระบวนการรีเซ็ตง่ายขึ้น
แม้จะมี จุดแรกไม่ควรใช้ ปัญหาของเขาคือมันหมายถึงการมี รหัสผ่านที่เก็บไว้ซึ่งคุณสามารถกลับมาใช้ใหม่ได้ตลอดเวลา มันถูกส่งผ่านช่องทางที่ไม่ปลอดภัยและยังคงอยู่ในกล่องจดหมายของคุณ มีโอกาสที่กล่องขาเข้าจะซิงค์กับอุปกรณ์เคลื่อนที่และโปรแกรมรับส่งเมล อีกทั้งยังอาจจัดเก็บออนไลน์ในบริการอีเมลทางเว็บเป็นเวลานานอีกด้วย ประเด็นก็คือว่า กล่องจดหมายไม่ถือเป็นวิธีการที่เชื่อถือได้สำหรับการจัดเก็บระยะยาว.
แต่นอกเหนือจากนี้ ย่อหน้าแรกยังมีปัญหาร้ายแรงอีกประการหนึ่ง นั่นก็คือ ง่ายขึ้นมากที่สุดเท่าที่จะเป็นไปได้ การบล็อกบัญชีด้วยเจตนาร้าย หากฉันทราบที่อยู่อีเมลของบุคคลที่เป็นเจ้าของบัญชีบนเว็บไซต์ ฉันสามารถบล็อกเขาได้ตลอดเวลาโดยเพียงแค่รีเซ็ตรหัสผ่านของเขา มันเป็นการโจมตีแบบปฏิเสธการบริการบนจานเงิน! นั่นคือเหตุผลที่การรีเซ็ตควรทำหลังจากตรวจสอบสิทธิ์กับผู้ขอสำเร็จแล้วเท่านั้น
เมื่อเราพูดถึง URL ที่รีเซ็ต เราหมายถึงที่อยู่เว็บไซต์ ซึ่งก็คือ เฉพาะสำหรับกรณีเฉพาะของกระบวนการรีเซ็ตนี้. แน่นอนว่าต้องเป็นแบบสุ่ม ต้องไม่เดาง่าย และต้องไม่มีการอ้างอิงภายนอกไปยังบัญชีที่ทำให้รีเซ็ตได้ง่าย ตัวอย่างเช่น URL ที่รีเซ็ตไม่ควรเป็นเพียงเส้นทางเช่น "Reset/?username=JohnSmith"
เราต้องการสร้างโทเค็นเฉพาะที่สามารถส่งทางไปรษณีย์เป็น URL รีเซ็ต จากนั้นจับคู่กับบันทึกเซิร์ฟเวอร์ของบัญชีผู้ใช้ จึงเป็นการยืนยันว่าเจ้าของบัญชีคือบุคคลเดียวกันกับที่พยายามรีเซ็ตรหัสผ่านจริงๆ ตัวอย่างเช่น โทเค็นอาจมีลักษณะดังนี้ "3ce7854015cd38c862cb9e14a1ae552b" และจัดเก็บไว้ในตารางพร้อมกับ ID ผู้ใช้ที่รีเซ็ตและเวลาในการสร้างโทเค็น (เพิ่มเติมเกี่ยวกับเรื่องนี้ในอีกสักครู่) เมื่อส่งอีเมลไป จะมี URL เช่น "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b" และเมื่อผู้ใช้โหลดหน้าเว็บจะถามถึงการมีอยู่ของโทเค็น จากนั้นยืนยันข้อมูลของผู้ใช้และอนุญาตให้เปลี่ยนรหัสผ่านได้
แน่นอนว่า เนื่องจากกระบวนการข้างต้น (หวังว่า) จะอนุญาตให้ผู้ใช้สร้างรหัสผ่านใหม่ได้ เราจึงต้องตรวจสอบให้แน่ใจว่า URL นั้นโหลดผ่าน HTTPS เลขที่, URL นี้พร้อมโทเค็นต้องใช้การรักษาความปลอดภัยเลเยอร์การขนส่ง เพื่อไม่ให้โจมตีแบบฟอร์มการป้อนรหัสผ่านใหม่ และรหัสผ่านที่สร้างโดยผู้ใช้จะถูกส่งผ่านการเชื่อมต่อที่ปลอดภัย
นอกจากนี้ สำหรับ URL ที่รีเซ็ต คุณจะต้องเพิ่มขีดจำกัดเวลาของโทเค็นเพื่อให้กระบวนการรีเซ็ตเสร็จสิ้นภายในระยะเวลาที่กำหนด เช่น ภายในหนึ่งชั่วโมง เพื่อให้แน่ใจว่ากรอบเวลารีเซ็ตจะถูกเก็บไว้ให้เหลือน้อยที่สุด เพื่อให้ผู้รับ URL ที่รีเซ็ตสามารถดำเนินการภายในหน้าต่างเล็กๆ นั้นเท่านั้น แน่นอนว่าผู้โจมตีสามารถเริ่มกระบวนการรีเซ็ตได้อีกครั้ง แต่จะต้องได้รับ URL การรีเซ็ตที่ไม่ซ้ำกันอีกรายการหนึ่ง
สุดท้ายนี้ เราต้องแน่ใจว่ากระบวนการนี้เป็นแบบใช้แล้วทิ้ง เมื่อกระบวนการรีเซ็ตเสร็จสมบูรณ์ จะต้องลบโทเค็นออกเพื่อให้ URL ที่รีเซ็ตนั้นใช้ไม่ได้อีกต่อไป จำเป็นต้องมีจุดก่อนหน้าเพื่อให้ผู้โจมตีมีหน้าต่างเล็กมากในระหว่างที่เขาสามารถจัดการ URL ที่รีเซ็ตได้ นอกจากนี้ แน่นอนว่าหลังจากการรีเซ็ตเสร็จสมบูรณ์แล้ว โทเค็นก็ไม่จำเป็นต้องใช้อีกต่อไป
ขั้นตอนเหล่านี้บางขั้นตอนอาจดูเหมือนซ้ำซ้อน แต่ไม่รบกวนการใช้งานและ ในความเป็นจริง ปรับปรุงความปลอดภัยแม้ในสถานการณ์ที่เราหวังว่าจะเกิดขึ้นได้ยาก ในกรณี 99% ผู้ใช้จะเปิดใช้งานการรีเซ็ตภายในระยะเวลาอันสั้นมากและจะไม่รีเซ็ตรหัสผ่านอีกในอนาคตอันใกล้นี้
บทบาทของแคปช่า
โอ้ CAPTCHA คุณลักษณะด้านความปลอดภัยที่เราทุกคนชอบเกลียด! ในความเป็นจริง CAPTCHA ไม่ใช่เครื่องมือป้องกันมากนักเนื่องจากเป็นเครื่องมือระบุตัวตน ไม่ว่าคุณจะเป็นบุคคลหรือหุ่นยนต์ (หรือสคริปต์อัตโนมัติ) จุดประสงค์คือเพื่อหลีกเลี่ยงการส่งแบบฟอร์มอัตโนมัติ ซึ่งแน่นอนว่า สามารถ ถูกใช้เป็นความพยายามที่จะทำลายการป้องกัน ในบริบทของการรีเซ็ตรหัสผ่าน CAPTCHA หมายความว่าฟังก์ชันการรีเซ็ตไม่สามารถบังคับอย่างดุร้ายกับสแปมผู้ใช้หรือพยายามตรวจสอบการมีอยู่ของบัญชี (ซึ่งแน่นอนว่าจะเป็นไปไม่ได้หากคุณทำตามคำแนะนำในส่วนที่ การยืนยันตัวตน)
แน่นอนว่า CAPTCHA เองก็ไม่ได้สมบูรณ์แบบ มีหลายแบบอย่างสำหรับซอฟต์แวร์ "แฮ็ก" และบรรลุอัตราความสำเร็จที่เพียงพอ (60-70%) นอกจากนี้ยังมีวิธีแก้ไขที่แสดงในโพสต์ของฉันเกี่ยวกับ ซึ่งคุณสามารถจ่ายเงินให้ผู้คนเพียงเศษสตางค์เพื่อแก้ CAPTCHA แต่ละรายการและบรรลุอัตราความสำเร็จ 94% นั่นคือมันมีความเสี่ยง แต่ก็เพิ่มอุปสรรคในการเข้า (เล็กน้อย)
มาดูตัวอย่าง PayPal กัน:
ในกรณีนี้ กระบวนการรีเซ็ตไม่สามารถเริ่มต้นได้ก่อนที่ CAPTCHA จะได้รับการแก้ไข ดังนั้น ตามหลักวิชา ไม่สามารถทำให้กระบวนการเป็นอัตโนมัติได้ ในทางทฤษฎี
อย่างไรก็ตาม สำหรับเว็บแอปพลิเคชันส่วนใหญ่ สิ่งนี้จะเกินความจำเป็นและ ถูกต้องที่สุด แสดงถึงการใช้งานที่ลดลง - ผู้คนแค่ไม่ชอบ CAPTCHA! นอกจากนี้ CAPTCHA ยังเป็นสิ่งที่คุณสามารถกลับมาใช้ใหม่ได้อย่างง่ายดายหากจำเป็น หากบริการเริ่มถูกโจมตี (นี่คือจุดที่การบันทึกมีประโยชน์ แต่จะมีประโยชน์มากกว่านี้ในภายหลัง) การเพิ่ม CAPTCHA ไม่ใช่เรื่องง่ายอีกต่อไป
คำถามและคำตอบลับ
ด้วยวิธีการทั้งหมดที่เราพิจารณา เราสามารถรีเซ็ตรหัสผ่านได้ เพียงแค่เข้าถึงบัญชีอีเมลเท่านั้น ฉันพูดว่า "แค่" แต่แน่นอนว่าเป็นการเข้าถึงบัญชีอีเมลของผู้อื่นอย่างผิดกฎหมาย ควร เป็นกระบวนการที่ซับซ้อน อย่างไรก็ตาม .
อันที่จริงลิงก์ด้านบนเกี่ยวกับการแฮ็ก Yahoo! ของ Sarah Palin มีจุดประสงค์สองประการ ประการแรก แสดงให้เห็นว่าการแฮ็กบัญชีอีเมล (บางส่วน) นั้นง่ายเพียงใด และประการที่สอง แสดงให้เห็นว่าคำถามเพื่อความปลอดภัยที่ไม่ดีสามารถนำไปใช้โดยมีเจตนาร้ายได้อย่างไร แต่เราจะกลับมาที่เรื่องนี้ในภายหลัง
ปัญหาในการรีเซ็ตรหัสผ่านที่ขึ้นอยู่กับอีเมล XNUMX% คือความสมบูรณ์ของบัญชีของไซต์ที่คุณพยายามรีเซ็ตกลายเป็น XNUMX% ขึ้นอยู่กับความสมบูรณ์ของบัญชีอีเมล ใครก็ตามที่สามารถเข้าถึงอีเมลของคุณได้ สามารถเข้าถึงบัญชีใด ๆ ที่สามารถรีเซ็ตได้โดยเพียงแค่รับอีเมล. สำหรับบัญชีดังกล่าว อีเมลคือ "กุญแจสู่ทุกประตู" ของชีวิตออนไลน์ของคุณ
วิธีหนึ่งในการลดความเสี่ยงนี้คือการใช้รูปแบบคำถามและคำตอบเพื่อความปลอดภัย ไม่ต้องสงสัยเลยว่าคุณเคยเห็นพวกเขาแล้ว: เลือกคำถามที่มีเพียงคุณเท่านั้น ต้อง รู้คำตอบ หลังจากนั้นเมื่อคุณรีเซ็ตรหัสผ่าน ระบบจะถามคุณ สิ่งนี้เพิ่มความมั่นใจว่าบุคคลที่พยายามรีเซ็ตคือเจ้าของบัญชีจริงๆ
กลับมาที่ Sarah Palin ข้อผิดพลาดคือคำตอบสำหรับคำถาม/คำถามลับของเธอนั้นหาได้ง่าย โดยเฉพาะอย่างยิ่งเมื่อคุณเป็นบุคคลสาธารณะที่มีชื่อเสียง ข้อมูลเกี่ยวกับนามสกุลเดิมของแม่ ประวัติโรงเรียน หรือสถานที่ซึ่งใครบางคนอาจเคยอาศัยอยู่ในอดีตไม่ได้เป็นความลับทั้งหมด ในความเป็นจริงส่วนใหญ่สามารถพบได้โดยใครก็ตาม นี่คือสิ่งที่เกิดขึ้นกับซาราห์
แฮ็กเกอร์ David Kernell เข้าถึงบัญชีของ Palin ได้โดยการค้นหารายละเอียดความเป็นมาของเธอ เช่น โรงเรียนมัธยมปลายและวันเกิดของเธอ จากนั้นจึงใช้ฟีเจอร์การกู้คืนรหัสผ่านบัญชีที่สูญหายของ Yahoo!
ก่อนอื่น นี่เป็นข้อผิดพลาดในการออกแบบของ Yahoo! — โดยการระบุคำถามง่ายๆ ดังกล่าว บริษัทได้ทำลายคุณค่าของคำถามเพื่อความปลอดภัยเป็นหลัก และรวมถึงการปกป้องระบบด้วย แน่นอนว่าการรีเซ็ตรหัสผ่านสำหรับบัญชีอีเมลนั้นยากกว่าเสมอ เนื่องจากคุณไม่สามารถพิสูจน์ความเป็นเจ้าของด้วยการส่งอีเมลถึงเจ้าของ (โดยไม่ต้องมีที่อยู่ที่สอง) แต่โชคดีที่ปัจจุบันนี้มีประโยชน์ไม่มากในการสร้างระบบดังกล่าว
กลับมาที่คำถามลับ - มีตัวเลือกให้ผู้ใช้ตั้งคำถามเองได้ ปัญหาคือผลลัพธ์จะเป็นคำถามที่ชัดเจนมาก:
ท้องฟ้าสีอะไร?
คำถามที่ทำให้ผู้คนรู้สึกไม่สบายใจเมื่อคำถามเพื่อความปลอดภัยใช้คำถามลับในการระบุตัวตน คน (เช่น ในศูนย์บริการทางโทรศัพท์):
ฉันนอนกับใครในวันคริสต์มาส?
หรือคำถามโง่ตรงไปตรงมา:
คุณสะกดคำว่า "รหัสผ่าน" อย่างไร?
เมื่อพูดถึงคำถามเพื่อความปลอดภัย ผู้ใช้จะต้องได้รับการช่วยเหลือจากตัวเอง! กล่าวอีกนัยหนึ่ง คำถามเพื่อความปลอดภัยควรถูกกำหนดโดยไซต์เอง หรือดีกว่านั้นคือถาม ชุด คำถามเพื่อความปลอดภัยที่ผู้ใช้สามารถเลือกได้ และอย่าเพิ่งเลือก หนึ่ง; ตามหลักการแล้วผู้ใช้ควรเลือกคำถามเพื่อความปลอดภัยตั้งแต่ XNUMX ข้อขึ้นไป ในขณะที่ลงทะเบียนบัญชีซึ่งจะใช้เป็นช่องทางการระบุตัวตนที่สอง การมีคำถามหลายข้อจะช่วยเพิ่มความมั่นใจในกระบวนการตรวจสอบ และยังให้ความสามารถในการเพิ่มการสุ่ม (ไม่แสดงคำถามเดียวกันเสมอไป) พร้อมทั้งให้ความซ้ำซ้อนเล็กน้อยในกรณีที่ผู้ใช้จริงลืมรหัสผ่าน
คำถามเพื่อความปลอดภัยที่ดีคืออะไร? สิ่งนี้ได้รับอิทธิพลจากปัจจัยหลายประการ:
- มันควรจะเป็น รวบรัด คำถามควรมีความชัดเจนและไม่คลุมเครือ
- คำตอบจะต้องเป็น เฉพาะเจาะจง — เราไม่ต้องการคำถามที่คนคนหนึ่งสามารถตอบได้หลายวิธี
- คำตอบที่เป็นไปได้ควรจะเป็น หลากหลาย การถามสีโปรดของใครบางคนจะให้คำตอบที่เป็นไปได้เพียงเล็กน้อย
- ค้นหา คำตอบจะต้องซับซ้อน - หากสามารถหาคำตอบได้ง่าย ใด (จำคนมีตำแหน่งสูงๆ) แล้วเขาก็เลว
- คำตอบจะต้องเป็น ไฟฟ้ากระแสตรง ทันเวลา - หากคุณถามภาพยนตร์เรื่องโปรดของใครบางคน หนึ่งปีต่อมาคำตอบอาจแตกต่างกัน
ที่เกิดขึ้นมีเว็บไซต์เฉพาะสำหรับการถามคำถามที่ดีเรียกว่า . คำถามบางข้อดูค่อนข้างดี แต่บางข้อก็ไม่ผ่านการทดสอบบางข้อที่อธิบายไว้ข้างต้น โดยเฉพาะการทดสอบ "ความง่ายในการค้นหา"
ฉันจะแสดงให้คุณเห็นว่าคำถามเพื่อความปลอดภัยถูกนำมาใช้ใน PayPal อย่างไร และโดยเฉพาะอย่างยิ่ง ความพยายามของเว็บไซต์ในการระบุตัวตนมากเพียงใด เราเห็นหน้าเริ่มต้นกระบวนการ (ด้วย CAPTCHA) ด้านบน และที่นี่เราจะแสดงสิ่งที่เกิดขึ้นหลังจากที่คุณป้อนที่อยู่อีเมลและแก้ไข CAPTCHA:
เป็นผลให้ผู้ใช้ได้รับอีเมลต่อไปนี้:
จนถึงตอนนี้ทุกอย่างค่อนข้างปกติ แต่นี่คือสิ่งที่ซ่อนอยู่หลัง URL รีเซ็ตนี้:
คำถามลับจึงเข้ามามีบทบาท ในความเป็นจริง PayPal ยังอนุญาตให้คุณรีเซ็ตรหัสผ่านโดยการตรวจสอบหมายเลขบัตรเครดิตของคุณ ดังนั้นจึงมีช่องทางเพิ่มเติมที่เว็บไซต์หลายแห่งไม่สามารถเข้าถึงได้ ฉันไม่สามารถเปลี่ยนรหัสผ่านโดยไม่ตอบได้ ทั้งสอง คำถามลับ (หรือไม่ทราบหมายเลขบัตร) แม้ว่าจะมีคนขโมยอีเมลของฉัน พวกเขาจะไม่สามารถรีเซ็ตรหัสผ่านบัญชี PayPal ของตนได้ เว้นแต่พวกเขาจะทราบข้อมูลส่วนตัวของฉันเพิ่มเติมอีกเล็กน้อย ข้อมูลอะไร? ต่อไปนี้คือตัวเลือกสำหรับคำถามเพื่อความปลอดภัยของ PayPal:
คำถามเกี่ยวกับโรงเรียนและโรงพยาบาลอาจจะดูยุ่งยากเล็กน้อยในแง่ของความสะดวกในการค้นหา แต่คำถามอื่นๆ ก็ไม่ได้แย่ขนาดนั้น อย่างไรก็ตาม เพื่อปรับปรุงความปลอดภัย PayPal จำเป็นต้องมีการระบุตัวตนเพิ่มเติม การเปลี่ยนแปลง คำตอบสำหรับคำถามเพื่อความปลอดภัย:
PayPal เป็นตัวอย่างที่ค่อนข้างยูโทเปียของการรีเซ็ตรหัสผ่านที่ปลอดภัย: ใช้ CAPTCHA เพื่อลดความเสี่ยงของการบังคับใช้อย่างดุร้าย ถามคำถามเพื่อความปลอดภัยสองข้อ จากนั้นจึงต้องการข้อมูลระบุตัวตนที่แตกต่างไปจากเดิมอย่างสิ้นเชิงเพียงเพื่อเปลี่ยนคำตอบ - และนั่นคือหลังจากที่ผู้ใช้ ได้ลงชื่อเข้าใช้แล้ว แน่นอนว่านี่คือสิ่งที่เรา ที่คาดหวัง จะมาจาก PayPal; เป็นสถาบันการเงินที่ต้องจัดการกับเงินก้อนใหญ่ นี่ไม่ได้หมายความว่าการรีเซ็ตรหัสผ่านทุกครั้งจะต้องทำตามขั้นตอนเหล่านี้ ซึ่งโดยส่วนใหญ่แล้วถือว่าเกินความจำเป็น แต่เป็นตัวอย่างที่ดีสำหรับกรณีที่การรักษาความปลอดภัยเป็นเรื่องสำคัญทางธุรกิจ
ความสะดวกของระบบคำถามเพื่อความปลอดภัยคือ หากคุณไม่ได้นำไปใช้ทันที คุณสามารถเพิ่มในภายหลังได้หากจำเป็นต้องมีระดับการปกป้องทรัพยากร ตัวอย่างที่ดีของเรื่องนี้ก็คือ Apple ซึ่งเพิ่งนำกลไกนี้ไปใช้เมื่อเร็วๆ นี้ [บทความที่เขียนในปี 2012]. เมื่อฉันเริ่มอัปเดตแอปพลิเคชันบน iPad ฉันเห็นคำขอต่อไปนี้:
จากนั้นฉันก็เห็นหน้าจอที่ฉันสามารถเลือกคำถามและคำตอบเพื่อความปลอดภัยได้หลายคู่ รวมถึงที่อยู่อีเมลสำหรับช่วยเหลือ:
สำหรับ PayPal คำถามจะถูกเลือกไว้ล่วงหน้าแล้ว และบางคำถามก็ค่อนข้างดี:
คำถามและคำตอบทั้งสามคู่แสดงถึงชุดคำถามที่เป็นไปได้ที่แตกต่างกัน ดังนั้นจึงมีวิธีมากมายในการกำหนดค่าบัญชี
อีกแง่มุมที่ต้องพิจารณาเกี่ยวกับคำตอบสำหรับคำถามเพื่อความปลอดภัยก็คือการจัดเก็บข้อมูล ข้อความธรรมดาใน DB ก่อให้เกิดภัยคุกคามเกือบจะเหมือนกับในกรณีของรหัสผ่าน กล่าวคือ การเปิดเผยฐานข้อมูลจะเปิดเผยค่าทันที และไม่เพียงแต่ทำให้แอปพลิเคชันมีความเสี่ยงเท่านั้น แต่ยังอาจทำให้แอปพลิเคชันที่แตกต่างกันโดยสิ้นเชิงโดยใช้คำถามเพื่อความปลอดภัยเดียวกัน (เป็นอีกครั้ง ). ทางเลือกหนึ่งคือการแฮชที่ปลอดภัย (อัลกอริธึมที่แข็งแกร่งและเกลือสุ่มแบบเข้ารหัส) แต่อาจแตกต่างจากกรณีการจัดเก็บรหัสผ่านส่วนใหญ่ตรงที่อาจมีเหตุผลที่ดีที่การตอบสนองจะปรากฏเป็นข้อความธรรมดา สถานการณ์ทั่วไปคือการยืนยันตัวตนโดยผู้ให้บริการโทรศัพท์สด แน่นอนว่าในกรณีนี้ การแฮชยังสามารถใช้ได้ (ผู้ปฏิบัติงานสามารถป้อนการตอบกลับที่ไคลเอ็นต์ตั้งชื่อไว้) แต่ในกรณีที่เลวร้ายที่สุด คำตอบลับจะต้องอยู่ในที่เก็บข้อมูลการเข้ารหัสระดับหนึ่ง แม้ว่าจะเป็นเพียงการเข้ารหัสแบบสมมาตรก็ตาม สรุป: รักษาความลับเหมือนเป็นความลับ!
แง่มุมสุดท้ายของคำถามและคำตอบเพื่อความปลอดภัยก็คือ คำถามและคำตอบเหล่านี้มีความเสี่ยงต่อวิศวกรรมทางสังคมมากกว่า การพยายามแยกรหัสผ่านไปยังบัญชีของผู้อื่นโดยตรงก็เป็นสิ่งหนึ่ง แต่การเริ่มสนทนาเกี่ยวกับการสร้างรหัสผ่าน (คำถามเพื่อความปลอดภัยยอดนิยม) นั้นแตกต่างไปจากเดิมอย่างสิ้นเชิง ในความเป็นจริง คุณสามารถสื่อสารกับใครบางคนเกี่ยวกับแง่มุมต่างๆ ในชีวิตของพวกเขาได้เป็นอย่างดี ซึ่งอาจก่อให้เกิดคำถามลับๆ โดยไม่กระตุ้นให้เกิดความสงสัย แน่นอนว่าประเด็นสำคัญของคำถามเพื่อความปลอดภัยก็คือ มันเกี่ยวข้องกับประสบการณ์ชีวิตของใครบางคน ดังนั้นจึงน่าจดจำ และนั่นคือจุดที่ปัญหาอยู่ - ผู้คนชอบพูดคุยเกี่ยวกับประสบการณ์ชีวิตของพวกเขา! คุณไม่สามารถทำอะไรเกี่ยวกับเรื่องนี้ได้มากนัก หากคุณเลือกตัวเลือกคำถามเพื่อความปลอดภัยดังกล่าวเท่านั้น น้อยกว่า มีแนวโน้มที่จะถูกดึงออกมาจากวิศวกรรมสังคม
[ยังมีต่อ.]เป็นโฆษณา
VDSน่า เสนอความน่าเชื่อถือ แต่ละเซิร์ฟเวอร์เชื่อมต่อกับช่องทางอินเทอร์เน็ต 500 Mbps และได้รับการป้องกันจากการโจมตี DDoS ฟรี!
ที่มา: will.com