การเข้ารหัส การหลบหนี และการแฮช

การเข้ารหัสไม่ใช่การเข้ารหัส และไม่ใช่การบีบอัด

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

Base64 รับครั้งละสามไบต์และเขียนใหม่เป็นอักขระสี่ตัวที่ดึงมาจากตัวอักษรสัญลักษณ์ 64 อักขระสี่ตัวที่มีสามไบต์หมายความว่าเอาต์พุตจะมีขนาดใหญ่กว่าอินพุตประมาณ 33% บวกกับช่องว่างภายในเสมอ เกิดขึ้นเนื่องจากโครงสร้างพื้นฐานจำนวนมาก เช่น ส่วนหัวอีเมล, ส่วนหัว HTTP, ค่าสตริง JSON, URL, แอตทริบิวต์ XML ได้รับการออกแบบมาเพื่อข้อความและความเสียหาย หรือปฏิเสธไบต์ที่กำหนดเอง Base64 เป็นอะแดปเตอร์ที่ให้คุณพุชไบต์ผ่านไพพ์รูปข้อความ

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

เหตุใด btoa() จึงแตก และทั้งสองวิธีที่แตกต่างกันจึงแตก

เบราว์เซอร์ให้ btoa() และ atob() แก่คุณ และเก่ากว่า API ข้อความสมัยใหม่ btoa ถูกกำหนดไว้เหนือ "สตริงไบนารี่": สตริงที่ทุกหน่วยโค้ดมีไบต์เดียว ตั้งแต่ 0 ถึง 255 ข้อความไม่ใช่อย่างนั้น

ความล้มเหลวครั้งแรกดังมาก โทร btoa("世界") และคุณได้รับ InvalidCharacterError เนื่องจาก U+4E16 ไม่พอดีกับไบต์ ความล้มเหลวที่ดังถือเป็นสิ่งดี คุณสังเกตเห็นได้ทันทีและมองหาวิธีแก้ไข

ความล้มเหลวครั้งที่สองนั้นเงียบงัน และความล้มเหลวนั้นก็มาถึงการผลิต อักขระ é คือ U+00E9 ซึ่งมีขนาดพอดีกับไบต์ ดังนั้น btoa("cafe") จึงกลับมาอย่างมีความสุข โดยเข้ารหัส é เป็นไบต์เดียว 0xE9 แต่ é ใน UTF-8 คือสองไบต์ 0xC3 0xA9 base64 ที่คุณเพิ่งสร้างการถอดรหัส ในทุกระบบบนโลก ไปจนถึงสิ่งที่ไม่ใช่ข้อความของคุณ คุณจะพบว่าสัปดาห์ต่อมาเมื่อชื่อในฐานข้อมูลกลายเป็นอักขระทดแทน

การแก้ไขคือการหยุดถือว่าข้อความเป็นไบต์และแปลงอย่างชัดเจน TextEncoder สร้าง UTF-8 ไบต์; เข้ารหัสสิ่งเหล่านั้น TextDecoder เปลี่ยนไบต์กลับเป็นข้อความ และการสร้างมันขึ้นมาด้วย { fatal: true } ทำให้มันมีลำดับที่ไม่ถูกต้อง แทนที่จะแทนที่ U+FFFD อย่างเงียบๆ ดังนั้นการถอดรหัสที่ไม่อาจถูกต้องได้จึงล้มเหลวแทนที่จะส่งกลับเรื่องไร้สาระที่ดูน่าเชื่อถือ นั่นคือขั้นตอนที่ชุดเครื่องมือนี้ใช้ ซึ่งเป็นเหตุผลว่าทำไมอีโมจิจึงรวมเครื่องหมายและสคริปต์จากขวาไปซ้ายไป-กลับทุกประการ

1. แปลงข้อความเป็นไบต์ด้วย TextEncoder — ไม่ต้องสร้างดัชนีลงในสตริง
2. เข้ารหัสไบต์เป็น base64
3. วิธีย้อนกลับ: ถอดรหัส base64 เป็นไบต์ จากนั้นถอดรหัสไบต์เป็น UTF-8 ด้วย fatal: true
4. หากขั้นตอน UTF-8 ล้มเหลว เพย์โหลดจะเป็นไบนารี ไม่ใช่ข้อความ แสดงเป็นเลขฐานสิบหกแทนที่จะแสร้งทำเป็น

