QR Code ของ Google Authenticator ทำงานอย่างไร: จากสตริงถึง Secret

QR Code ของ Google Authenticator มีอะไรจริงๆ?

หลายคนสันนิษฐานว่า QR code เก็บความลับที่เข้ารหัสหรือภาพไบนารี ความจริงนั้นง่ายและน่าสนใจกว่า: QR code ของ Google Authenticator มี URL ข้อความธรรมดาเท่านั้น

เมื่อคุณส่งออกบัญชี Google จะสร้าง URL ที่มีลักษณะดังนี้:

หากคุณสแกนนี่ด้วยสแกนเนอร์ QR code ธรรมดา (ไม่ใช่ Authenticator) คุณจะเห็นสตริงนี้อย่างแม่นยำ ไม่มีอะไรซ่อน ไม่มีรูปภาพ ไม่มีชั้นการเข้ารหัส

การแยกวิเคราะห์โครงสร้าง URL

URL นี้เป็นไปตาม มาตรฐาน RFC สำหรับ TOTP เช่นเดียวกับ URL ใดๆ มี 3 ส่วน:

• Scheme: otpauth-migration:// ระบุว่านี่คือ URL การย้ายข้อมูล OTP
• Path: offline ระบุว่าข้อมูลเป็นอิสระ (ไม่ได้ดึงจากเซิร์ฟเวอร์)
• Parameter: data=... มีข้อมูลบัญชีที่เข้ารหัสทั้งหมด

การใช้งานจริงเกิดขึ้นในพารามิเตอร์ data ซึ่งต้องมีขั้นตอนการถอดรหัสหลายขั้นตอน

การถอดรหัส: จาก URL สู่ Secret

การทำความเข้าใจวิธีการเข้ารหัสข้อมูลเป็นสิ่งสำคัญสำหรับความปลอดภัยและความเป็นส่วนตัว มาเดินทางผ่านแต่ละขั้นตอน

ขั้นตอนที่ 1: ถอดรหัส URL

URL มีอักขระที่สงวนไว้ซึ่งไม่สามารถปรากฏได้โดยตรง อักขระพิเศษถูกแทนที่ด้วยลำดับหนีเช่น %2F สำหรับ "/" หรือ %3D สำหรับ "="

หลังจากถอดรหัส URL คุณจะได้สตริง Base64 มาตรฐานพร้อมสำหรับขั้นตอนถัดไป

ขั้นตอนที่ 2: ถอดรหัส Base64

Base64 มักถูกสับสนกับการเข้ารหัส ไม่ใช่ Base64 ไม่ใช่การเข้ารหัส มันเป็นรูปแบบการเข้ารหัสเท่านั้นที่แสดงข้อมูลไบนารีเป็นข้อความโดยใช้ 64 อักขระที่ปลอดภัย (A-Z, a-z, 0-9, +, /)

เมื่อคุณถอดรหัส Base64 ด้วยข้อมูล Google Authenticator คุณจะไม่ได้รับข้อความที่อ่านได้ แต่คุณจะได้ข้อมูลไบนารี:

ไบนารีนี้ไม่ได้เข้ารหัส มันเป็นข้อมูลในรูปแบบอื่น ใครก็ได้สามารถถอดรหัสได้ ด้วยเหตุนี้ คุณไม่ควรแชร์ QR code ที่ส่งออก และคุณควรเก็บรหัสการกู้คืนให้ปลอดภัย

ขั้นตอนที่ 3: การแยกวิเคราะห์ Protocol Buffers

นี่คือจุดที่โครงสร้างปรากฏ Google ใช้ Protocol Buffers (protobuf) เพื่อทำให้ข้อมูลที่ส่งออกอยู่ในรูปแบบอนุกรม

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

สคีมาสำหรับการส่งออก Google Authenticator มีลักษณะดังนี้:

message OtpParameters {
    bytes secret = 1;
    string name = 2;
    string issuer = 3;
    Algorithm algorithm = 4;
    DigitCount digits = 5;
    OtpType type = 6;
}

โดยใช้สคีมานี้ protobuf parser รู้ว่าฟิลด์ 1 มี secret, ฟิลด์ 2 มีชื่อบัญชี เป็นต้น จากนั้น parser จะสร้างข้อมูลที่มีโครงสร้างใหม่

ข้อมูลที่ถอดรหัสมีอะไร

หลังจากแยกวิเคราะห์ protobuf คุณจะมีวัตถุที่มีโครงสร้างพร้อม:

• ชื่อบัญชี: example@example.com
• ผู้ออกแบบ: Example (ชื่อบริการ)
• Secret: ข้อมูลไบนารี (24 63 9B AA D6 CC CF D5...)
• อัลกอริทึม: SHA1 หรือ SHA256
• ตัวเลข: มักจะ 6 (ความยาวรหัส OTP)
• ประเภท: TOTP (ตามเวลา) หรือ HOTP (ตามตัวนับ)

นี่คือสิ่งที่ Authenticator ต้องการในการสร้างรหัสเพียงครั้งเดียว secret ไบนารีคือแกน มันคือสิ่งที่ทำให้รหัส 6 หลักแต่ละตัวมีเอกลักษณ์และอิงตามเวลา

ทำไม Base32? Secret ที่อ่านได้สำหรับมนุษย์

secret ภายใน protobuf คือข้อมูลไบนารีดิบ สำหรับผู้คน ข้อมูลไบนารีนั้นไม่สะดวก นี่คือเหตุผลที่รหัสการกู้คืนและช่องการป้อนข้อมูลด้วยตนเองใช้การเข้ารหัส Base32

