หากคุณสามารถถอดรหัส JWT พวกเขาจะปลอดภัยได้อย่างไร?

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

ฉันรู้ว่าพวกเขาต้องปลอดภัย แต่ฉันแค่อยากจะเข้าใจเทคโนโลยีจริงๆ ฉันพลาดอะไรไป

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

ตอบความคิดเห็นของคุณ: ฉันไม่แน่ใจว่าฉันเข้าใจความคิดเห็นของคุณอย่างถูกต้องหรือไม่ เพื่อให้แน่ใจว่า: คุณรู้จักและเข้าใจลายเซ็นดิจิทัลหรือไม่? ฉันจะอธิบายสั้น ๆ หนึ่งตัวแปร (HMAC ซึ่งสมมาตร แต่มีคนอื่นอีกมากมาย)

สมมติว่า Alice ต้องการส่ง JWT ถึง Bob พวกเขาทั้งสองรู้ว่าเป็นความลับร่วมกัน มัลลอรี่ไม่ทราบความลับนั้น แต่ต้องการแทรกแซงและเปลี่ยนแปลง JWT เพื่อป้องกันสิ่งนั้น Alice คำนวณHash(payload + secret)และผนวกสิ่งนี้เป็นลายเซ็น

เมื่อได้รับข้อความบ็อบสามารถคำนวณHash(payload + secret)เพื่อตรวจสอบว่าลายเซ็นตรงกันหรือไม่ อย่างไรก็ตามหากมัลลอรีเปลี่ยนแปลงบางอย่างในเนื้อหาเธอจะไม่สามารถคำนวณลายเซ็นที่ตรงกัน (ซึ่งจะเป็นHash(newContent + secret)) เธอไม่รู้ความลับและไม่มีทางที่จะค้นพบมัน ซึ่งหมายความว่าถ้าเธอเปลี่ยนแปลงบางสิ่งบางอย่างลายเซ็นจะไม่ตรงกันอีกต่อไปและบ๊อบจะไม่ยอมรับ JWT อีกต่อไป

สมมติว่าเราจะส่งบุคคลอื่นข้อความและลงนามด้วย{"id":1} Hash(content + secret)(+ เป็นเพียงการต่อกันที่นี่) ฉันจะใช้ฟังก์ชั่น SHA256 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8cกัญชาและลายเซ็นที่ผมได้รับคือ: ตอนนี้ก็เปิดของคุณ: {"id":2}เล่นบทบาทของมัลลอและพยายามที่จะลงนามในข้อความ คุณทำไม่ได้เพราะคุณไม่รู้ความลับที่ฉันใช้ ถ้าฉันคิดว่าผู้รับรู้ความลับเขาสามารถคำนวณลายเซ็นของข้อความใด ๆ และตรวจสอบว่ามันถูกต้อง

คุณสามารถไปที่jwt.ioวางโทเค็นของคุณและอ่านเนื้อหา นี่เป็นครั้งแรกที่ผู้คนจำนวนมากสับสน

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

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

1. เหตุผลที่ง่ายที่สุดคือเนื่องจากมันถือว่านี่เป็นปัญหาที่แก้ไขแล้วส่วนใหญ่ หากจัดการกับลูกค้าเช่นเว็บเบราว์เซอร์คุณสามารถจัดเก็บโทเค็น JWT ไว้ในคุกกี้ที่secure(ไม่ถูกส่งผ่าน HTTP ผ่านทาง HTTPS เท่านั้น) และhttpOnly(ไม่สามารถอ่านได้โดย Javascript) และพูดคุยกับเซิร์ฟเวอร์ผ่านทาง แชนเนลที่เข้ารหัส (HTTPS) เมื่อคุณรู้ว่าคุณมีช่องทางที่ปลอดภัยระหว่างเซิร์ฟเวอร์และลูกค้าคุณสามารถแลกเปลี่ยน JWT หรืออะไรก็ได้ที่คุณต้องการ

2. สิ่งนี้ทำให้ง่าย การใช้งานที่ง่ายทำให้การปรับใช้ง่ายขึ้น แต่ก็ช่วยให้แต่ละชั้นทำในสิ่งที่ดีที่สุด (ให้ HTTPS จัดการการเข้ารหัส)