base64 กับ base64url และคำถามการเติม

มาตรฐาน base64 ใช้ + และ / เป็นสัญลักษณ์สองตัวสุดท้าย ทั้งสองมีความหมายใน URL: + สามารถอ่านเป็นพื้นที่เข้ารหัสในสตริงการสืบค้น และ / เป็นตัวคั่นเส้นทาง ดังนั้น RFC 4648 กำหนดตัวอักษรตัวที่สอง base64url ซึ่งใช้แทน - และ _ แทน JWT ใช้มัน เช่นเดียวกับรูปแบบโทเค็นส่วนใหญ่และ API จำนวนมาก

ช่องว่างภายในเป็นอีกตัวแปรหนึ่ง แผ่น base64 มาตรฐานที่มี = ดังนั้นความยาวเอาต์พุตจะเป็นผลคูณของสี่เสมอ base64url มักจะลดช่องว่างภายใน เนื่องจาก = เป็นอักขระที่น่าอึดอัดใจใน URL และสามารถกู้คืนความยาวได้ทางคณิตศาสตร์ ตัวถอดรหัสที่ยืนยันในการเติมจะปฏิเสธเซ็กเมนต์ JWT ที่ถูกต้องสมบูรณ์

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

encodeURI และ encodeURIComponent: ความแตกต่างในประโยคเดียว

เข้ารหัสทั้งเปอร์เซ็นต์โดยใช้ UTF-8 พวกเขาต่างกันแค่ว่าตัวละครตัวไหนที่พวกเขาปล่อยให้อยู่คนเดียว และความแตกต่างนั้นก็คือเรื่องราวทั้งหมด: encodeURIComponent จะหลีกหนีจากตัวคั่นที่สงวนไว้ แต่ encodeURI จะไม่หนี

ตัวคั่นที่สงวนไว้คืออักขระที่ให้ URL โครงสร้าง: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. encodeURI ถือว่าคุณมอบ URL ให้กับมันซึ่งมีโครงสร้างที่ถูกต้องอยู่แล้วและจะต้องคงไว้เช่นนั้น ดังนั้นจึงรักษาสิ่งเหล่านั้นไว้ — มันจะไม่เปลี่ยน https:// ให้เป็น https%3A%2F%2F encodeURIComponent ถือว่าคุณได้มอบชิ้นส่วนนั้นให้กับมันหนึ่งชิ้นที่จะหล่นลงในช่อง ดังนั้นมันจึงหลบหนีออกไป เพื่อให้แน่ใจว่าชิ้นส่วนนั้นจะไม่หลุดออกจากช่อง

แมลงที่เกิดนี้เป็นกลไกโดยสมบูรณ์ ใช้ค่าค้นหา a&b=c เข้ารหัสด้วย encodeURI และต่อท้ายเป็น ?q=a&b=c และคุณได้สร้างพารามิเตอร์สองตัวขึ้นมาอย่างเงียบๆ: ตอนนี้ q เป็นเพียง "a" และ b=c ที่หลงทางปรากฏขึ้น เข้ารหัสด้วย encodeURIComponent แล้วคุณจะได้รับ ?q=a%26b%3Dc หนึ่งพารามิเตอร์ ค่าที่ถูกต้อง ข้อผิดพลาดระดับเดียวกันทำให้ค่าที่สร้างขึ้นสามารถแทรกพารามิเตอร์ลงใน URL โค้ดที่คุณสร้างได้ ซึ่งเป็นเหตุผลว่าทำไม "การใช้แบบฟอร์มส่วนประกอบสำหรับค่า" จึงเป็นกฎความปลอดภัย ไม่ใช่แค่กฎความถูกต้อง

การเข้ารหัสแบบฟอร์มเป็นกฎข้อที่สามที่มีลักษณะเหมือนกฎข้อที่สอง application/x-www-form-urlencoded เขียนช่องว่างเป็น + แทนที่จะเป็น %20 หากคุณถอดรหัสเนื้อหาของฟอร์มด้วย decodeURIComponent ธรรมดา เครื่องหมายบวกทุกตัวในข้อมูลจะกลายเป็นช่องว่าง ทุกช่องค้นหาที่เคยรวม "C++" ลงใน "C" คือจุดบกพร่องนี้

