SRP는 프로토콜에서 비밀번호를 보내지 않습니다. 이것은 비밀번호의 제거, 피싱에 대한 면역, verifier가 무해하다는 뜻과는 다릅니다.
패스키와 SRP는 서로 다른 두 가지 인증 방식입니다. 패스키는 키 쌍을 사용하며 비밀번호의 필요성을 없앨 수 있습니다. SRP는 여전히 비밀번호에 기반하지만, 프로토콜이 올바르게 구현되면 비밀번호를 알고 있음을 증명하기 위해 비밀번호 자체를 서버에 보내지 않습니다.
따라서 “비밀번호를 보내지 않는 로그인”과 “비밀번호를 갖지 않는 로그인”은 같지 않습니다. 이들 방식 중 하나를 선택할 때는 막연한 “영지식”이라는 이름이 아니라 피싱 위험, 자격 증명 관리, 복구, 구현 품질을 기준으로 삼아야 합니다.
패스키는 무엇을 바꾸는가?
패스키 기반 인증에서는 서비스가 공개키를 보관하고 사용자는 개인키를 통제하여 로그인을 승인합니다. 자격 증명을 해당 서비스 및 오리진과 연결하는 것은 이 방식의 피싱 저항성에서 중요한 부분입니다. FIDO의 패스키 설명.
모든 패스키가 반드시 클라우드에서 동기화되는 것은 아닙니다. 일부는 특정 기기나 보안 키에 묶여 있고, 일부는 자격 증명 제공자를 통해 기기 사이에서 이동합니다. 복구 모델과 동기화 보호는 해당 제공자를 기준으로 살펴봐야 합니다. “클라우드 동기화”라는 사실만으로 회사가 키를 읽을 수 있는 형태로 보관한다고 결론 내릴 수는 없습니다.
로그인 이후의 세션 보안도 별개의 문제입니다. 패스키가 기기의 악성코드나 유효한 세션의 탈취를 자동으로 무력화하지는 않습니다.
SRP는 서버에 무엇을 제공하는가?
SRP는 비밀번호 인증 키 교환 계열에 속합니다. 서버는 비밀번호 자체 대신 솔트와 검증자(verifier) 같은 데이터를 보관합니다. 양측은 프로토콜 메시지를 교환하여 비밀과 공유 키를 알고 있는지 확인합니다.
하지만 verifier는 무해한 데이터가 아닙니다. RFC 5054의 3.3절은 검증자를 얻은 공격자가 비밀번호를 추측하는 사전 공격을 수행할 수 있다고 명시합니다. 따라서 “데이터베이스가 도난당해도 오프라인 추측의 가능성은 전혀 없다”는 주장은 잘못입니다.
강력한 비밀번호, 서버 보호, 적절한 매개변수, 입력 검증, 로그인 시도 통제는 여전히 필요합니다. SRP는 비밀번호를 입력하는 페이지가 안전하다는 보장도 하지 않습니다. 악성 코드는 프로토콜이 실행되기 전에 비밀번호를 가로챌 수 있습니다.
공정한 비교
| 질문 | 패스키 | SRP |
|---|---|---|
| 사용자가 서비스 비밀번호를 기억하는가? | 보통은 아니지만 자격 증명에 대한 통제가 필요함 | 예, 비밀번호를 알고 있다는 사실에 의존함 |
| 서비스는 로그인을 위해 무엇을 보관하는가? | 공개키와 관련 정보 | 검증자와 관련 매개변수 |
| 피싱 저항성은 어떻게 확보되는가? | FIDO 설계에서 자격 증명을 서비스/오리진에 연결함 | 프로토콜에서 비밀번호를 보내지 않는 것만으로 가짜 입력 화면이 안전해지지는 않음 |
| 클라우드가 필수인가? | 아니며, 기기에 묶인 선택지도 있음 | 프로토콜 자체에 제3자 신원 제공자가 필수인 것은 아니지만 인증 서비스는 필요함 |
| 복구는 어떻게 이루어지는가? | 자격 증명의 종류와 제공자에 따라 다름 | SRP라는 이름이 아니라 계정과 제품의 정책이 결정함 |
이 표로 모든 구현에 절대적인 순위를 매길 수는 없습니다. 취약한 복구 절차는 강력한 로그인 방식의 이점을 약화시킬 수 있습니다.
계정 로그인과 채팅 키는 어떤 관계인가?
인증은 누가 활동할 권한이 있는지를 서비스에 알려줍니다. 메시지 암호화 키는 누가 내용을 열 수 있는지를 결정합니다. 제품이 이 둘을 연결할 수는 있지만, 그 관계는 문서로 설명되어야 합니다.
Livara 보안 문서에는 로그인용 SRP가 설명되어 있고 암호화된 신원을 위한 v7 복구 패키지는 별도로 설명되어 있습니다. 그 패키지는 신원을 복원하며 채팅 기록을 복원하는 것이 아닙니다. 따라서 “로그인 비밀번호가 맞다”는 것이 “모든 키와 예전 메시지가 돌아왔다”는 뜻은 아닙니다.
이 글은 개념적인 비교이며, Livara의 모든 로그인 방식에 대한 실제 시험이나 제품이 특정 RFC를 정확하게 구현했다는 인증이 아닙니다.
선택할 때 무엇을 물어야 하는가?
- 기기를 잃어버리면 대체 로그인 방법은 무엇이고 누가 통제하는가?
- 복구 방식이 주된 로그인 방식보다 약한가?
- 알 수 없는 세션을 어떻게 확인하고 무효화하는가?
- 로그인 방식을 바꾸면 메시지 키나 연결된 기기가 바뀌는가?
- 자격 증명 동기화에는 어떤 계정과 어떤 독립적인 보호가 필요한가?
요약: 패스키를 본질적으로 “클라우드이므로 안전하지 않다”고 부르거나 SRP를 “영지식이므로 침해에 면역이다”라고 부르지 마세요. 각 방식의 경계와 제품의 복구 정책이 신뢰할 수 있는 비교의 토대입니다.
