보안
금고가 어떻게 만들어졌는지, 그리고 침입이 발생하면 무엇이 발견될지.
최종 업데이트: 2026년 9월 21일 · AssuredAuth, CircleRoll LLC 제공
이 문서는 AssuredAuth가 사용자가 저장하는 2단계 인증 비밀번호, 암호 및 카드 정보를 어떻게 보호하는지에 대한 공개 설명입니다. 보안에 민감한 독자가 앱의 모든 주장을 검증하고 공개된 테스트 벡터(hello@assuredauth.com으로 요청 시 제공 가능)를 통해 확인할 수 있도록 작성되었습니다. 이 문서에는 사실만 명시되어 있으며, 어떠한 공격에도 완전히 안전하다고 주장하거나 특정 비율을 보장하지는 않습니다.
간단히 설명드리자면, 데이터 저장소는 단 한 곳, 바로 여러분의 휴대폰에만 존재합니다. 저장소에 저장된 모든 값은 휴대폰의 보안 하드웨어가 보유하고 있으며 외부로 유출될 수 없는 암호화 키로 암호화됩니다. 저희는 저장소 서버를 운영하지 않으며, 저장소 사본이나 암호화 키를 보관하지 않습니다. 백업 파일은 암호화된 후에만 휴대폰에서 외부로 전송되며, 이 암호화 키는 어디에도 저장되지 않습니다.
문제 신고: hello@assuredauth.com. 본문 말미의 "약점 보고" 부분을 참조하십시오.
1. 무엇이 어떤 것으로 암호화되었습니까?
| 데이터 | 휴대폰에서 | 키 |
|---|---|---|
| 2단계 인증 (TOTP/HOTP/Steam 시드) | 휴대폰에서키체인(iOS) / 안드로이드 키스토어 기반 저장소 | 키플랫폼의 하드웨어에 연결된 키입니다. 데이터베이스 행에는 시드(seed)가 아닌 참조(secretRef)만 저장됩니다. |
| 비밀번호 (비밀번호 값, 메모) | 휴대폰에서봉인된 행: AES-256-GCM, 값당 96비트 난수 생성 | 키256비트의 임의 데이터 키는 2절의 하드웨어 키로 래핑됩니다. |
| 카드 정보 (카드 번호, 만료일, 카드 소지자 이름, CVC 코드) | 휴대폰에서비밀번호와 동일한 보안 조치가 적용됩니다. CVC는 선택 사항이며 입력한 경우에만 저장됩니다. | 키동일한 데이터 키 |
| 메타데이터(서비스 이름, 사용자 이름, 아이콘, 정렬 순서) | 휴대폰에서앱의 데이터베이스(SwiftData/Room) | 키운영체제의 파일 암호화 기능으로 보호되며, 비밀이 아닌 것으로 취급됩니다. |
| 백업 파일(.authbackup) | 휴대폰에서어디에 두든 상관없습니다. 파일, iCloud Drive, Google Drive 앱, DataFolder, 공유 시트 등 어디에든 저장하세요. | 키암호문(§3)에서 파생된 키입니다. Apple과 Google은 봉인된 파일만 수신하며 그 외에는 아무것도 수신하지 않습니다. |
| Watch / Wear 컴패니언 | 휴대폰에서시계 자체의 키체인/암호화된 공유 환경설정 | 키워치 플랫폼의 키는 플랫폼의 페어링된 장치 채널을 통해 전송됩니다. |
| 데스크톱 확장 프로그램 트래픽(일회용 코드는 요청 시 제공) | 휴대폰에서저장되지 않고, 종단 간 암호화된 봉투 형태로 전달됩니다. | 키페어링당 X25519 키 쌍이 하나씩 생성되며, 개인 키는 키체인/키스토어에 저장됩니다. 릴레이는 암호문만 볼 수 있습니다. |
진단 기능에는 비밀 키를 허용하는 메서드가 없습니다. 분석 이벤트에는 볼트 필드가 포함되지 않습니다. 어떤 빌드에서도 볼트의 값은 로그에 기록되지 않습니다.
2. 각 플랫폼에서 키가 보관되는 위치
iOS. 데이터 키는 보안 인클레이브(kSecAttrTokenIDSecureEnclave) 내부에서 생성된 키로 래핑되며, 접근 제어는 .privateKeyUsage + .userPresence, 접근성은 …ThisDeviceOnly로 설정되어 있습니다. 이 키는 앱의 공유 키체인 접근 그룹에 속하므로 자동 완성 확장 프로그램에서도 동일한 키를 사용할 수 있습니다. 개인 키는 앱, 백업 또는 디버거를 통해 인클레이브에서 읽어낼 수 없습니다. 인클레이브는 사용자가 기기에 접근한 후(Face ID, Touch ID 또는 기기 암호)에만 키 사용을 허용합니다. ThisDeviceOnly는 iCloud 또는 iTunes 백업에 키가 포함되지 않음을 의미합니다. 복원된 휴대폰은 빈 금고로 시작하며 백업 파일과 암호를 입력하라는 메시지가 표시됩니다. 암호가 없는 휴대폰은 .userPresence 키를 잠금 해제할 수 없습니다(인클레이브가 이를 생성하지 않음). 시뮬레이터도 설계상 동일한 방식을 따릅니다(시뮬레이터의 상태 표시 메시지는 어떤 테스트도 응답할 수 없는 경고입니다). 시뮬레이터에서 데이터 키는 일반적인 기기 전용 키체인 항목으로, 모든 백업에서 제외되고 휴대폰이 잠겨 있는 동안에는 읽을 수 없지만 두 번째 메시지는 표시되지 않습니다. 보안 화면에는 이러한 내용이 그대로 표시되며 암호를 설정하라는 메시지가 나타납니다.
Android. 데이터 키는 AndroidKeyStore AES-256 키로 래핑되며, 기기에 해당 키가 있는 경우 StrongBox에서 생성됩니다(그렇지 않은 경우 TEE). 이 키에는 setUserAuthenticationRequired(true)와 생체 인증 또는 기기 자격 증명을 사용한 후 30초 동안 인증이 유효하도록 설정되어 있으며, setUnlockedDeviceRequired(true)와 setInvalidatedByBiometricEnrollment(true) 플래그도 활성화되어 있습니다. 마지막 플래그는 부하를 주는 것이 아니라 단순히 기능을 무효화하는 용도로 사용됩니다. Android는 매번 사용할 때마다 생체 인증을 요구하는 키에만 이 플래그를 적용하므로, 기기 자격 증명을 사용하는 30초 유효 키에는 아무런 영향을 미치지 않습니다. 낯선 사람이 접근하지 못하도록 하는 것은 키 등록 시 PIN이 필요하고, 화면 잠금을 해제하면 키가 영구적으로 무효화된다는 점입니다. 키스토어 키는 내보낼 수 없으며 Android 클라우드 백업에서 제외됩니다. 앱이 자체 뷰에서 지정하는 도메인(webDomain)은 알려진 브라우저에서만 유효한 것으로 간주됩니다. 다른 패키지에서 가져온 도메인도 해당 패키지에 대해 시스템에서 검증한 도메인이어야 합니다(디지털 자산 링크). 모든 앱이 모든 도메인을 주장할 수 있기 때문입니다.
이는 도난당한 데이터베이스 파일에 어떤 의미를 갖는가? SQLite 파일과 봉인된 행들은 암호문입니다. 이를 해독하는 키는 파일이 저장된 휴대폰의 보안 하드웨어에 보관되어 있으며 파일과 함께 복사될 수 없습니다. 오프라인에서 추측할 수 있는 것은 아무것도 없습니다. 데이터 키는 임의로 생성되며, 사람이 선택한 어떤 요소에서도 파생되지 않습니다.
3. 백업 파일
백업 파일은 휴대폰에서 완전히 제외되는 유일한 데이터이므로, 원칙적으로 오프라인 공격이 가능한 유일한 지점입니다. 하지만 설계상 이러한 공격은 비용이 많이 들고 공격자가 활용할 수 있는 요소가 최소화됩니다.
- 암호는 최소 12자 이상이어야 합니다(12자 미만일 경우 시스템에서 이를 허용하지 않으며, 암호 강도 막대가 표시됩니다).
- 암호 힌트는 파일이나 앱 어디에도 저장되지 않습니다.
- 파일을 작성할 때마다 새로운 16바이트 솔트와 12바이트 논스가 무작위로 생성됩니다.
- 전체 내용이 AES-256-GCM으로 암호화되어 있으므로, 잘못된 암호문이나 손상된 파일은 거부되며, 절대 해독되어 의미 없는 데이터가 생성되지 않습니다.
- 헤더(형식, 버전, KDF 매개변수, 솔트)는 추가 인증 데이터로 GCM 태그에 바인딩되므로 작업 인자가 낮아진 파일은 열리지 않습니다.
해당 파일은 JSON 형식이며 모든 텍스트 편집기에서 읽을 수 있습니다. 암호화된 부분만 불투명합니다. 5년 후 앱이 사라진 상태에서 누군가가 이 파일을 발견한다면, 파일이 어떻게 암호화되었는지 정확히 확인할 수 있고 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 | UTF-8 JSON, 키 정렬됨: {"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 | UTF-8 JSON, 키 정렬됨: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id는 두 플랫폼 모두에 탑재된 참조 C 구현체(phc-winner-argon2, CC0)입니다. 64MiB 메모리와 3번의 패스는 현재 스마트폰에서 약 1초가 소요되며, 모든 하드웨어에서 각 추측에 해당 메모리와 시간이 소모됩니다. 이는 PBKDF2가 GPU 환경에서 부족한 부분이며, v2가 존재하는 이유이기도 합니다. 카드 리더기는 알지 못하는 키를 무시하므로, v1 리더기는 v2 카드 본체를 인식하지 못합니다.
증거
세 개의 테스트 벡터 파일(백업 v1, 백업 v2 및 Argon2id)은 두 앱과 독립적인 제3의 구현(PBKDF2 및 AES-GCM용 Node의 OpenSSL, 참조 구현의 공개된 응답과 생성 시 대조되는 WebAssembly Argon2id)을 사용하여 생성됩니다. 각 파일에는 암호, 솔트, 논스, 평문, 파생 키, AAD, 예상 암호문 및 태그, 그리고 전체 파일이 포함되어 있습니다. iOS와 Android에서 실행되는 단위 테스트는 동일한 파일을 읽고 동일한 바이트를 검증합니다. 따라서 한 플랫폼에서 암호화된 백업은 다른 플랫폼에서도 열 수 있음이 입증되었으며, 세 플랫폼 모두에서 동일한 오류가 반복되는 것이 아닙니다. 보조 도구는 휴대폰이 실제로 동일한 세 번째 구현으로 작성한 파일을 열고 헤더를 위의 규칙과 비교하여 확인합니다(정확히 형식의 키이므로 힌트나 이름이 있을 수 없음; 16바이트 솔트, 12바이트 논스, 16바이트 태그가 별도로 저장됨; 버전 2, 정확히 64MiB/3/1 크기; 잘못된 암호는 거부됨). 자동화된 iOS 실행은 시뮬레이터에 파일을 작성하고 해당 방식으로 파일을 열어 시뮬레이터의 앱 컨테이너, 앱 그룹 컨테이너 및 키체인 데이터베이스에서 시드된 모든 암호와 카드 번호를 UTF-8 및 UTF-16 형식으로 검색합니다(0건).
4. 위협 모델
| 상황 | 가진 것 | 얻는 것 |
|---|---|---|
| 분실 또는 도난당한 휴대전화, 잠금 상태 | 가진 것장치, 데이터베이스 파일, 봉인된 행 | 얻는 것암호문. 래핑 키는 보안 영역/StrongBox에 저장되며, 기기 잠금 후 새로운 생체 정보 또는 암호를 입력해야만 해제됩니다. 원격으로 휴대폰을 초기화(나의 찾기/기기 찾기)하면 키 자료도 함께 파괴됩니다. |
| 도난당한 백업 파일 | 가진 것클라우드 계정, 이메일, 노트북의 .authbackup 파일 | 얻는 것최소 12자 길이의 암호문에서 파생된 키를 사용하는 AES-256-GCM 본문에 파일별 솔트가 적용되며, Argon2id는 64MiB × 3회 패스(v2) 또는 PBKDF2는 600,000라운드(v1)로 실행됩니다. 힌트, 사용자 이름, 계정 목록은 평문으로 제공되지 않습니다. 암호문을 추측할 때마다 전체 파생 과정이 필요하며, 지름길은 없습니다. 강력한 암호문이 보안의 핵심이며, 앱 설명서에도 이 점이 명시되어 있습니다. |
| 도난당한 기기, 화면 잠금 해제됨 | 가진 것손에 든 휴대폰, 잠금 해제된 상태 | 얻는 것코드 목록입니다. 금고(비밀번호, 카드)는 앱 잠금으로 보호되며 자동 잠금 타이머(즉시/1분/5분)에 따라 다시 잠깁니다. 복호화된 값은 화면에 표시되는 동안에만 메모리에 저장됩니다. 자동 완성 및 일반 텍스트 내보내기 기능은 앱이 열려 있는 경우에도 새로운 생체 인증을 요구합니다. 이러한 문제가 걱정되시면 앱 잠금을 "즉시"로 설정하세요. |
| 같은 휴대폰에 악성 앱이 설치되어 있음 | 가진 것다른 앱의 샌드박스, 클립보드, 접근성 또는 오버레이 기능 | 얻는 것해당 앱은 사용자 파일(플랫폼 샌드박싱)을 읽거나 사용자 키(키는 서명 ID 및 사용자 접속 정보와 연결됨)를 사용할 수 없습니다. 클립보드에 복사된 내용은 30초 후 삭제됩니다. Android에서는 복사본이 민감한 정보로 표시되어 클립보드 기록에서 제외됩니다. Android에서는 Vault 화면에 FLAG_SECURE 플래그가 설정됩니다(스크린샷 및 화면 녹화 금지, 앱 전환 메뉴 빈 화면). iOS에서는 앱 전환 메뉴의 썸네일이 비어 있습니다. Android의 자동 완성 기능은 시스템에서 저장된 도메인(디지털 자산 링크)에 대해 검증된 앱에만 제공되므로, 유사한 앱에는 비밀번호가 제공되지 않습니다. |
| 피싱 페이지 | 가진 것저장한 사이트와 비슷하게 생긴 사이트 | 얻는 것아무것도 채워지지 않습니다. 일치 여부는 등록 가능한 도메인(앱에 포함되어 업데이트되는 공개 접미사 목록)을 기준으로 판단합니다. login.example.com과 example.com은 일치하지만 example.com.evil.net과 examp1e.com은 일치하지 않습니다. 앱 내 브라우저도 같은 방식으로 일치 여부를 확인하며, 요청한 프레임에만 자동으로 채워집니다. 이때 채워지는 순간 해당 프레임의 출처와 다시 한번 대조됩니다. 등록 가능한 도메인이 없는 호스트(IP 주소, 로컬 네트워크상의 이름 등)는 정확하게 일치하며, 그 외의 다른 것은 전혀 일치하지 않습니다. iOS 자동 완성 기능은 Apple의 연관 도메인 확인 기능을 추가합니다. 하지만 유사한 주소에 직접 암호를 입력해야 하는 경우는 여전히 위험합니다. 앱은 이러한 위험을 완전히 제거할 수는 없고, 단지 입력을 방해하지 않도록 할 뿐입니다. |
| 우리 자체 서버 | 가진 것— | 얻는 것금고 서버는 존재하지 않습니다. AssuredAuth는 계정도 없고, 로그인 기능도 없으며, 금고 사본도 보관하지 않으므로, 도난당하거나 해킹될 수 있는 귀하의 개인 정보는 저희 측에 없습니다. 서버 측에서는 두 가지 기능이 실행되지만, 둘 다 금고와는 아무런 관련이 없습니다. 하나는 데스크톱 확장 프로그램용 릴레이 사서함으로, 종단 간 암호화된 봉투(일회용 코드, 읽으면 삭제됨, 릴레이 서버는 키를 보유하지 않음)를 저장합니다. 다른 하나는 선택적 개인 연결의 종료 서버로, 트래픽을 처리하며 접속 로그를 저장하지 않습니다. |
| 소환장 또는 정부 요청 | 가진 것우리에게 발송된 법적 절차 | 얻는 것넘겨줄 것이 없습니다. 저희는 금고도, 열쇠도, 암호도, 백업 파일도 가지고 있지 않습니다. 그렇다고 말하도록 강요받을 수는 있지만, 존재하지 않는 것을 제출하도록 강요받을 수는 없습니다. |
5. 클립보드, 스크린샷 및 메모리
- 복사 기능은 클립보드에 값을 30초 동안 저장한 후, 해당 값이 여전히 내 소유인 경우 삭제합니다. 안드로이드에서는 클립에 EXTRA_IS_SENSITIVE라는 표시가 되어 시스템에서 클립보드 미리보기와 기록에 표시되지 않도록 합니다. iOS에서는 클립보드 항목이 로컬 기기 전용으로만 사용되며(다른 기기로 Handoff되지 않음) 전송되지 않습니다.
- Android에서는 Vault 화면(암호, 암호, 카드, 카드, 암호문 시트, 일반 텍스트 내보내기)에서 FLAG_SECURE 플래그가 설정됩니다. iOS에는 이에 상응하는 플래그가 없으며, 앱 전환기에서 앱의 썸네일이 사라지고 기본적으로 눈 모양 아이콘으로 값이 표시됩니다.
- 복호화된 값은 화면에 표시되는 동안에만 메모리에 저장되며, 화면이 사라지거나 앱이 잠기면 삭제됩니다. 데이터 키는 요청 시에만 복호화되며, 잠금 해제 후에도 캐시되지 않습니다.
- 일반 텍스트 내보내기 기능이 있으며(언제든지 종료할 수 있음), 확인 시트와 새로운 생체 정보 입력이 필요하고, 해당 화면도 FLAG_SECURE로 표시됩니다.
6. 자동 완성: 어떤 항목이 채워지고 어떤 항목은 채워지지 않는가
| 위치 | 비밀번호 | 카드 |
|---|---|---|
| iOS: Safari 및 앱(자동 완성 확장 프로그램) | 비밀번호예, 확장 프로그램(LAContext)에서 Face ID/Touch ID/암호를 새로 등록한 후, Apple의 앱 관련 도메인 확인 기능을 통해 해당 항목이 저장된 등록 가능한 도메인에 대해서만 가능합니다. | 카드아니요. 사파리의 카드 자동 완성 기능은 애플만의 기능입니다. 카드 화면에는 "AssuredAuth 브라우저에서 자동 완성되며 복사 기능도 제공합니다"라고만 표시되어 있고 그 외의 다른 기능은 제공하지 않습니다. |
| Android: 앱 및 Chrome(자동 완성 서비스) | 비밀번호예, 데이터 세트별 인증입니다. 시스템은 입력 전에 생체인식 프롬프트를 표시합니다. 앱 패키지는 디지털 자산 링크가 저장된 도메인과 연결될 때만 일치합니다. | 카드네, 신용카드 번호, 신용카드 만료일*, 신용카드 보안 코드는 모두 동일한 생체 인식 게이트를 나타냅니다. |
| AssuredAuth 브라우저(두 플랫폼 모두) | 비밀번호네, 등록 가능한 도메인 기준 — 자체 도메인이 없는 호스트는 정확히 일치할 때만 — 요청한 프레임에, 채우기 전에 생체 인증 | 카드네, 현장 감지를 통해 충전 전에 생체 인식을 할 수 있습니다. |
| 복사 버튼 | 비밀번호앱 잠금 뒤에 숨겨진 30초 클립보드 | 카드번호, 만료일, CVC (동일한 규칙 적용) |
유사 호스트에는 아무것도 채워지지 않습니다. 생체 정보 없이는 아무것도 채워지지 않습니다.
7. 절대 일어나지 않는 일
볼트 서버 없음. 볼트 필드를 사용하는 분석 기능 없음. 확인서와 새로운 생체 정보 없이는 일반 텍스트 내보내기 불가. 볼트 화면에 타사 SDK 로드 불가. 볼트 화면 스크린샷 불가. 암호 힌트 불가. 어떤 빌드에서도 값 로깅 불가.
8. 우리가 보호할 수 없는 것들
추측하기 쉬운 암호. 운영체제가 근본적으로 손상된 휴대폰(탈옥 또는 루팅된 기기는 위의 모든 사항에 대해 앱에 거짓 정보를 제공할 수 있습니다). 타이핑하는 동안 감시당하는 사람. 붙여넣는 바탕 화면에 있는 악성 프로그램. 이러한 설명을 덧붙이는 이유는 위 목록을 있는 그대로, 즉 디자인이 제거할 수 있는 모든 것을 제거한 것으로 이해시키기 위함입니다.
9. 검토 상태
이 디자인은 두 플랫폼 모두에서 공개된 알려진 답변과 자체 크로스 플랫폼 벡터를 대상으로 단위 테스트를 거쳤습니다. 소유자는 해당 금고를 스토어 목록에 광고하기 전에 외부 검토를 진행할 예정이며, 검토가 완료될 때까지 이 문서에는 해당 내용이 명시됩니다.
10. 각 부분이 실행되는 곳
금고에 저장된 데이터는 휴대전화에서 외부로 유출되지 않지만, 일부 기능은 다른 사람의 컴퓨터에서 실행될 수 있습니다. 다음은 해당 기능 목록이며, 각 기능에 대한 자세한 데이터 흐름은 https://assuredauth.com/privacy 에서 확인할 수 있는 개인정보 보호정책을 참조하십시오.
- Google Cloud/Firebase는 데스크톱 확장 프로그램(종단 간 암호화된 봉투, 읽으면 삭제됨), 푸시 토큰, 구매 상태 및 문의 양식을 통해 전송된 메시지를 위한 중계 메일함입니다.
- Vercel — assuredauth.com, 해당 페이지 및 그 이면에 있는 세부 기능들.
- Vultr는 사설 연결의 종료 서버입니다. 트래픽은 이 서버를 통과하지만 아무것도 저장되지 않습니다.
- 애플과 구글 플레이 스토어 - 각 스토어에서의 구매 및 구독.
- PostHog — 제품 분석: 사용량 집계, 개인 정보 노출 없음.
- RevenueCat — 구독 상태: 활성 또는 만료됨, 그리고 어떤 요금제를 사용하고 있는지.
각 항목은 해당 항목에 명시된 내용만 담고 있으며, 보관소의 정보는 포함하지 않습니다. 제품이 변경될 때 목록도 변경되며, 이 섹션도 그에 따라 업데이트됩니다.
취약점 신고
여기에 설명된 내용에서 취약점을 발견했다고 생각되시면 hello@assuredauth.com으로 "보안"이라는 제목으로 이메일을 보내주세요. 사용하시는 플랫폼, 앱 버전, 그리고 발견 단계를 함께 기재해 주시면 감사하겠습니다. 본인의 데이터를 사용한 증거 자료면 충분하며, 타인의 데이터를 대상으로 테스트하지 마시기 바랍니다. 저희는 PGP 키를 제공하지 않으므로, 일반 이메일로 보고서를 전송하고 싶지 않으시면 첫 메시지에 미리 알려주시면 다른 방법을 안내해 드리겠습니다.
저희는 다음과 같은 사항을 약속드립니다. 3영업일 이내에 접수 확인을 해드리고, 작업 진행 상황을 지속적으로 알려드리며, 게시 전에 사실 여부를 확인하고, 원하시는 경우 출처를 명시해 드립니다. 아래 범위 내에서 선의로 진행된 연구에 대해서는 법적 조치를 취하지 않습니다.
적용 범위: iOS 및 Android 앱, 스마트워치 앱, 데스크톱 확장 프로그램, assuredauth.com 및 해당 API. 적용 범위 제외: 앱 스토어 및 구글 플레이 스토어 자체, 위에 나열된 제공업체, 소셜 엔지니어링 공격, 서비스 거부 공격.
현재 현상금은 없습니다. 신고에 대한 답변은 문제 해결과 감사 인사로 이루어지며, 금전적 보상은 없습니다.