เกิดอะไรขึ้นถ้า JWT ถูกขโมย?

ฉันพยายามใช้การพิสูจน์ตัวตนแบบไร้รัฐกับ JWT สำหรับ RESTful API ของฉัน

AFAIK, JWT นั้นเป็นสตริงเข้ารหัสที่ส่งผ่านเป็นส่วนหัว HTTP ในระหว่างการเรียกใช้ REST

แต่ถ้ามีคนดักฟังที่เห็นคำขอและขโมยโทเค็นล่ะ? จากนั้นเขาจะสามารถปลอมแปลงคำขอด้วยตัวตนของฉันได้อย่างไร

อันที่จริงความกังวลนี้ใช้กับทุกการตรวจสอบ token-based

จะป้องกันได้อย่างไร ช่องทางที่ปลอดภัยเช่น HTTPS

ฉันเป็นผู้เขียนของไลบรารี่โหนดที่จัดการกับการพิสูจน์ตัวตนในเชิงลึก, express-stormpath , ดังนั้นฉันจะพูดสอดกับข้อมูลบางอย่างที่นี่

ก่อนอื่น JWT มักไม่มีการเข้ารหัส ในขณะที่มีวิธีการเข้ารหัส JWTs (ดู: JWEs ) สิ่งนี้ไม่ได้เป็นเรื่องธรรมดาในทางปฏิบัติด้วยเหตุผลหลายประการ

ถัดไปขึ้นไปการตรวจสอบความถูกต้องทุกรูปแบบ (โดยใช้ JWT หรือไม่ก็ตาม) ขึ้นอยู่กับการโจมตีของ MitM (การโจมตีแบบกึ่งกลาง) การโจมตีเหล่านี้เกิดขึ้นเมื่อผู้โจมตีสามารถดูทราฟฟิกเครือข่ายของคุณเมื่อคุณทำการร้องขอผ่านอินเทอร์เน็ต นี่คือสิ่งที่ ISP ของคุณสามารถมองเห็นได้ NSA ฯลฯ

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

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

ตอนนี้นี่คือที่มาของโปรโตคอล

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

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

สิ่งที่ทำให้คำถามของคุณน่าสนใจยิ่งขึ้นคือโปรโตคอลที่ใช้งานอยู่

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

แนวคิดคือถ้าโทเค็นของคุณถูกขโมยผู้โจมตีสามารถใช้งานได้เพียงช่วงเวลาสั้น ๆ

ด้วย OAuth2 คุณต้องรับรองความถูกต้องของตัวคุณเองกับเซิร์ฟเวอร์อีกครั้งโดยการระบุชื่อผู้ใช้ / รหัสผ่านหรือข้อมูลรับรอง API ของคุณจากนั้นรับโทเค็นกลับมาเพื่อแลกเปลี่ยน

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

หวังว่านี่จะช่วยได้ ^^

ฉันรู้ว่านี่เป็นคำถามเก่า แต่ฉันคิดว่าฉันสามารถวาง $ 0.50 ของฉันที่นี่อาจมีใครบางคนสามารถปรับปรุงหรือให้ข้อโต้แย้งเพื่อปฏิเสธแนวทางของฉันโดยสิ้นเชิง ฉันใช้ JWT ใน RESTful API ผ่าน HTTPS (ofc)

เพื่อให้ทำงานได้คุณควรออกโทเค็นอายุสั้น ๆ เสมอ (ขึ้นอยู่กับกรณีส่วนใหญ่ในแอพของฉันฉันตั้งค่าการexpเรียกร้องเป็น 30 นาทีและttl3 วันเพื่อให้คุณสามารถรีเฟรชโทเค็นนี้ได้ตราบใดที่ttlยังคงอยู่ ถูกต้องและโทเค็นไม่ได้ถูกขึ้นบัญชีดำ )

สำหรับauthentication serviceในการทำให้โทเค็นเป็นโมฆะฉันชอบที่จะใช้เลเยอร์แคชในหน่วยความจำ ( redisในกรณีของฉัน) เป็นJWT blacklist/ ban-listในหน้าขึ้นอยู่กับเกณฑ์บางอย่าง: (ฉันรู้ว่ามันทำลายปรัชญาสงบ แต่เอกสารที่เก็บไว้เป็น สั้นมากจริง ๆ เพราะฉันขึ้นบัญชีดำสำหรับเวลาที่เหลืออยู่ของพวกเขา - การเรียกร้อง - ttl)

