ความปลอดภัย

วิธีการสร้างห้องนิรภัย และสิ่งที่จะพบหากมีการบุกรุก

อัปเดตล่าสุด 21 กันยายน 2026 · AssuredAuth โดย CircleRoll LLC

นี่คือคำอธิบายสาธารณะเกี่ยวกับวิธีการที่ AssuredAuth ปกป้องความลับของการยืนยันตัวตนสองขั้นตอน รหัสผ่าน และบัตรที่คุณเก็บไว้ในนั้น คำอธิบายนี้เขียนขึ้นเพื่อให้ผู้อ่านที่ใส่ใจเรื่องความปลอดภัยสามารถตรวจสอบข้อกล่าวอ้างทั้งหมดกับแอปและกับเวกเตอร์ทดสอบที่เผยแพร่ (สามารถขอได้จากผู้ตรวจสอบทุกคนที่ hello@assuredauth.com) คำอธิบายนี้บอกเฉพาะความจริงและไม่มีอะไรมากไปกว่านั้น: ไม่มีสิ่งใดในที่นี้อ้างว่าปลอดภัยจากการโจมตี และไม่มีการรับประกันใดๆ เป็นเปอร์เซ็นต์

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

แจ้งปัญหา: hello@assuredauth.com. ดูหัวข้อ "การรายงานจุดอ่อน" ในตอนท้าย

1. สิ่งใดถูกเข้ารหัส และเข้ารหัสด้วยอะไร

ข้อมูล	บนโทรศัพท์	คีย์
รหัสลับสองปัจจัย (รหัสลับ TOTP/HOTP/Steam)	บนโทรศัพท์Keychain (iOS) / Android ร้านค้าที่ได้รับการสนับสนุนจาก Keystore	คีย์คีย์ที่ผูกติดกับฮาร์ดแวร์ของแพลตฟอร์มนั้น แถวในฐานข้อมูลจะเก็บเพียงข้อมูลอ้างอิง (secretRef) เท่านั้น ไม่ใช่ค่าเริ่มต้น (seed)
รหัสผ่าน (ค่ารหัสผ่าน, หมายเหตุ)	บนโทรศัพท์แถวที่ปิดผนึก: AES-256-GCM, ค่าสุ่ม 96 บิตต่อค่า	คีย์คีย์ข้อมูลแบบสุ่ม 256 บิต ซึ่งถูกห่อหุ้มด้วยคีย์ฮาร์ดแวร์ใน §2
ข้อมูลบัตร (หมายเลขบัตร วันหมดอายุ ชื่อบนบัตร รหัส CVC)	บนโทรศัพท์ตราสัญลักษณ์เดียวกับรหัสผ่าน โดย CVC เป็นตัวเลือกเสริมและจะถูกจัดเก็บก็ต่อเมื่อคุณป้อนเท่านั้น	คีย์คีย์ข้อมูลเดียวกัน
ข้อมูลเมตา (ชื่อบริการ ชื่อผู้ใช้ ไอคอน ลำดับการจัดเรียง)	บนโทรศัพท์ฐานข้อมูลของแอป (SwiftData / Room)	คีย์ได้รับการปกป้องโดยการเข้ารหัสไฟล์ของระบบปฏิบัติการ จึงถือว่าเป็นข้อมูลที่ไม่เป็นความลับ
ไฟล์สำรองข้อมูล (.authbackup)	บนโทรศัพท์ไม่ว่าจะเก็บไว้ที่ไหน: ไฟล์, iCloud Drive, Google Drive, โฟลเดอร์ข้อมูลแอป หรือแผ่นแชร์	คีย์คีย์ที่ได้มาจากรหัสผ่านของคุณ (§3) Apple และ Google จะได้รับไฟล์ที่ปิดผนึกแล้วเท่านั้น ไม่มีสิ่งอื่นใดอีก
แอปคู่บน Watch / Wear	บนโทรศัพท์พวงกุญแจของนาฬิกาเอง / การตั้งค่าร่วมที่เข้ารหัส	คีย์คีย์ของแพลตฟอร์มนาฬิกาจะถูกส่งผ่านช่องทางการเชื่อมต่ออุปกรณ์ที่จับคู่แล้วของแพลตฟอร์ม
การรับส่งข้อมูลผ่านส่วนขยายเดสก์ท็อป (รหัสใช้ครั้งเดียวเมื่อร้องขอ)	บนโทรศัพท์ไม่ได้จัดเก็บไว้ แต่ส่งต่อในรูปแบบซองจดหมายเข้ารหัสแบบ end-to-end	คีย์คีย์คู่ X25519 ต่อการจับคู่หนึ่งครั้ง คีย์ส่วนตัวอยู่ใน Keychain / Keystore; ตัวรีเลย์จะเห็นเฉพาะข้อความที่เข้ารหัสแล้วเท่านั้น