3. JWT ไม่ได้มีไว้สำหรับเก็บข้อมูลที่ละเอียดอ่อน เมื่อเซิร์ฟเวอร์ได้รับโทเค็น JWT และตรวจสอบความถูกต้องแล้วก็สามารถค้นหา ID ผู้ใช้ในฐานข้อมูลของตนเองสำหรับข้อมูลเพิ่มเติมสำหรับผู้ใช้นั้น (เช่นสิทธิ์ที่อยู่ทางไปรษณีย์และอื่น ๆ ) สิ่งนี้ทำให้ JWT มีขนาดเล็กและหลีกเลี่ยงการรั่วไหลของข้อมูลโดยไม่ตั้งใจเพราะทุกคนรู้ว่าจะไม่เก็บข้อมูลที่สำคัญใน JWT

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

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

สิ่งสำคัญคือต้องเข้าใจความแตกต่างระหว่างผู้ออกและผู้ตรวจสอบ ผู้รับโทเค็นมีหน้าที่ตรวจสอบความถูกต้อง

มีสองขั้นตอนที่สำคัญในการใช้ JWT อย่างปลอดภัยในเว็บแอปพลิเคชัน: 1) ส่งพวกเขาผ่านช่องทางการเข้ารหัสและ 2) ตรวจสอบลายเซ็นทันทีที่ได้รับ ลักษณะของการเข้ารหัสคีย์สาธารณะแบบอสมมาตรทำให้สามารถตรวจสอบลายเซ็น JWT ได้ กุญแจสาธารณะตรวจสอบ JWT ได้รับการลงนามโดยคีย์ส่วนตัวที่ตรงกัน ไม่มีการรวมกันของคีย์อื่น ๆ ที่สามารถทำการตรวจสอบนี้ได้ดังนั้นจึงป้องกันความพยายามเลียนแบบ ทำตามสองขั้นตอนเหล่านี้และเราสามารถรับประกันด้วยความแน่นอนทางคณิตศาสตร์ของ JWT

อ่านเพิ่มเติม: กุญแจสาธารณะตรวจสอบลายเซ็นได้อย่างไร

เรามาจากการเริ่มต้นกันเถอะ:

JWT เป็นวิธีการที่ทันสมัยเรียบง่ายและปลอดภัยซึ่งครอบคลุมสำหรับ Json Web Tokens Json Web Tokens เป็นโซลูชั่นไร้สัญชาติสำหรับการตรวจสอบสิทธิ์ ดังนั้นไม่จำเป็นต้องเก็บสถานะเซสชันใด ๆ ไว้บนเซิร์ฟเวอร์ซึ่งแน่นอนว่าเหมาะสำหรับ API ที่สงบ Restful APIs ควรไร้สถานะเสมอและทางเลือกที่ใช้กันอย่างแพร่หลายในการรับรองความถูกต้องกับ JWT ก็คือการจัดเก็บสถานะการเข้าสู่ระบบของผู้ใช้บนเซิร์ฟเวอร์โดยใช้เซสชัน แต่แน่นอนว่าไม่เป็นไปตามหลักการที่บอกว่า API ที่สงบควรไร้สัญชาติและนั่นเป็นสาเหตุที่โซลูชันเช่น JWT ได้รับความนิยมและมีประสิทธิภาพ

ดังนั้นตอนนี้เรามาดูกันว่าการรับรองความถูกต้องใช้งานได้จริงกับ Json Web Tokens สมมติว่าเรามีผู้ใช้ที่ลงทะเบียนแล้วในฐานข้อมูลของเรา ดังนั้นลูกค้าของผู้ใช้เริ่มต้นด้วยการโพสต์คำขอด้วยชื่อผู้ใช้และรหัสผ่านแอปพลิเคชันจะตรวจสอบว่ามีผู้ใช้อยู่หรือไม่และรหัสผ่านนั้นถูกต้องแอปพลิเคชันจะสร้าง Json Web Token เฉพาะสำหรับผู้ใช้นั้น

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

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

