จะส่งรหัสผ่านอย่างปลอดภัยผ่าน HTTP ได้อย่างไร

หากในหน้าจอเข้าสู่ระบบผู้ใช้ส่งแบบฟอร์มพร้อมชื่อผู้ใช้และรหัสผ่านของเขารหัสผ่านจะถูกส่งเป็นข้อความธรรมดา (แม้จะมี POST ก็ตามโปรดแก้ไขฉันหากฉันผิด)

คำถามคือวิธีที่ถูกต้องในการปกป้องผู้ใช้และรหัสผ่านของเขาจากบุคคลที่สามที่อาจแอบดักฟังข้อมูลการสื่อสารคืออะไร?

ฉันทราบว่า HTTPS สามารถแก้ไขปัญหาได้ แต่มีวิธีใดบ้างที่จะทำให้มั่นใจได้ว่าอย่างน้อยระดับความปลอดภัยโดยใช้โปรโตคอล HTTP มาตรฐาน (คำขอ POST) (อาจใช้จาวาสคริปต์ไม่ทางใดก็ทางหนึ่ง)

แก้ไข ฉันอาจทิ้งสิ่งสำคัญบางอย่างไป

สิ่งที่ฉันเกี่ยวกับคือหน้านั่นคือหน้าเข้าสู่ระบบที่สร้างโดย PHP ซึ่งแน่นอนว่าส่งถึงผู้ใช้ในคำขอ HTTP GET เป็นไฟล์ HTML ไม่มีการเชื่อมต่อ (@Jeremy Powel) ระหว่างเซิร์ฟเวอร์และไคลเอนต์ดังนั้นฉันจึงไม่สามารถสร้างโปรโตคอลการจับมือดังกล่าวได้ และฉันต้องการให้กระบวนการทั้งหมดมีความโปร่งใสสำหรับผู้ใช้ - เขาต้องการส่งรหัสผ่านไม่ใช่จัดการกับการเข้ารหัส

ขอบคุณ

การใช้ HTTP กับ SSL จะทำให้ชีวิตของคุณง่ายขึ้นมากและคุณสามารถพักผ่อนได้อย่างสบายใจคนฉลาด (อย่างน้อยก็ฉลาดกว่าฉัน!) ได้กลั่นกรองวิธีการสื่อสารที่เป็นความลับนี้มาหลายปีแล้ว

การตรวจสอบความปลอดภัยเป็นหัวข้อกว้าง ๆ โดยสรุปตามที่ @ jeremy-powell กล่าวไว้มักชอบส่งข้อมูลรับรองผ่าน HTTPS แทน HTTP จะทำให้ปวดหัวที่เกี่ยวข้องกับความปลอดภัยไปมาก

ใบรับรอง TSL / SSL ค่อนข้างถูกในทุกวันนี้ ในความเป็นจริงหากคุณไม่ต้องการเสียเงินเลยมีให้บริการฟรีallowencrypt.org - ผู้ออกใบรับรองอัตโนมัติ

คุณสามารถก้าวไปอีกขั้นและใช้caddyserver.comซึ่งเรียกใช้ allowencrypt อยู่เบื้องหลัง

ตอนนี้เมื่อเราได้ HTTPS แล้ว ...

คุณไม่ควรส่งข้อมูลเข้าสู่ระบบและรหัสผ่านผ่านพารามิเตอร์ POST payload หรือ GET ใช้ส่วนหัวการอนุญาต (โครงร่างการพิสูจน์ตัวตนการเข้าถึงพื้นฐาน) แทนซึ่งสร้างขึ้นดังนี้:

• ชื่อผู้ใช้และรหัสผ่านจะรวมกันเป็นสตริงโดยคั่นด้วยเครื่องหมายจุดคู่เช่นชื่อผู้ใช้: รหัสผ่าน
• สตริงผลลัพธ์ถูกเข้ารหัสโดยใช้ตัวแปร RFC2045-MIME ของ Base64 ยกเว้นไม่ จำกัด ที่ 76 อักขระ / บรรทัด
• วิธีการอนุญาตและช่องว่างเช่น "พื้นฐาน" จะถูกใส่ก่อนสตริงที่เข้ารหัส

แหล่งที่มา: Wikipedia: ส่วนหัวการอนุญาต

อาจดูเหมือนซับซ้อนเล็กน้อย แต่ก็ไม่ใช่ มีห้องสมุดดีๆมากมายที่จะมอบฟังก์ชันนี้ให้คุณได้ทันที

มีเหตุผลที่ดีสองสามประการที่คุณควรใช้ส่วนหัวการอนุญาต