ระบบวินิจฉัยไม่มีเมธอดใดที่รับค่าลับ เหตุการณ์วิเคราะห์ใดๆ ก็ไม่มีฟิลด์เก็บข้อมูลลับ และไม่มีค่าใดๆ จากที่เก็บข้อมูลลับถูกเขียนลงในบันทึกในทุกบิลด์

2. ตำแหน่งที่เก็บคีย์บนแต่ละแพลตฟอร์ม

iOS. คีย์ข้อมูลถูกห่อหุ้มด้วยคีย์ที่สร้างขึ้นภายใน Secure Enclave (kSecAttrTokenIDSecureEnclave) ด้วยการควบคุมการเข้าถึง .privateKeyUsage + .userPresence และการเข้าถึง …ThisDeviceOnly ในกลุ่มการเข้าถึง Keychain ที่ใช้ร่วมกันของแอป เพื่อให้ส่วนขยาย AutoFill สามารถใช้คีย์เดียวกันได้ คีย์ส่วนตัวไม่สามารถอ่านออกจาก Enclave ได้โดยแอป การสำรองข้อมูล หรือดีบักเกอร์ Enclave จะยินยอมให้ใช้คีย์ก็ต่อเมื่อผู้ใช้ปรากฏอยู่เท่านั้น (Face ID, Touch ID หรือรหัสผ่านของอุปกรณ์) ThisDeviceOnly หมายความว่าการสำรองข้อมูล iCloud หรือ iTunes ของโทรศัพท์จะไม่มีคีย์ โทรศัพท์ที่กู้คืนจะเริ่มต้นด้วย Vault ที่ว่างเปล่าและขอไฟล์สำรองข้อมูลและรหัสผ่านของคุณ โทรศัพท์ที่ไม่มีรหัสผ่านไม่สามารถล็อกคีย์ .userPresence ได้ (Enclave ปฏิเสธที่จะสร้างคีย์ดังกล่าว) และโปรแกรมจำลองก็ใช้เส้นทางเดียวกันตามที่ออกแบบไว้ (ข้อความแจ้งเตือนสถานะการใช้งานเป็นเพียงข้อความแจ้งเตือนที่ไม่มีการทดสอบใดสามารถตอบได้) ในโปรแกรมจำลองนั้น คีย์ข้อมูลเป็นเพียงรายการ Keychain ของอุปกรณ์เท่านั้น ซึ่งยังคงอยู่นอกเหนือการสำรองข้อมูลทุกครั้ง ยังคงอ่านไม่ได้ในขณะที่โทรศัพท์ถูกล็อก แต่ไม่มีข้อความแจ้งเตือนครั้งที่สอง และหน้าจอความปลอดภัยก็ระบุเช่นนั้นและแนะนำให้ตั้งรหัสผ่าน

Android. คีย์ข้อมูลถูกห่อหุ้มด้วยคีย์ AES-256 จาก AndroidKeyStore ซึ่งสร้างขึ้นใน StrongBox เมื่ออุปกรณ์มี (มิฉะนั้นจะใช้ TEE) โดยตั้งค่า setUserAuthenticationRequired(true) และกำหนดระยะเวลาการตรวจสอบสิทธิ์ 30 วินาทีหลังจากใช้ไบโอเมตริกหรือข้อมูลประจำตัวอุปกรณ์ ตั้งค่า setUnlockedDeviceRequired(true) และ setInvalidatedByBiometricEnrollment(true) ไว้ แฟล็กสุดท้ายนี้เป็นเพียงการตั้งค่าเพื่อความถูกต้อง ไม่ใช่เพื่อใช้งานจริง: Android จะใช้แฟล็กนี้เฉพาะกับคีย์ที่ต้องการไบโอเมตริกทุกครั้งที่ใช้งาน ดังนั้นในคีย์ 30 วินาทีนี้ที่อนุญาตให้ใช้ข้อมูลประจำตัวอุปกรณ์ แฟล็กนี้จึงไม่เปลี่ยนแปลงอะไร — สิ่งที่ป้องกันไม่ให้คนแปลกหน้าเข้าถึงได้คือการลงทะเบียนต้องใช้ PIN และการปลดล็อกหน้าจอจะทำให้คีย์นั้นใช้การไม่ได้อย่างถาวร คีย์ Keystore ไม่สามารถส่งออกได้และไม่รวมอยู่ในการสำรองข้อมูลบนคลาวด์ของ Android โดเมนที่แอปตั้งชื่อในมุมมองของตัวเอง (webDomain) จะเชื่อถือได้เฉพาะจากเบราว์เซอร์ที่รู้จักเท่านั้น จากแพ็กเกจอื่นๆ จะต้องเป็นแพ็กเกจที่ระบบได้ตรวจสอบแล้ว (ลิงก์สินทรัพย์ดิจิทัล) เนื่องจากแอปใดๆ ก็สามารถอ้างสิทธิ์ในโดเมนใดก็ได้