ดังนั้นเซิร์ฟเวอร์จึงไม่รู้ว่าผู้ใช้คนใดที่เข้าสู่ระบบจริง แต่แน่นอนผู้ใช้รู้ว่าเขาเข้าสู่ระบบเพราะเขามี Json Web Token ที่ถูกต้องซึ่งเป็นเหมือนหนังสือเดินทางเพื่อเข้าถึงส่วนที่ได้รับการป้องกันของแอปพลิเคชัน

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

จากนั้นทุกครั้งที่ผู้ใช้ต้องการเข้าถึงเส้นทางที่ได้รับการป้องกันเช่นข้อมูลโปรไฟล์ผู้ใช้ของเขา เขาส่ง Json Web Token พร้อมกับคำขอไปแล้วดังนั้นจึงเป็นการแสดงพาสปอร์ตเพื่อเข้าถึงเส้นทางนั้น

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

การสื่อสารทั้งหมดนี้จะต้องเกิดขึ้นบน https ดังนั้น Http ที่เข้ารหัสจึงปลอดภัยเพื่อป้องกันไม่ให้ทุกคนสามารถเข้าถึงรหัสผ่านหรือ Json Web Tokens ได้ เท่านั้นเรามีระบบที่ปลอดภัยจริงๆ

ดังนั้น Json Web Token ดูเหมือนว่าส่วนซ้ายของภาพหน้าจอนี้ซึ่งนำมาจาก JWT ดีบักเกอร์ที่ jwt.ioSo เป็นหลักมันเป็นสตริงการเข้ารหัสที่ประกอบด้วยสามส่วน ส่วนหัว, ส่วนของข้อมูลและลายเซ็นตอนนี้ส่วนหัวเป็นเพียงข้อมูลเมตาเกี่ยวกับโทเค็นของตัวเองและส่วนของข้อมูลเป็นข้อมูลที่เราสามารถเข้ารหัสเป็นโทเค็น, ข้อมูลใด ๆ ที่เราต้องการจริงๆ ข้อมูลเพิ่มเติมที่เราต้องการเข้ารหัสที่นี่ยิ่งใหญ่ JWT อย่างไรก็ตามทั้งสองส่วนนี้เป็นเพียงข้อความธรรมดาที่จะได้รับการเข้ารหัส แต่ไม่ได้เข้ารหัส

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

และกระบวนการทั้งหมดนี้จะเรียกว่าการลงนามใน Json เว็บ Token อัลกอริทึมการเซ็นชื่อใช้ส่วนหัวเพย์โหลดและความลับในการสร้างลายเซ็นที่ไม่ซ้ำกัน เฉพาะข้อมูลนี้และความลับเท่านั้นที่สามารถสร้างลายเซ็นนี้ได้ใช่ไหม จากนั้นเมื่อรวมกับส่วนหัวและส่วนของข้อมูลแล้วลายเซ็นเหล่านี้จะสร้าง JWT ซึ่งจะถูกส่งไปยังลูกค้า

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

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

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

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

PrivateKey ของ JWT เท่านั้นซึ่งอยู่บนเซิร์ฟเวอร์ของคุณจะถอดรหัส JWT ที่เข้ารหัส ผู้ที่รู้จัก privateKey จะสามารถถอดรหัส JWT ที่เข้ารหัสได้

ซ่อน privateKey ในตำแหน่งที่ปลอดภัยในเซิร์ฟเวอร์ของคุณและอย่าบอก privateKey กับใคร

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

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

ฉันจะแนะนำในการดูเป็น JWE โดยใช้อัลกอริทึมพิเศษที่ไม่อยู่ใน jwt.io เพื่อถอดรหัส

ลิงค์อ้างอิง: https://www.npmjs.com/package/node-webtokens

jwt.generate('PBES2-HS512+A256KW', 'A256GCM', payload, pwd, (error, token) => {
  jwt.parse(token).verify(pwd, (error, parsedToken) => {
    // other statements
  });
});

คำตอบนี้อาจจะสายเกินไปหรือคุณอาจค้นพบวิธีแล้ว แต่ฉันก็รู้สึกว่ามันจะเป็นประโยชน์สำหรับคุณและคนอื่น ๆ เช่นกัน

ตัวอย่างง่ายๆที่ฉันได้สร้าง: https://github.com/hansiemithun/jwe-example