Base32 แปลงข้อมูลไบนารีเดียวกันให้เป็นข้อความที่อ่านได้โดยใช้ 32 อักขระ (A-Z และ 2-7) ตัวอย่างเช่น:

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

นัยทางความปลอดภัย: ทำไมสิ่งนี้จึงสำคัญสำหรับความเป็นส่วนตัว

การทำความเข้าใจวิธีการทำงานของ QR code มีความสำคัญอย่างยิ่งสำหรับ วิศวกรรมความเป็นส่วนตัว ข้อมูลเชิงลึกหลัก: ไม่มีการเข้ารหัสในระดับ QR

• QR code ไม่ได้เข้ารหัส: ใครก็ได้ที่มี QR code ของคุณสามารถถอดรหัสและแยก TOTP secret ของคุณได้ ปฏิบัติต่อ QR code ที่ส่งออกด้วยความระมัดระวังเดียวกับที่คุณจะปฏิบัติต่อ secret เอง
• การขนส่งสำคัญ: หากคุณส่ง QR code ทางอีเมลหรือทำภาพหน้าจอ คุณกำลังส่งข้อมูล secret ที่ไม่ได้เข้ารหัส ใช้ช่องทางที่ปลอดภัย (การแชทที่เข้ารหัส, การถ่ายโอนลงมือ) หากคุณต้องแชร์รหัสการกู้คืน
• ภาพหน้าจอเป็นแบบถาวร: ไม่เหมือนการดู QR code บนหน้าจอ ภาพหน้าจอสามารถสร้างสำเนา, ซิงโครไนซ์กับคลาวด์ หรือกู้คืนจากพื้นที่จัดเก็บข้อมูลของอุปกรณ์ ใช้งานการบล็อกภาพหน้าจอหากเป็นไปได้
• สำเนา Base32 มีความไวเท่ากัน: รหัสสำเนา Base32 เป็นเพียงการแสดง secret เดียวกันแบบอื่น ปกป้องมันในลักษณะเดียวกับที่คุณปกป้อง QR code

กระบวนการแปลงที่สมบูรณ์

นี่คือการเดินทางแบบเต็มจาก QR code สู่ secret ที่ใช้ได้:

QR Code (รูปภาพ)
    ↓
otpauth-migration://offline?data=...
    ↓
ถอดรหัส URL
    ↓
ถอดรหัส Base64
    ↓
ข้อมูลไบนารี (0A 3E 0A 14...)
    ↓
แยกวิเคราะห์ Protocol Buffers
    ↓
ข้อมูลที่มีโครงสร้าง:
  - Secret (ไบนารี)
  - ชื่อบัญชี
  - ผู้ออกแบบ
  - อัลกอริทึม
  - ตัวเลข
    ↓
เข้ารหัส Base32 (ไม่บังคับ)
    ↓
ERRZXKWWZTH5K6U6KGR3LRK5UQMP3SXH

ทุกขั้นตอนสามารถย้อนกลับได้และไม่ได้เข้ารหัส การป้องกันเพียงอย่างเดียวคือความสวยงามและการปฏิบัติเก็บข้อมูลที่เหมาะสม

ทำไมความรู้นี้จึงสำคัญ

การทำความเข้าใจกลไกของ QR code ช่วยให้คุณ:

• ตัดสินใจด้านความปลอดภัยโดยที่มีข้อมูล: รู้ว่า QR code ไม่ได้เข้ารหัส เพื่อให้คุณปฏิบัติต่อมันอย่างเหมาะสม
• เก็บข้อมูลสำเนาปลอดภัย: เข้าใจว่าเหตุใดคุณจึงไม่ควรทำภาพหน้าจอ QR code หรือส่งอีเมลให้ไม่ได้เข้ารหัส
• ปฏิบัติการย้ายข้อมูลอย่างเหมาะสม: เมื่อเพิ่ม 2FA บนอุปกรณ์ใหม่ ให้ใช้ช่องทางที่ปลอดภัยและตรวจสอบรหัสก่อนลบรหัสเก่า
• ตรวจสอบเครื่องมือของบุคคลที่สาม: หากคุณใช้เครื่องมือสำเนาหรือการย้ายข้อมูล คุณจะรู้ว่าต้องถาม: พวกเขาถอดรหัส protobuf ในเครื่อง หรือพวกเขาส่งไปยังเซิร์ฟเวอร์ของพวกเขา?

สรุป

QR code ของ Google Authenticator มีความสง่างาม แต่ไม่ได้เข้ารหัส พวกเขามี URL ข้อความที่มีข้อมูล protobuf ที่เข้ารหัส โดยการถอดรหัส URL, Base64 และ protobuf คุณสามารถกู้คืนข้อมูลทั้งหมดที่จำเป็นในการกู้คืน 2FA

นี่คือเหตุผลที่ QR code ส่งออกตัวเดียวเพียงพอที่จะย้ายไปยังอุปกรณ์อื่น และเหตุใดคุณควรปฏิบัติต่อรหัสส่งออกด้วยความระมัดระวังเดียวกับที่คุณจะปฏิบัติต่อ secret เอง สำหรับ องค์กรที่ใช้ความปลอดภัย การทำความเข้าใจชั้นเหล่านี้จำเป็นต่อการสร้างวัฒนธรรมการปฏิบัติตนของ 2FA ที่เหมาะสม

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