นี่หมายความว่าอย่างไรสำหรับไฟล์ฐานข้อมูลที่ถูกขโมยไป ไฟล์ SQLite และแถวที่ถูกผนึกไว้เป็นข้อความเข้ารหัส กุญแจที่ใช้เปิดไฟล์นั้นอยู่ในฮาร์ดแวร์รักษาความปลอดภัยบนโทรศัพท์ที่ส่งไฟล์มา และไม่สามารถคัดลอกไปพร้อมกับไฟล์ได้ ไม่มีอะไรให้เดาได้แบบออฟไลน์: กุญแจข้อมูลเป็นแบบสุ่ม ไม่ได้มาจากสิ่งที่บุคคลใดบุคคลหนึ่งเลือก

3. ไฟล์สำรองข้อมูล

การสำรองข้อมูลเป็นสิ่งเดียวที่ออกจากโทรศัพท์ ดังนั้นจึงเป็นจุดเดียวที่การโจมตีแบบออฟไลน์เป็นไปได้ในทางทฤษฎี การออกแบบทำให้การโจมตีดังกล่าวมีค่าใช้จ่ายสูงและลดโอกาสในการโจมตีให้น้อยที่สุดเท่าที่จะเป็นไปได้:

• วลีรหัสผ่านมีความยาวอย่างน้อย 12 ตัวอักษร (หน้าต่างจะไม่รับที่สั้นกว่านั้น และแสดงแถบระดับความแข็งแรง)
• ไม่มีการจัดเก็บคำใบ้รหัสผ่านไว้ที่ใดเลย ทั้งในไฟล์หรือในแอปพลิเคชัน
• มีการสร้างค่า salt แบบสุ่มใหม่ขนาด 16 ไบต์ และค่า nonce ขนาด 12 ไบต์ สำหรับไฟล์ทุกไฟล์ที่เขียน
• ตัวเข้ารหัสทั้งหมดใช้ AES-256-GCM ดังนั้นหากรหัสผ่านไม่ถูกต้องหรือไฟล์เสียหาย ระบบจะปฏิเสธการถอดรหัสและจะไม่ถอดรหัสเป็นข้อมูลที่ไม่ถูกต้อง
• ส่วนหัว (รูปแบบ เวอร์ชัน พารามิเตอร์ KDF ค่า salt) จะถูกผูกเข้ากับแท็ก GCM เป็นข้อมูลที่ได้รับการตรวจสอบความถูกต้องเพิ่มเติม ดังนั้นไฟล์ที่มีการแก้ไขค่า work factor ให้ต่ำลงจะไม่สามารถเปิดได้

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

รูปแบบ v1 (จัดส่งในเวอร์ชัน 1.0 อ่านได้ปกติ)

{
  "format": "authbackup",
  "version": 1,
  "kdf": "PBKDF2-HMAC-SHA256",
  "rounds": 600000,
  "salt": "<base64, 16 bytes>",
  "cipher": "AES-256-GCM",
  "nonce": "<base64, 12 bytes>",
  "ciphertext": "<base64>",
  "tag": "<base64, 16 bytes>"
}

ขั้นตอน	ไบต์
key	PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes)
aad	UTF-8("authbackup:1:600000:") ‖ salt (ไบต์เกลือดิบ ไม่ใช่ base64)
ciphertext, tag	AES-256-GCM(key, nonce, plaintext, aad); แท็กขนาด 16 ไบต์ จัดเก็บแยกต่างหาก
plaintext	JSON ในรูปแบบ UTF-8 โดยเรียงลำดับคีย์แล้ว: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1}

หมายเหตุเกี่ยวกับความเข้ากันได้: Android 1.0 เขียนไฟล์เวอร์ชัน v1 ที่แตกต่างออกไป — ไฟล์ kdf เป็นตัวพิมพ์เล็ก ไม่มีคีย์แท็ก (แท็ก 16 ไบต์ที่ต่อท้ายข้อความเข้ารหัส) และไม่มีข้อมูลเพิ่มเติม ทั้งสองแพลตฟอร์มยังคงอ่านไฟล์เหล่านั้น (เมื่อไม่มีแท็ก: แยก 16 ไบต์สุดท้าย เปิดด้วย AAD ว่างเปล่า เปรียบเทียบ kdf โดยไม่คำนึงถึงตัวพิมพ์ใหญ่เล็ก) และทั้งสองแพลตฟอร์มจะเขียนเฉพาะรูปแบบข้างต้นเท่านั้น