HTML เอนทิตี และเหตุใดการถอดรหัสด้วย innerHTML จึงเป็นนิสัยที่ไม่ดี

การ Escape สำหรับ HTML นั้นแคบและเข้าใจดี: & กลายเป็น &amp;, < กลายเป็น &lt;, > กลายเป็น &gt; และค่าแอตทริบิวต์ภายใน " และ ' จำเป็นต้อง Escape ด้วย อักขระห้าตัว การ Escape มากกว่านั้น - การเปลี่ยนตัวอักษรเน้นเสียงทุกตัวให้เป็นเอนทิตีที่มีชื่อ - เป็นวิธีการแก้ปัญหาสำหรับวันที่การเข้ารหัสอักขระไม่แน่นอน และตอนนี้เป็นรูปแบบที่เป็นทางเลือกแทน มากกว่าความปลอดภัย

การถอดรหัสคือที่ที่นิสัยไม่ดีอาศัยอยู่ เคล็ดลับบรรทัดเดียวที่ปรากฏในทุกคำตอบคือการกำหนดสตริงให้กับ innerHTML ขององค์ประกอบที่แยกออก และอ่านเนื้อหาข้อความกลับ มันใช้งานได้และเป็นความคิดที่ไม่ดี คุณได้ส่งข้อมูลที่ไม่น่าเชื่อถือให้กับตัวแยกวิเคราะห์ HTML ซึ่งสร้างโหนด DOM จริงจากตัวแยกวิเคราะห์ <img src=x onerror=...> ในสตริงนั้นจะกลายเป็นองค์ประกอบรูปภาพจริงโดยมีตัวจัดการข้อผิดพลาดแนบมาด้วย หากทรีย่อยนั้นถูกแทรกลงในเอกสาร มันจะทำงาน นอกจากนี้ยังทำลายข้อมูลของคุณโดยไม่แจ้งให้ทราบ แท็กในอินพุตจะหายไปแทนที่จะวนซ้ำ เนื่องจาก parser ตีความว่าเป็นมาร์กอัปแทนที่จะเป็นข้อความ

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

การเลือกแฮชและคำถามสามข้อที่ตัดสินใจ

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

คำถามแรก: คุณกำลังป้องกันอุบัติเหตุหรือศัตรูหรือไม่? การตรวจสอบการป้องกันการดาวน์โหลดที่เสียหายจะต้องตรวจจับการพลิกแบบสุ่มเท่านั้น CRC32 ไม่เป็นไร สรุปว่าผู้โจมตีอาจได้รับประโยชน์จากการชนกันนั้นจำเป็นต้องมีแฮชที่ยังคงอยู่ ความแตกต่างนั้นคือสาเหตุที่ SHA-1 ไม่ใช่แค่ "เก่า"

SHA-1 เสียหายอย่างเป็นรูปธรรม ใน 2017 งาน SHAttered ได้สร้างไฟล์ PDF สองไฟล์ที่แตกต่างกันโดยมี SHA-1 แยกย่อยเหมือนกัน ใน 2020 "SHA-1 is a Shambles" แสดงให้เห็นถึงการชนกันของคำนำหน้าที่เลือก ซึ่งเป็นรูปแบบที่รุนแรงกว่าและอันตรายกว่ามาก เพราะมันทำให้ผู้โจมตีสามารถชนเอกสารสองฉบับที่แตกต่างกันอย่างมีความหมาย แทนที่จะเป็นสอง Blob ที่สร้างขึ้นอย่างระมัดระวัง หากการรักษาความปลอดภัยของระบบขึ้นอยู่กับความต้านทานการชนกัน SHA-1 การรักษาความปลอดภัยนั้นก็จะหมดไป SHA-1 ยังคงอยู่ในชุดเครื่องมือนี้ เนื่องจากรหัสอ็อบเจ็กต์ git และลายเซ็น API แบบยาวส่วนท้ายยังคงใช้งานอยู่ และคุณจะต้องสามารถทำซ้ำค่าเหล่านั้นได้ การสร้างค่าซ้ำนั้นไม่เหมือนกับการพึ่งพาค่านั้น