1. มันเป็นมาตรฐาน
2. ง่ายมาก (หลังจากเรียนรู้วิธีใช้แล้ว)
3. จะช่วยให้คุณสามารถเข้าสู่ระบบที่ระดับ URL ได้ดังนี้: https://user:password@your.domain.com/login(เช่น Chrome จะแปลงเป็นAuthorizationส่วนหัวโดยอัตโนมัติ)

สิ่งสำคัญ:
ตามที่ @zaph ระบุไว้ในความคิดเห็นของเขาด้านล่างการส่งข้อมูลที่ละเอียดอ่อนเนื่องจากข้อความค้นหา GET ไม่ใช่ความคิดที่ดีเนื่องจากมักจะลงเอยในบันทึกของเซิร์ฟเวอร์

คุณสามารถใช้แผนการตอบสนองความท้าทาย สมมติว่าทั้งไคลเอนต์และเซิร์ฟเวอร์รู้ความลับ S จากนั้นเซิร์ฟเวอร์จะมั่นใจได้ว่าไคลเอนต์รู้รหัสผ่าน (โดยไม่ต้องให้รหัสผ่าน) โดย:

1. เซิร์ฟเวอร์ส่งตัวเลขสุ่ม R ไปยังไคลเอนต์
2. ไคลเอนต์ส่ง H (R, S) กลับไปที่เซิร์ฟเวอร์ (โดยที่ H คือฟังก์ชันแฮชการเข้ารหัสเช่น SHA-256)
3. เซิร์ฟเวอร์คำนวณ H (R, S) และเปรียบเทียบกับการตอบสนองของลูกค้า หากตรงกันเซิร์ฟเวอร์จะรู้ว่าไคลเอนต์รู้รหัสผ่าน

แก้ไข:

มีปัญหาที่นี่เกี่ยวกับความใหม่ของ R และความจริงที่ว่า HTTP ไม่มีสถานะ นี้สามารถจัดการได้โดยมีเซิร์ฟเวอร์สร้างความลับเรียกว่า Q ที่เพียงเซิร์ฟเวอร์รู้ จากนั้นโปรโตคอลจะเป็นดังนี้:

โปรดทราบเนื่องจากไคลเอนต์ไม่สามารถปลอมแปลง H (R, Q) ได้ H (R, Q) จึงทำหน้าที่เป็นคุกกี้ (ดังนั้นจึงสามารถนำไปใช้เป็นคุกกี้ได้)

การแก้ไขอื่น:

การแก้ไขโปรโตคอลก่อนหน้านี้ไม่ถูกต้องเนื่องจากทุกคนที่สังเกตเห็น H (R, Q) ดูเหมือนว่าจะสามารถเล่นซ้ำได้ด้วยแฮชที่ถูกต้อง เซิร์ฟเวอร์ต้องจำว่า R ตัวไหนไม่สดอีกต่อไป ฉันกำลังตอบรับคำตอบนี้เพื่อให้พวกคุณสามารถแก้ไขได้และหาสิ่งที่ดีออกมา

หากเว็บโฮสต์ของคุณอนุญาตหรือคุณจะต้องจัดการกับข้อมูลที่ละเอียดอ่อนให้ใช้ HTTPS เป็นช่วงเวลา (มักจะกำหนดโดยกฎหมาย afaik)

มิฉะนั้นหากคุณต้องการทำบางอย่างผ่าน HTTP ฉันจะทำอะไรแบบนี้

1. เซิร์ฟเวอร์ฝังคีย์สาธารณะไว้ในหน้าเข้าสู่ระบบ
2. ลูกค้ากรอกแบบฟอร์มการเข้าสู่ระบบและคลิกส่ง
3. คำขอ AJAX ได้รับการประทับเวลาปัจจุบันจากเซิร์ฟเวอร์
4. สคริปต์ฝั่งไคลเอ็นต์เชื่อมต่อข้อมูลประจำตัวการประทับเวลาและเกลือ (แฮชจากข้อมูลอะนาล็อกเช่นการเคลื่อนไหวของเมาส์เหตุการณ์การกดแป้น) เข้ารหัสโดยใช้คีย์สาธารณะ
5. ส่งแฮชที่เป็นผลลัพธ์
6. เซิร์ฟเวอร์ถอดรหัสแฮช
7. ตรวจสอบว่าการประทับเวลาล่าสุดเพียงพอหรือไม่ (อนุญาตให้ใช้หน้าต่างสั้น ๆ 5-10 วินาทีเท่านั้น) ปฏิเสธการเข้าสู่ระบบหากการประทับเวลาเก่าเกินไป
8. เก็บแฮชเป็นเวลา 20 วินาที ปฏิเสธแฮชเดียวกันสำหรับการล็อกอินในช่วงเวลานี้
9. พิสูจน์ตัวตนผู้ใช้