รูปแบบ v2 (ปัจจุบัน; ค่าเริ่มต้นสำหรับการสำรองข้อมูลใหม่)

{
  "format": "authbackup",
  "version": 2,
  "kdf": "Argon2id",
  "memoryKiB": 65536,
  "passes": 3,
  "lanes": 1,
  "salt": "<base64, 16 bytes>",
  "cipher": "AES-256-GCM",
  "nonce": "<base64, 12 bytes>",
  "ciphertext": "<base64>",
  "tag": "<base64, 16 bytes>"
}

ขั้นตอน	ไบต์
key	Argon2id(version 0x13, passphrase as UTF-8, salt, m = 65536 KiB, t = 3, p = 1, tagLength 32, no secret, no associated data)
aad	UTF-8("authbackup:2:argon2id:65536:3:1:") ‖ salt
ciphertext, tag	AES-256-GCM(key, nonce, plaintext, aad); แท็กขนาด 16 ไบต์ จัดเก็บแยกต่างหาก
plaintext	JSON ในรูปแบบ UTF-8 โดยเรียงลำดับคีย์แล้ว: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2}

Argon2id เป็นไลบรารีภาษา C ที่ใช้เป็นมาตรฐาน (phc-winner-argon2, CC0) ซึ่งรวมอยู่ในทั้งสองแพลตฟอร์ม ขนาด 64 MiB และการประมวลผล 3 รอบใช้เวลาประมาณหนึ่งวินาทีบนโทรศัพท์รุ่นปัจจุบัน และทำให้การเดาแต่ละครั้งใช้หน่วยความจำและเวลาเท่ากันบนฮาร์ดแวร์ใดๆ ก็ตาม ซึ่งเป็นคุณสมบัติที่ PBKDF2 ขาดไปเมื่อใช้กับเครื่อง GPU และเป็นเหตุผลที่ทำให้มีเวอร์ชัน 2 ตัวอ่านจะไม่สนใจคีย์ที่ไม่รู้จัก ดังนั้นตัวอ่านเวอร์ชัน 1 เมื่อได้รับข้อมูลตัวอ่านเวอร์ชัน 2 จะไม่เห็นการ์ดเลย

การพิสูจน์

ไฟล์เวกเตอร์ทดสอบสามไฟล์ (backup v1, backup v2 และ Argon2id) ถูกสร้างขึ้นโดยการใช้งานที่สาม ซึ่งเป็นอิสระจากแอปพลิเคชันทั้งสอง (OpenSSL ของ Node สำหรับ PBKDF2 และ AES-GCM, Argon2id ของ WebAssembly ที่ตรวจสอบในขณะสร้างไฟล์เทียบกับคำตอบที่เผยแพร่ของการใช้งานอ้างอิง) แต่ละไฟล์ประกอบด้วยวลีรหัสผ่าน, salt, nonce, ข้อความธรรมดา, คีย์ที่ได้มา, AAD, ข้อความเข้ารหัสที่คาดหวัง และแท็ก รวมถึงไฟล์ทั้งหมด การทดสอบหน่วยบน iOS และ Android อ่านไฟล์เดียวกันและตรวจสอบไบต์เดียวกัน ดังนั้นการสำรองข้อมูลที่ปิดผนึกบนแพลตฟอร์มหนึ่งจึงได้รับการพิสูจน์แล้ว ไม่ใช่การสันนิษฐาน ว่าสามารถเปิดได้บนอีกแพลตฟอร์มหนึ่ง และข้อตกลงของทั้งสามแพลตฟอร์มไม่ได้หมายความว่ามีข้อผิดพลาดเดียวกันสองชุด เครื่องมือเสริมจะเปิดไฟล์ที่โทรศัพท์เขียนขึ้นจริงโดยใช้การใช้งานเวอร์ชันที่สามแบบเดียวกัน และตรวจสอบส่วนหัวเทียบกับกฎข้างต้น (ใช้คีย์ของรูปแบบอย่างถูกต้อง ดังนั้นจึงไม่มีคำใบ้หรือชื่อใดๆ อยู่; เกลือ 16 ไบต์, นอนซ์ 12 ไบต์, แท็ก 16 ไบต์ จัดเก็บแยกกัน; เวอร์ชัน 2 ที่ 64 MiB / 3 / 1 พอดี; รหัสผ่านที่ไม่ถูกต้องถูกปฏิเสธ); การรัน iOS อัตโนมัติจะเขียนไฟล์หนึ่งลงในโปรแกรมจำลองและเปิดไฟล์นั้นด้วยวิธีนั้น และค้นหาคอนเทนเนอร์แอปของโปรแกรมจำลอง คอนเทนเนอร์กลุ่มแอป และฐานข้อมูลคีย์เชนสำหรับรหัสผ่านและหมายเลขบัตรที่ใส่ไว้ทั้งหมดในรูปแบบ UTF-8 และ UTF-16 (ไม่พบผลลัพธ์ใดๆ)