คำถามที่สอง: การป้อนข้อมูลเป็นรหัสผ่านหรือไม่ ถ้าใช่ สิ่งเหล่านี้ไม่ใช่คำตอบ SHA-256 ได้รับการออกแบบมาให้รวดเร็ว และความรวดเร็วนั้นผิดอย่างชัดเจนสำหรับรหัสผ่าน นั่นหมายความว่าผู้โจมตีที่มีฐานข้อมูลของคุณสามารถลองเดาได้หลายพันล้านครั้งต่อวินาที รหัสผ่านต้องมีฟังก์ชันที่ช้าและหน่วยความจำยากโดยเจตนา พร้อมด้วยเกลือต่อผู้ใช้ — Argon2id, scrypt หรือ bcrypt นี่ไม่ใช่ความแตกต่างกันนิดหน่อย การใช้ SHA-256 สำหรับรหัสผ่านถือเป็นข้อผิดพลาดในการแฮชที่ร้ายแรงที่สุดเพียงครั้งเดียว

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

สำหรับทุกสิ่งทุกอย่าง เช่น การพิมพ์ลายนิ้วมือไฟล์ ที่อยู่เนื้อหา คุณลักษณะความสมบูรณ์ SHA-256 เป็นค่าเริ่มต้นที่สมเหตุสมผล และ SHA-512 มักจะเร็วกว่าบนฮาร์ดแวร์ 64 บิตในขณะที่ให้รายละเอียดที่กว้างขึ้น

เหตุใดแฮชจึงมาจากเบราว์เซอร์

ข้อมูลสรุปในชุดเครื่องมือนี้คำนวณโดย SubtleCrypto ซึ่งเป็นการใช้งาน Web Crypto ของเบราว์เซอร์ ไม่ใช่โดย JavaScript ที่จัดส่งจากไซต์นี้ นั่นเป็นการตัดสินใจโดยเจตนา: การใช้งานเบราว์เซอร์ได้รับการตรวจสอบ ดูแลรักษา และโดยปกติจะทำงานเป็นโค้ดเนทีฟที่ได้รับการปรับปรุง SHA-256 ที่เขียนด้วยลายมือในชุดเพจเป็นโค้ดที่น่าเชื่อถือได้มากขึ้นโดยไม่เกิดประโยชน์ใดๆ

มันมีผลที่มองเห็นได้ประการหนึ่ง Web Crypto จะถูกเปิดเผยในบริบทที่ปลอดภัยเท่านั้น ซึ่งหมายถึง https:// หรือ localhost เปิดหน้านี้บน HTTP แบบธรรมดาบนที่อยู่ LAN และ crypto.subtle จะไม่ถูกกำหนด ดังนั้นยูทิลิตี้แฮชจะบอกคุณอย่างชัดเจน แทนที่จะล้มเหลวอย่างเงียบๆ หรือทดแทนบางสิ่งที่อ่อนแอกว่า

เหตุผลเดียวกันนี้ขับเคลื่อนตัวสร้าง UUID crypto.randomUUID() ยังเป็นบริบทที่ปลอดภัยเท่านั้น ดังนั้นในกรณีที่ไม่พร้อมใช้งาน ชุดเครื่องมือจะกลับไปเป็น crypto.getRandomValues() — ซึ่งยังคงเป็นแหล่งที่มาที่ปลอดภัยด้วยการเข้ารหัสเดียวกัน — และตั้งค่าเวอร์ชันและบิตตัวแปรด้วยตัวมันเอง สิ่งที่มันจะไม่มีวันทำคือถอยกลับไปที่ Math.random() นั่นคือ PRNG ที่ไม่ใช่การเข้ารหัสที่รวดเร็ว ซึ่งสถานะภายในสามารถกู้คืนได้จากเอาต์พุตระยะสั้น และตัวระบุมีพฤติกรรมที่โชคร้ายของการเลื่อนระดับเป็นคีย์เซสชันและลิงก์รีเซ็ตรหัสผ่าน หากไม่มีแหล่งที่มาที่ปลอดภัย เครื่องมือนี้จะไม่สร้างอะไรเลยและบอกว่าทำไม

จะเกิดอะไรขึ้นกับสิ่งที่คุณวาง

