ฉันกำลังทำงานกับผู้ให้บริการ PHP OpenID ที่จะทำงานผ่าน HTTPS (ด้วยเหตุนี้จึงมีการเข้ารหัส SSL)
มันเป็นเรื่องที่ไม่ถูกต้องสำหรับผมที่จะส่งรหัสผ่านเป็นข้อความธรรมดา? HTTPS ในทางทฤษฎีไม่สามารถดักจับได้ดังนั้นฉันจึงไม่เห็นอะไรผิดปกติ หรือไม่ปลอดภัยในบางระดับและฉันไม่เห็นสิ่งนี้?
คำตอบ:
มันมีความปลอดภัย. นั่นคือวิธีการทำงานของเว็บทั้งหมด รหัสผ่านทั้งหมดในแบบฟอร์มจะถูกส่งเป็นข้อความธรรมดาเสมอดังนั้นจึงขึ้นอยู่กับ HTTPS เพื่อรักษาความปลอดภัย
คุณยังคงต้องตรวจสอบให้แน่ใจว่าคุณส่งผ่านคำขอ POST ไม่ใช่ GET หากคุณส่งผ่านคำขอ GET อาจบันทึกเป็นข้อความธรรมดาในบันทึกประวัติเบราว์เซอร์ของผู้ใช้หรือบันทึกการเข้าถึงของเว็บเซิร์ฟเวอร์
หากปิดใช้งาน HTTP และคุณใช้เฉพาะ HTTPS แสดงว่าคุณไม่ได้ส่งรหัสผ่านเป็นข้อความธรรมดาจริงๆ
แฮชฝั่งไคลเอ็นต์ ทำไม? ให้ฉันบอกคุณเกี่ยวกับการทดลองเล็กน้อย เดินไปที่คอมพิวเตอร์ในโรงอาหารของ บริษัท เปิดเบราว์เซอร์ไปยังหน้าเข้าสู่ระบบเว็บไซต์ของ บริษัท (https) กด F12 คลิกแท็บเครือข่ายทำเครื่องหมายที่บันทึกถาวรย่อขนาดคอนโซล แต่เปิดหน้าเว็บไว้เพื่อเข้าสู่หน้าเข้าสู่ระบบ นั่งทานอาหารกลางวัน ดูเป็นพนักงานหลังจากที่พนักงานล็อกอินเข้าสู่เว็บไซต์ของ บริษัท และการเป็นพนักงานที่ดีจะออกจากระบบเมื่อทำเสร็จแล้ว รับประทานอาหารกลางวันเสร็จนั่งลงที่คอมพิวเตอร์เพื่อเปิดแท็บเครือข่ายและดูชื่อผู้ใช้และรหัสผ่านทุกรายการในรูปแบบข้อความธรรมดา
ไม่มีเครื่องมือพิเศษไม่มีความรู้พิเศษไม่มีฮาร์ดแวร์แฮ็กแฟนซีไม่มีคีย์ล็อกเกอร์ที่ดีแค่ F12 รุ่นเก่า
แต่เดี๋ยวก่อนคิดว่าสิ่งที่คุณต้องการคือ SSL คนเลวจะรักคุณ
มาจดบันทึกคำตอบก่อนหน้านี้กัน
ประการแรกอาจไม่ใช่ความคิดที่ดีที่สุดที่จะใช้ฝั่งไคลเอ็นต์แฮชอัลกอริทึม หากรหัสผ่านของคุณอยู่ในฝั่งเซิร์ฟเวอร์คุณจะไม่สามารถเปรียบเทียบแฮชได้ (อย่างน้อยก็ไม่ใช่ถ้าคุณไม่เก็บแฮชของไคลเอนต์ไว้ในฐานข้อมูลในเลเยอร์การแฮชจากรหัสผ่านซึ่งเหมือนกันหรือ แย่ลง) และคุณไม่ต้องการใช้อัลกอริทึมการแฮชที่ใช้โดยฐานข้อมูลในฝั่งไคลเอ็นต์มันจะโง่
ประการที่สองการซื้อขายคีย์การเข้ารหัสก็ไม่เหมาะเช่นกัน MITM ในทางทฤษฎี (เนื่องจากเขามีใบรับรองหลักที่ติดตั้งบนไคลเอนต์) เปลี่ยนคีย์การเข้ารหัสและเปลี่ยนด้วยคีย์ของเขาเอง:
การเชื่อมต่อดั้งเดิม (ไม่พิจารณา tls) จากเซิร์ฟเวอร์ตามทฤษฎีที่แลกเปลี่ยนคีย์:
คำขอคีย์สาธารณะของไคลเอ็นต์> เซิร์ฟเวอร์เก็บคีย์ส่วนตัวสร้างคีย์สาธารณะไปยังไคลเอนต์> เซิร์ฟเวอร์ส่งคีย์สาธารณะไปยังไคลเอนต์
ตอนนี้ใน atrack MITM เชิงทฤษฎี:
ไคลเอนต์ขอคีย์สาธารณะ> MITM สร้างคีย์ส่วนตัวปลอม > เซิร์ฟเวอร์เก็บคีย์ส่วนตัวสร้างคีย์สาธารณะไปยังไคลเอนต์> MITM ได้รับคีย์สาธารณะจากเซิร์ฟเวอร์ดั้งเดิมตอนนี้เรามีอิสระที่จะส่งคีย์สาธารณะปลอมของเราไปยังไคลเอนต์และ เมื่อใดก็ตามที่มีการร้องขอจากไคลเอนต์เราจะถอดรหัสข้อมูลไคลเอนต์ด้วยคีย์ปลอมเปลี่ยนเพย์โหลด (หรืออ่าน) และเข้ารหัสด้วยคีย์สาธารณะดั้งเดิม > MITM ส่งคีย์สาธารณะปลอมไปยังไคลเอนต์
นั่นคือจุดสำคัญของการมีใบรับรอง CA ที่เชื่อถือได้ใน TLS และนั่นคือวิธีที่คุณได้รับข้อความเตือนจากเบราว์เซอร์หากใบรับรองไม่ถูกต้อง
ในการตอบสนองต่อ OP: ในความเห็นที่ต่ำต้อยของฉันคุณไม่สามารถทำเช่นนั้นได้เพราะไม่ช้าก็เร็วมีคนต้องการโจมตีผู้ใช้จากบริการของคุณและจะพยายามทำลายโปรโตคอลของคุณ
อย่างไรก็ตามสิ่งที่คุณทำได้คือการติดตั้ง 2FA เพื่อป้องกันไม่ให้ผู้อื่นพยายามเข้าสู่ระบบด้วยรหัสผ่านเดียวกัน ระวังการโจมตีซ้ำ
ฉันไม่ถนัดเรื่องการเข้ารหัสโปรดแก้ไขฉันด้วยถ้าฉันผิด
โปสเตอร์อื่น ๆ ถูกต้อง ตอนนี้คุณกำลังใช้ SSL ในการเข้ารหัสการส่งรหัสผ่านตรวจสอบให้แน่ใจว่าคุณได้แฮชด้วยอัลกอริทึมและเกลือที่ดีเพื่อให้ได้รับการปกป้องเมื่ออยู่นิ่งเช่นกัน
@CodeDog ตัวอย่างมีปัญหา ..
ใช่ฉันเชื่อได้ว่าผู้ใช้จะเข้าสู่กล่องโรงอาหาร หากคุณกำลังเก็บบันทึกจากโรงอาหารของ บริษัท แสดงว่าคุณเป็นผู้ละเมิดความปลอดภัย ควรปิดใช้งานกล่องโรงอาหารของ บริษัท เช่นไม่มีข้อกำหนดไม่มีคนตัดไม้ไม่มีการเข้าถึงระยะไกล ฯลฯ เพื่อป้องกันคุณแฮกเกอร์ภายใน
ตัวอย่างนี้เป็นหนึ่งในการรักษาความปลอดภัยในการเข้าถึงคอมพิวเตอร์และไม่เกี่ยวข้องกับความปลอดภัยของเครือข่าย มีไว้เพื่อเป็นเหตุผลสำหรับการแฮชฝั่งไคลเอ็นต์ แต่ถ้าคุณมีการเข้าถึงคอมพิวเตอร์คุณสามารถใช้เครื่องบันทึกการกดแป้นพิมพ์และข้ามสิ่งนั้นได้ แฮชฝั่งไคลเอ็นต์ไม่เกี่ยวข้องอีกครั้ง ตัวอย่างของ @CodeDog คือการแฮ็กการเข้าถึงคอมพิวเตอร์และต้องใช้เทคนิคที่แตกต่างจากการแฮ็กเลเยอร์เครือข่าย
นอกจากนี้การแฮ็กคอมพิวเตอร์สาธารณะยังได้รับการป้องกันโดยการทำให้ระบบเสียประโยชน์จากภัยคุกคามดังที่กล่าวไว้ข้างต้น เช่นใช้ Chromebook สำหรับคอมพิวเตอร์โรงอาหารสาธารณะ แต่นั่นถูกข้ามโดยการแฮ็กทางกายภาพ ในช่วงนอกเวลาให้ไปที่โรงอาหารและตั้งค่ากล้องลับเพื่อบันทึกการกดแป้นพิมพ์ของผู้ใช้ ถ้าอย่างนั้นไม่สำคัญว่าคอมพิวเตอร์โรงอาหารจะพิการหรือใช้การเข้ารหัสประเภทใด
เลเยอร์ทางกายภาพ -> เลเยอร์คอมพิวเตอร์ -> เลเยอร์ไคลเอนต์ -> เลเยอร์เครือข่าย -> เลเยอร์เซิร์ฟเวอร์
สำหรับระบบเครือข่ายไม่ว่าคุณจะแฮชในฝั่งไคลเอ็นต์เนื่องจากเลเยอร์ https / ssl จะเข้ารหัส passwd ธรรมดา ดังที่คนอื่นพูดถึงการแฮชไคลเอ็นต์นั้นซ้ำซ้อนหาก TLS ปลอดภัย