4. แบบจำลองภัยคุกคาม

สถานการณ์	สิ่งที่พวกเขามี	สิ่งที่พวกเขาได้รับ
โทรศัพท์หายหรือถูกขโมย หรือถูกล็อกไว้	สิ่งที่พวกเขามีอุปกรณ์ ไฟล์ฐานข้อมูล แถวที่ถูกปิดผนึก	สิ่งที่พวกเขาได้รับข้อความเข้ารหัสลับ กุญแจเข้ารหัสถูกเก็บไว้ใน Secure Enclave / StrongBox และจะถูกปล่อยออกมาก็ต่อเมื่ออุปกรณ์ถูกล็อกและมีการป้อนไบโอเมตริกหรือรหัสผ่านใหม่เท่านั้น การล้างข้อมูลโทรศัพท์จากระยะไกล (Find My / Find My Device) จะทำลายข้อมูลกุญแจเข้ารหัสไปด้วย
ไฟล์สำรองที่ถูกขโมย	สิ่งที่พวกเขามีไฟล์ .authbackup จากบัญชีคลาวด์ อีเมล หรือแล็ปท็อป	สิ่งที่พวกเขาได้รับการเข้ารหัสแบบ AES-256-GCM ภายใต้คีย์ที่ได้มาจากวลีรหัสผ่านที่มีความยาวอย่างน้อย 12 ตัวอักษร พร้อมด้วย salt ต่อไฟล์ และ Argon2id ที่ 64 MiB × 3 รอบ (v2) หรือ PBKDF2 ที่ 600,000 รอบ (v1) ไม่มีคำใบ้ ไม่มีชื่อผู้ใช้ ไม่มีรายการบัญชีที่เปิดเผย การเดาแต่ละครั้งต้องใช้การคำนวณทั้งหมด ไม่มีทางลัด วลีรหัสผ่านที่แข็งแกร่งคือการป้องกันทั้งหมดในที่นี้ และแอปพลิเคชันก็ระบุไว้เช่นนั้นในเอกสาร
อุปกรณ์ที่ถูกขโมยโดยที่หน้าจอไม่ได้ล็อก	สิ่งที่พวกเขามีโทรศัพท์ในมือของคุณที่ปลดล็อกแล้ว	สิ่งที่พวกเขาได้รับรายการรหัส ข้อมูลสำคัญ (รหัสผ่าน บัตร) อยู่หลังการล็อกแอป และจะล็อกอัตโนมัติเมื่อตั้งเวลา (ทันที / 1 นาที / 5 นาที) ค่าที่ถอดรหัสแล้วจะอยู่ในหน่วยความจำเฉพาะขณะที่หน้าจอแสดงค่านั้นอยู่เท่านั้น การกรอกข้อมูลอัตโนมัติและการส่งออกข้อความธรรมดาจะขอข้อมูลไบโอเมตริกใหม่แม้ว่าแอปจะเปิดอยู่ก็ตาม หากคุณกังวลเกี่ยวกับเรื่องนี้ ให้เปิดใช้งานการล็อกแอปโดยเลือก "ทันที"
แอปที่เป็นอันตรายในโทรศัพท์เครื่องเดียวกัน	สิ่งที่พวกเขามีแซนด์บ็อกซ์ของแอปอื่น คลิปบอร์ด การเข้าถึง หรือเทคนิคการแสดงผลซ้อนทับ	สิ่งที่พวกเขาได้รับระบบไม่สามารถอ่านไฟล์ของเราได้ (การจำกัดการเข้าถึงแพลตฟอร์ม) หรือใช้คีย์ของเราได้ (คีย์ผูกอยู่กับข้อมูลประจำตัวในการลงนามและสถานะการใช้งานของผู้ใช้) สำเนาจะถูกลบออกจากคลิปบอร์ดหลังจาก 30 วินาที บน Android สำเนาจะถูกทำเครื่องหมายว่าเป็นข้อมูลที่ละเอียดอ่อนและจะไม่ปรากฏในประวัติคลิปบอร์ด หน้าจอ Vault จะตั้งค่าเป็น FLAG_SECURE บน Android (ไม่สามารถจับภาพหน้าจอ ไม่สามารถบันทึกหน้าจอได้ และว่างเปล่าในตัวสลับแอป) บน iOS จะแสดงภาพขนาดย่อของตัวสลับแอปเป็นสีดำ การกรอกข้อมูลอัตโนมัติบน Android จะแสดงเฉพาะแอปที่ระบบได้ตรวจสอบกับโดเมนที่บันทึกไว้แล้ว (Digital Asset Links) เท่านั้น ดังนั้นแอปที่ดูคล้ายกันจะไม่ได้รับรหัสผ่านของคุณ
หน้าเว็บฟิชชิ่ง	สิ่งที่พวกเขามีเว็บไซต์ที่มีลักษณะเหมือนกับเว็บไซต์ที่คุณบันทึกไว้	สิ่งที่พวกเขาได้รับไม่มีอะไรถูกกรอกลงไป การจับคู่จะใช้โดเมนที่ลงทะเบียนได้ (รายการส่วนต่อท้ายสาธารณะ ซึ่งรวมและอัปเดตไว้ในแอป): login.example.com และ example.com จะตรงกัน ส่วน example.com.evil.net และ examp1e.com จะไม่ตรงกัน เบราว์เซอร์ในแอปจะจับคู่ในลักษณะเดียวกันและกรอกเฉพาะในเฟรมที่ขอเท่านั้น โดยจะตรวจสอบซ้ำกับต้นทางของเฟรมนั้นในขณะที่ทำการกรอก โฮสต์ที่ไม่มีโดเมนที่ลงทะเบียนได้ของตัวเอง เช่น ที่อยู่ IP หรือชื่อเปล่าบนเครือข่ายท้องถิ่น จะตรงกันอย่างแม่นยำและไม่คลาดเคลื่อนไปจากนั้น iOS AutoFill เพิ่มการตรวจสอบโดเมนที่เกี่ยวข้องของ Apple รหัสผ่านที่คุณต้องวางด้วยตนเองลงในช่องที่ดูคล้ายกันยังคงมีความเสี่ยง แอปไม่สามารถลบความเสี่ยงนั้นได้ เพียงแต่หลีกเลี่ยงการให้ความช่วยเหลือเท่านั้น
เซิร์ฟเวอร์ของเราเอง	สิ่งที่พวกเขามี—	สิ่งที่พวกเขาได้รับไม่มีเซิร์ฟเวอร์เก็บข้อมูลลับ AssuredAuth ไม่มีบัญชี ไม่มีระบบลงชื่อเข้าใช้ และไม่มีสำเนาข้อมูลลับของคุณ ดังนั้นจึงไม่มีสิ่งใดของคุณอยู่ในฝั่งของเราที่จะถูกขโมยหรือเจาะระบบได้ มีเพียงสองสิ่งเท่านั้นที่ทำงานอยู่บนฝั่งเซิร์ฟเวอร์ ซึ่งทั้งสองอย่างนี้ไม่ได้แตะต้องข้อมูลลับเลย ได้แก่ กล่องจดหมายรีเลย์สำหรับส่วนขยายเดสก์ท็อป ซึ่งจัดเก็บซองจดหมายที่เข้ารหัสแบบ end-to-end (รหัสใช้ครั้งเดียว จะถูกลบเมื่ออ่านแล้ว รีเลย์ไม่เคยมีคีย์) และเซิร์ฟเวอร์ทางออกของการเชื่อมต่อส่วนตัว (ซึ่งเป็นตัวเลือกเสริม) ซึ่งทำหน้าที่จัดการการรับส่งข้อมูลและไม่เก็บบันทึกการเข้าถึงใดๆ
หมายเรียกหรือคำร้องขอจากรัฐบาล	สิ่งที่พวกเขามีกระบวนการทางกฎหมายที่ส่งถึงเรา	สิ่งที่พวกเขาได้รับไม่มีอะไรต้องส่งมอบ: เราไม่มีตู้นิรภัย ไม่มีกุญแจ ไม่มีรหัสผ่าน และไม่มีข้อมูลสำรอง เราอาจถูกบังคับให้พูดอย่างนั้นได้ แต่เราไม่สามารถถูกบังคับให้ผลิตสิ่งที่ไม่มีอยู่จริงได้