ดังนั้นวิธีนี้จึงป้องกันรหัสผ่านและแฮชการตรวจสอบสิทธิ์เดียวกันไม่สามารถเล่นซ้ำได้

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

1. เซิร์ฟเวอร์ตั้งค่าคุกกี้เซสชันพิเศษซึ่งประกอบด้วยสตริงแบบสุ่ม
2. เบราว์เซอร์จะส่งคุกกี้นี้กลับในคำขอถัดไป
3. เซิร์ฟเวอร์จะตรวจสอบค่าในคุกกี้หากแตกต่างกันแสดงว่ามันทำลายเซสชันมิฉะนั้นทั้งหมดก็ไม่เป็นไร
4. เซิร์ฟเวอร์ตั้งค่าคุกกี้อีกครั้งด้วยข้อความที่แตกต่างกัน

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

แก้ไข: โปรดทราบว่านี่ไม่ได้ป้องกันการโจมตีของ MITM หากผู้โจมตีตั้งค่าเพจของตนเองด้วยคีย์สาธารณะและคำขอพร็อกซีที่แตกต่างกันไปยังเซิร์ฟเวอร์ เพื่อป้องกันสิ่งนี้คีย์สาธารณะจะต้องตรึงไว้ในที่จัดเก็บในตัวของเบราว์เซอร์หรือภายในแอพเพื่อตรวจจับกลเม็ดประเภทนี้

เกี่ยวกับการใช้งาน: RSA น่าจะเป็นอัลกอริทึมที่รู้จักกันมากที่สุด แต่ค่อนข้างช้าสำหรับคีย์แบบยาว ฉันไม่รู้ว่าการติดตั้ง PHP หรือ Javascript จะเร็วแค่ไหน แต่อาจมีอัลกอริทึมที่เร็วกว่า

ฉันจะใช้ระบบแลกเปลี่ยนคีย์ Diffie-Hellman ฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์กับ AJAX หรือการส่งแบบฟอร์มหลายรายการ (ฉันแนะนำแบบเดิม) แม้ว่าฉันจะไม่เห็นการใช้งานที่ดีบนอินเทอร์เน็ต โปรดจำไว้ว่าไลบรารี JS สามารถเสียหายหรือเปลี่ยนแปลงได้โดย MITM พื้นที่เก็บข้อมูลในเครื่องสามารถใช้เพื่อช่วยต่อสู้กับปัญหานี้ได้ในระดับหนึ่ง

คุณสามารถใช้SRPเพื่อใช้รหัสผ่านที่ปลอดภัยผ่านช่องทางที่ไม่ปลอดภัย ข้อดีคือแม้ว่าผู้โจมตีจะดักฟังการรับส่งข้อมูลหรือโจมตีเซิร์ฟเวอร์ แต่ก็ไม่สามารถใช้รหัสผ่านบนเซิร์ฟเวอร์อื่นได้ https://github.com/alax/jsrpเป็นไลบรารี javascript ที่รองรับรหัสผ่านที่ปลอดภัยผ่าน HTTP ในเบราว์เซอร์หรือฝั่งเซิร์ฟเวอร์ (ผ่านโหนด)

HTTPS มีประสิทธิภาพมากเนื่องจากใช้การเข้ารหัสแบบไม่สมมาตร การเข้ารหัสประเภทนี้ไม่เพียง แต่ให้คุณสร้างอุโมงค์เข้ารหัส แต่คุณสามารถยืนยันได้ว่าคุณกำลังคุยกับคนที่ใช่ไม่ใช่แฮกเกอร์

นี่คือซอร์สโค้ด Java ซึ่งใช้ RSA การเข้ารหัสแบบอสมมาตร (ใช้โดย PGP) ในการสื่อสาร: http://www.hushmail.com/services/downloads/

คุณสามารถใช้ ssl สำหรับโฮสต์ของคุณได้มีโครงการฟรีสำหรับ ssl เช่น allowencrypt https://letsencrypt.org/

การใช้ https เสียงเป็นตัวเลือกที่ดีที่สุดที่นี่ (ใบรับรองไม่แพงขนาดนี้) อย่างไรก็ตามหาก http เป็นข้อกำหนดคุณอาจใช้การเข้ารหัสบางส่วน - เข้ารหัสที่ฝั่งเซิร์ฟเวอร์และถอดรหัสในเบราว์เซอร์ของผู้ใช้ (ส่งคีย์แยกต่างหาก)

เราได้ใช้สิ่งนั้นในขณะที่ใช้safevia.net - การเข้ารหัสจะทำบนฝั่งไคลเอนต์ (ผู้ส่ง / ผู้รับ) ดังนั้นข้อมูลผู้ใช้จึงไม่มีอยู่ในเครือข่ายหรือเลเยอร์เซิร์ฟเวอร์