หมายเหตุ: โทเค็นที่อยู่ในบัญชีดำจะไม่สามารถรีเฟรชอัตโนมัติ

• หากuser.passwordหรือuser.emailได้รับการปรับปรุง (ต้องมีการยืนยันรหัสผ่าน) บริการรับรองความถูกต้องจะส่งคืนโทเค็นที่รีเฟรชและทำให้ใช้งานไม่ได้ (บัญชีดำ) ก่อนหน้านี้ดังนั้นหากลูกค้าของคุณตรวจพบว่าตัวตนของผู้ใช้นั้นถูกโจมตี . หากคุณไม่ต้องการใช้บัญชีดำคุณสามารถ (แต่ฉันไม่สนับสนุนให้คุณ) ตรวจสอบการiatอ้างสิทธิ์ (ออกเมื่อ) กับuser.updated_atฟิลด์ (ถ้าjwt.iat < user.updated_atJWT นั้นไม่ถูกต้อง)
• ผู้ใช้ออกจากระบบโดยเจตนา

ในที่สุดคุณตรวจสอบโทเค็นตามปกติเหมือนทุกคน

หมายเหตุ 2:แทนที่จะใช้โทเค็นเอง (ซึ่งมีความยาวจริง ๆ ) เป็นคีย์ของแคชฉันแนะนำให้สร้างและใช้โทเค็น UUID สำหรับการjtiอ้างสิทธิ์ ซึ่งเป็นสิ่งที่ดีและฉันคิดว่า (ไม่แน่ใจตั้งแต่เพิ่งมาในใจของฉัน) คุณสามารถใช้ UUID เดียวกันนี้เป็นโทเค็น CSRF ได้เช่นกันโดยส่งคืนsecure/ non-http-onlyคุกกี้ด้วยและใช้X-XSRF-TOKENส่วนหัวอย่างเหมาะสมโดยใช้ js วิธีนี้คุณหลีกเลี่ยงการคำนวณการสร้างโทเค็นอื่นสำหรับการตรวจสอบ CSRF

ขออภัยที่มาสายเล็กน้อย แต่มีข้อกังวลที่คล้ายกันและตอนนี้ต้องการมีส่วนร่วมในสิ่งเดียวกัน

1) rdeggesเพิ่มจุดที่ยอดเยี่ยมว่า JWT ไม่มีส่วนเกี่ยวข้องกับ "ความปลอดภัย" และเพียงแค่ตรวจสอบความถูกต้องถ้าใครมี messed กับ payload หรือไม่ (ลงนาม); ssl ช่วยป้องกันการรั่วไหล

2) ทีนี้ถ้า ssl นั้นถูกบุกรุก eavesdropper ใด ๆ สามารถขโมยโทเค็นผู้ถือ (JWT) ของเราและปลอมตัวเป็นผู้ใช้ของแท้ขั้นตอนต่อไปที่จะทำคือค้นหา"หลักฐานการครอบครอง"ของ JWT จากลูกค้า .

3) ในตอนนี้ด้วยวิธีนี้ผู้นำเสนอของ JWT มีคีย์ Proof-Of-Possession (POP) ซึ่งผู้รับสามารถยืนยันการเข้ารหัสว่าคำขอนั้นมาจากผู้ใช้จริงหรือไม่

ฉันเรียกหลักฐานการพิสูจน์ของบทความเรื่องนี้และเชื่อมั่นกับ apporach

ฉันจะยินดีถ้าสามารถมีส่วนร่วมอะไร

ไชโย (y)

เราไม่สามารถเพิ่ม ip ของโฮสต์เริ่มต้นที่ร้องขอให้สร้างโทเค็น JWT นี้เป็นส่วนหนึ่งของการอ้างสิทธิ์ได้หรือไม่ ตอนนี้เมื่อ JWT ถูกขโมยและใช้จากเครื่องอื่นเมื่อเซิร์ฟเวอร์ตรวจสอบโทเค็นนี้เราสามารถตรวจสอบว่า IP เครื่องที่ร้องขอตรงกับชุดที่ตั้งเป็นส่วนหนึ่งของการอ้างสิทธิ์หรือไม่ สิ่งนี้จะไม่ตรงกันและด้วยเหตุนี้โทเค็นสามารถถูกปฏิเสธ นอกจากนี้หากผู้ใช้พยายามจัดการโทเค็นด้วยการตั้งค่า ip ของเขาเป็นโทเค็นโทเค็นจะถูกปฏิเสธเมื่อโทเค็นมีการเปลี่ยนแปลง