5. คลิปบอร์ด ภาพหน้าจอ และหน่วยความจำ

• ฟังก์ชันคัดลอกจะบันทึกค่าลงในคลิปบอร์ดเป็นเวลา 30 วินาที จากนั้นจะลบออกหากค่าดังกล่าวยังคงเป็นของเราอยู่ ในระบบ Android คลิปบอร์ดจะถูกทำเครื่องหมายว่า EXTRA_IS_SENSITIVE เพื่อให้ระบบซ่อนคลิปบอร์ดจากหน้าตัวอย่างและประวัติการคัดลอก ในระบบ iOS รายการในคลิปบอร์ดจะเป็นแบบเฉพาะเครื่อง (ไม่สามารถส่งต่อไปยังอุปกรณ์อื่นได้)
• หน้าจอ Vault (รหัสผ่าน, รหัสผ่าน, บัตร, บัตร, แผ่นรหัสผ่าน, การส่งออกข้อความธรรมดา) จะตั้งค่าเป็น FLAG_SECURE บน Android ส่วน iOS ไม่มีแฟล็กที่เทียบเท่ากัน แอปจะลบภาพขนาดย่อในตัวสลับแอป และค่าต่างๆ จะถูกซ่อนไว้หลังไอคอนรูปตาโดยค่าเริ่มต้น
• ค่าที่ถอดรหัสแล้วจะถูกเก็บไว้ในหน่วยความจำเฉพาะขณะที่หน้าจอแสดงค่าเหล่านั้น และจะถูกลบออกเมื่อหน้าจอปิดลงหรือแอปล็อก ข้อมูลสำคัญจะถูกถอดรหัสสำหรับคำขอแต่ละครั้งและจะไม่ถูกแคชไว้เมื่อแอปล็อก
• มีฟังก์ชันส่งออกเป็นข้อความธรรมดา (เพื่อให้คุณสามารถออกจากโปรแกรมได้เสมอ) โดยจะต้องยืนยันข้อมูลและตรวจสอบไบโอเมตริกก่อน และหน้าจอนั้นก็มีการตั้งค่าความปลอดภัยระดับ FLAG_SECURE เช่นกัน