• ทุกการแปลง แฮช ถอดรหัส และส่วนต่างจะทำงานในแท็บเบราว์เซอร์ของคุณ ไม่มีการอัปโหลด บันทึก หรือจัดเก็บอินพุตบนเซิร์ฟเวอร์ เนื่องจากไม่มีเซิร์ฟเวอร์ที่เกี่ยวข้องเมื่อโหลดเพจแล้ว
• แฮชมาจากการใช้งาน Web Crypto ของเบราว์เซอร์เอง และ UUID จากตัวสร้างแบบสุ่มที่ปลอดภัยด้วยการเข้ารหัส ไม่เกี่ยวข้องกับการโทรผ่านเครือข่าย
• ไม่มีสิ่งใดที่คุณพิมพ์ถูกเขียนลงในที่จัดเก็บในตัวเครื่องหรือคุกกี้ การโหลดหน้าซ้ำจะทิ้งหน้านั้นไป การปิดแท็บจะทิ้งมันไป
• การวิเคราะห์ทั่วทั้งไซต์ทำงานบนโฮสต์การผลิตตามรูปแบบบัญญัติที่กำหนดค่าไว้เท่านั้น และได้รับการเปิดเผยในนโยบายความเป็นส่วนตัว โฮสต์ในท้องถิ่นและโฮสต์ตัวอย่างปฏิเสธ ค่าที่วาง โทเค็น URL และเนื้อหาไฟล์จะไม่รวมอยู่ในเหตุการณ์การวิเคราะห์ของ ToolAcre เอง การโฆษณาถูกปิดใช้งานในการกำหนดค่าปัจจุบัน
• ที่กล่าวว่า: คีย์ JWT หรือ API เป็นข้อมูลประจำตัวที่ใช้งานอยู่ นิสัยที่ปลอดภัยคืออย่าวางสิ่งใดสิ่งหนึ่งลงในหน้าเว็บที่คุณไม่ได้เขียน ไม่ว่าคำกล่าวอ้างนั้นจะน่าเชื่อถือเพียงใด รวมถึงหน้านี้ด้วย

คำถาม

ข้อจำกัด

• ตารางเอนทิตีที่มีชื่อ HTML ครอบคลุมชุดย่อยที่ใช้งานจริง — อักขระที่มีความสำคัญอย่างยิ่งต่อมาร์กอัป การพิมพ์ สกุลเงิน ลูกศร คณิตศาสตร์ กรีกและละติน-1 — ไม่ใช่การอ้างอิงที่มีชื่อ 2,231 HTML5 ทั้งหมด ชื่อที่ไม่รู้จักจะถูกรายงานและทิ้งไว้ตามที่เขียนไว้แทนที่จะเดา
• การถอดรหัสเอนทิตีต้องใช้เครื่องหมายอัฒภาคที่สิ้นสุด HTML5 ยอมรับการอ้างอิงแบบเดิมจำนวนหนึ่งโดยไม่มีการอ้างอิง แต่การถอดรหัสอย่างถูกต้องนั้นขึ้นอยู่กับบริบทของมาร์กอัปโดยรอบ ซึ่งเครื่องมือข้อความแบบสแตนด์อโลนไม่มี
• การแฮชและการสร้าง UUID จำเป็นต้องมีบริบทที่ปลอดภัย (https:// หรือ localhost) เนื่องจาก Web Crypto จะไม่ถูกเปิดเผยเป็นอย่างอื่น เครื่องมือจะรายงานสิ่งนี้แทนที่จะแทนที่การใช้งานที่อ่อนแอกว่า
• มีเพียง SHA-1, SHA-256, SHA-384 และ SHA-512 เท่านั้นที่พร้อมใช้งาน เพราะสิ่งเหล่านี้คือสิ่งที่ SubtleCrypto นำไปใช้ MD5 ขาดทั้งทางเลือกและความจำเป็น
• ไม่มี HMAC ไม่มีการสืบทอดคีย์ และไม่มีการเข้ารหัสที่นี่ สิ่งเหล่านี้จำเป็นต้องมีการจัดการคีย์ ซึ่งไม่ใช่สิ่งที่เพจที่คุณพบบนอินเทอร์เน็ตควรจัดการ
• ทุกอย่างถูกจำกัดด้วยหน่วยความจำของอุปกรณ์ของคุณ เนื่องจากทุกอย่างทำงานในแท็บเบราว์เซอร์เดียว อินพุตถูกจำกัด — ไม่กี่เมกะไบต์ต่อยูทิลิตี้ — และเครื่องมือปฏิเสธงานขนาดใหญ่แทนที่จะค้าง