6. การกรอกข้อมูลอัตโนมัติ: ข้อมูลใดบ้างที่จะถูกกรอก และข้อมูลใดบ้างที่ไม่ถูกกรอก

ที่ไหน	รหัสผ่าน	บัตร
iOS: Safari และแอปต่างๆ (ส่วนขยาย AutoFill)	รหัสผ่านใช่ครับ หลังจากตั้งค่า Face ID / Touch ID / รหัสผ่านใหม่ในส่วนขยาย (LAContext) และเฉพาะโดเมนที่ลงทะเบียนได้ซึ่งบันทึกข้อมูลไว้เท่านั้น โดยใช้การตรวจสอบโดเมนที่เกี่ยวข้องของแอปจาก Apple	บัตรไม่ครับ ฟังก์ชันกรอกข้อมูลอัตโนมัติใน Safari เป็นของ Apple แต่เพียงผู้เดียว หน้าจอการ์ดจะระบุว่า "กรอกข้อมูลในเบราว์เซอร์ AssuredAuth และมีฟังก์ชันคัดลอก" และไม่ได้ให้คำมั่นสัญญาอะไรเพิ่มเติม
Android: แอปและ Chrome (AutofillService)	รหัสผ่านใช่ การตรวจสอบสิทธิ์ต่อชุดข้อมูล: ระบบจะแสดง BiometricPrompt ก่อนกรอกข้อมูล และแพ็กเกจแอปจะตรงกันก็ต่อเมื่อ Digital Asset Links เชื่อมโยงกับโดเมนที่บันทึกไว้เท่านั้น	บัตรใช่แล้ว ข้อมูลบัตรเครดิต ได้แก่ หมายเลขบัตรเครดิต วันหมดอายุของบัตรเครดิต* ​​และรหัสความปลอดภัยของบัตรเครดิต ซึ่งเป็นข้อมูลที่ใช้ตรวจสอบด้วยระบบไบโอเมตริกเหมือนกัน
เบราว์เซอร์ AssuredAuth (ทั้งสองแพลตฟอร์ม)	รหัสผ่านใช่ โดยใช้โดเมนที่จดทะเบียนได้ — โฮสต์ที่ไม่มีการจับคู่ที่ตรงกันอย่างแม่นยำ — เข้าไปในกรอบที่ขอไว้ โดยใช้ข้อมูลไบโอเมตริกก่อนกรอกข้อมูล	บัตรใช่ค่ะ โดยใช้การตรวจจับภาคสนามและระบบไบโอเมตริกก่อนการกรอกข้อมูล
ปุ่มคัดลอก	รหัสผ่านเบื้องหลังการล็อกแอป มีคลิปบอร์ดให้ดาวน์โหลดภายใน 30 วินาที	บัตรหมายเลข, วันหมดอายุ, CVC (ใช้กฎเดียวกัน)

ไม่มีอะไรจะกรอกข้อมูลได้บนโฮสต์ที่มีหน้าตาคล้ายกัน ไม่มีอะไรจะกรอกข้อมูลได้หากปราศจากข้อมูลไบโอเมตริก

7. สิ่งที่ไม่เคยเกิดขึ้น

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

8. สิ่งที่เราไม่สามารถป้องกันได้

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

9. ตรวจสอบสถานะ

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

10. ที่ซึ่งสิ่งต่างๆ ดำเนินไป

ไม่มีข้อมูลใดๆ จากระบบรักษาความปลอดภัยถูกส่งออกจากโทรศัพท์ แต่มีบางส่วนที่ทำงานบนเครื่องคอมพิวเตอร์ของผู้อื่น นี่คือรายการข้อมูลและสิ่งที่แต่ละรายการจัดเก็บไว้ ส่วนการไหลเวียนของข้อมูลนั้นได้อธิบายไว้ในนโยบายความเป็นส่วนตัวที่ https://assuredauth.com/privacy แล้ว

• Google Cloud / Firebase — ทำหน้าที่เป็นกล่องจดหมายส่งต่อสำหรับส่วนขยายเดสก์ท็อป (ซองจดหมายเข้ารหัสแบบ end-to-end และจะถูกลบเมื่ออ่านแล้ว) โทเค็นสำหรับการแจ้งเตือนแบบพุช สถานะการซื้อ และข้อความที่ส่งผ่านแบบฟอร์มติดต่อ
• Vercel — assuredauth.com, หน้าเว็บต่างๆ และฟังก์ชันเล็กๆ ที่อยู่เบื้องหลัง
• Vultr คือเซิร์ฟเวอร์ขาออกของการเชื่อมต่อส่วนตัว ข้อมูลจะไหลผ่านเซิร์ฟเวอร์เหล่านี้เท่านั้น ไม่มีการจัดเก็บข้อมูลใดๆ
• Apple และ Google Play — การซื้อและการสมัครสมาชิกในร้านค้าของตนเอง
• PostHog — การวิเคราะห์ผลิตภัณฑ์: นับจำนวนการใช้งาน โดยไม่ผูกติดกับตัวตนใดๆ
• RevenueCat — สถานะการสมัครสมาชิก: ใช้งานอยู่หรือหมดอายุ และอยู่ในแพ็กเกจใด

แต่ละรายการจะแสดงรายการตามที่ระบุไว้ในบรรทัดนั้น ๆ และไม่มีข้อมูลใด ๆ จากคลังข้อมูล รายการจะเปลี่ยนแปลงไปเมื่อผลิตภัณฑ์นั้น ๆ เปลี่ยนแปลง และส่วนนี้จะเปลี่ยนแปลงไปพร้อมกันด้วย

การรายงานจุดอ่อน

หากคุณเชื่อว่าคุณพบจุดอ่อนในสิ่งใดก็ตามที่อธิบายไว้ที่นี่ โปรดเขียนถึง hello@assuredauth.com โดยระบุหัวข้อว่า "Security" โปรดระบุแพลตฟอร์ม เวอร์ชันแอป และขั้นตอนต่างๆ หลักฐานที่ใช้ข้อมูลของคุณเองก็เพียงพอแล้ว และเราขอให้คุณอย่าทดสอบกับข้อมูลของผู้อื่น เราไม่มีบริการคีย์ PGP หากรายงานไม่ควรส่งทางอีเมลธรรมดา โปรดแจ้งให้เราทราบในข้อความแรก และเราจะจัดหาช่องทางอื่นให้

สิ่งที่เราสัญญาตอบแทน: เราจะตอบรับภายในสามวันทำการ แจ้งความคืบหน้าให้คุณทราบระหว่างที่เราดำเนินการ แก้ไขสิ่งที่ผิดพลาดก่อนที่จะเผยแพร่ และให้เครดิตคุณที่นี่หากคุณต้องการ เราจะไม่ดำเนินการทางกฎหมายใดๆ เกี่ยวกับการวิจัยที่ทำด้วยความสุจริตใจภายในขอบเขตที่ระบุไว้ด้านล่าง

ขอบเขตการตรวจสอบ: แอปพลิเคชัน iOS และ Android, แอปพลิเคชันสำหรับ Apple Watch, ส่วนขยายสำหรับเดสก์ท็อป, assuredauth.com และ API ของเว็บไซต์ ขอบเขตการตรวจสอบ: App Store และ Google Play เอง, ผู้ให้บริการที่ระบุไว้ข้างต้น, การหลอกลวงทางสังคมต่อบุคคลใดๆ และการโจมตีแบบปฏิเสธการให้บริการ (Denial of Service)

ขณะนี้ไม่มีรางวัลนำจับ การแจ้งรายงานจะได้รับการตอบกลับด้วยการแก้ไขปัญหาและคำขอบคุณ ไม่ใช่การให้เงินรางวัล