SRP는 로그인 교환에서 비밀번호를 보내지 않지만, 도난당한 검증자를 무해하게 만들지는 않습니다.
Secure Remote Password, 즉 SRP는 일반적인 프로토콜 교환 중에 비밀번호를 보내지 않고도 클라이언트와 서버가 비밀번호를 이용해 인증할 수 있게 합니다. 원래라면 로그인 과정에서 비밀번호를 받았을 서버에 대한 노출을 줄일 수 있습니다.
그렇다고 서버에서 비밀번호와 관련된 모든 비밀이 없어지는 것은 아닙니다. 서버는 검증자를 보관하며, 도난당한 검증자는 오프라인 비밀번호 추측에 사용될 수 있습니다. “영지식 로그인”이라는 주장을 평가할 때 이 차이는 핵심적입니다.
기존 비밀번호 로그인과 무엇이 달라지나요?
기존 설계에서는 클라이언트가 인증된 TLS 연결을 통해 비밀번호를 보냅니다. 잘 설계된 서버는 적절한 솔트가 적용된 비밀번호 해시를 비교하고, 인증 정보를 로그에 남기지 않으며, 추측 공격 방어를 적용합니다. TLS는 연결을 보호하고 비밀번호 해시는 저장된 인증 정보를 다른 방식으로 보호합니다.
SRP는 교환 과정을 바꿉니다. 등록 시 시스템은 솔트와 검증자 자료를 만듭니다. 로그인할 때 양측은 새로운 프로토콜 값과 각자의 비밀을 이용해 공유 키 자료를 설정하고 확인합니다. 클라이언트는 비밀번호를, 서버는 검증자를 사용합니다. 정직하게 동작하는 클라이언트는 비밀번호 자체를 로그인 페이로드로 제출하지 않습니다.
RFC 2945의 SRP 명세는 프로토콜의 기초를 설명합니다. 후속 프로파일과 구현은 정확한 매개변수와 메시지 검사를 검토해야 합니다. 설계를 “SRP”라고 부른다고 모든 구현 선택이 타당하다는 뜻은 아닙니다.
| 질문 | 기존 TLS 기반 비밀번호 로그인 | 올바르게 구현된 SRP 교환 |
|---|---|---|
| 로그인 시 애플리케이션 서버가 입력한 비밀번호를 받나요? | 일반적으로 받음 | 프로토콜 교환의 일부로는 받지 않음 |
| 어떤 민감한 인증 자료를 저장하나요? | 보통 솔트가 적용된 비밀번호 해시 | 솔트와 비밀번호에서 유도한 검증자 |
| 도난당한 데이터베이스로 오프라인 추측이 가능한가요? | 저장된 자료에 따라 가능 | 가능. 도난당한 SRP 검증자 자료로 추측할 수 있음 |
| 키로거를 막아 주나요? | 아니요 | 아니요 |
| 메시지 기록을 자동으로 암호화하나요? | 아니요 | 아니요 |
도난당한 검증자가 여전히 중요한 이유
RFC 5054의 3.3절은 검증자 도난을 명시적으로 다룹니다. 검증자를 통해 공격자가 서버를 사칭하고 사전 공격으로 비밀번호를 복구할 수 있다고 설명합니다.
중요한 차이는 검증자가 단순히 재사용 가능한 클라이언트 로그인 토큰은 아니라는 점입니다. 그렇다고 무해한 것은 아닙니다. 공격자는 가능한 모든 비밀마다 이산 로그 문제를 푸는 대신 도난당한 자료에 후보 비밀번호를 대입해 시험할 수 있습니다. 약하거나 재사용한 비밀번호는 여전히 심각한 위험입니다.
온라인 요청 속도 제한은 실제 서비스에 대한 시도를 늦출 수 있지만, 도난당한 데이터베이스를 대상으로 수행하는 계산에는 적용되지 않습니다. 데이터베이스 보호, 신중한 비밀번호 처리, 강력하고 고유한 비밀번호는 여전히 중요합니다.
SRP가 보호하지 못하는 것
침해된 엔드포인트: 악성코드는 프로토콜이 시작되기 전에 비밀번호를 수집하거나 인증 후 세션을 훔칠 수 있습니다.
악성 로그인 페이지: 비밀번호를 요구하는 페이지 자체가 적대적이라면 입력한 텍스트를 다른 곳으로 보낼 수 있습니다. 웹 애플리케이션에는 여전히 신뢰할 수 있는 전달 경로가 필요합니다.
모든 복구 경로: 계정 접근을 허용하는 이메일, SMS, 지원 절차에는 각각 별도의 요구 사항이 있습니다. 가장 강력한 일반 로그인 방식도 더 약한 대체 경로 때문에 무력화될 수 있습니다.
모든 능동적 네트워크 공격: 프로토콜 매개변수, 입력 검증, 상호 확인, 주변의 인증된 연결이 중요합니다. “비밀번호는 절대 이동하지 않는다”는 구호로 해당 배포 환경에 규정된 TLS 보호를 대체하지 마세요.
메타데이터 또는 채팅 암호화: 인증은 세션의 진입을 허용해야 하는지 답합니다. 어떤 대화 기록이 존재하는지 또는 누가 메시지 복호화 키를 보유하는지를 결정하지는 않습니다.
Livara가 로그인과 신원 복구를 분리하는 방식
Livara의 보안 개요는 SRP 인증을 LVR1 메시징 프로토콜과 별개로 설명합니다. 또한 별도의 무작위 256비트 복구 키로 보호하는 버전 7의 암호화된 신원 백업을 문서화합니다.
백업은 업로드 전에 암호화해 봉인하며, 채팅 기록이 아닌 암호학적 신원을 복원합니다. 계정 비밀번호만 알아서는 해당 암호화 키를 복원하지 못합니다. 반대로 지원팀이 암호화 비밀을 재구성할 수 없다는 설명만으로 계정 관리 작업이나 비밀번호 변경 절차가 전혀 존재할 수 없다고 결론 내릴 수도 없습니다.
위협 모델은 기기 침해와 관찰 가능한 통신 메타데이터도 범위 안에 둡니다. SRP를 이유로 전체 서비스가 사용자 활동의 모든 측면에 대해 “영지식”이라고 다시 이름 붙여서는 안 됩니다.
실용적인 평가 체크리스트
사용자는 강력하고 고유한 비밀번호를 선택하고, 기기를 보호하고, 복구 자료를 적절한 별도 장소에 보관하며, 세션을 철회하는 방법을 이해해야 합니다. 신뢰할 수 없는 사이트가 SRP를 쓴다고 주장한다는 이유만으로 비밀을 입력하지 마세요.
기술 검토자는 정확한 프로토콜 프로파일, 비밀번호에서 검증자로의 처리, 입력 검증, 실패 처리, 등록 흐름, 재설정 설계를 요청해야 합니다. 클라이언트와 서버를 함께 검토하세요. 로그인 성공 테스트에만 의존하지 말고, 잘못된 공개 값, 재전송 공격, 중단된 세션에 대한 테스트도 포함하세요.
SRP는 인증 과정에서 비밀번호 공개를 제한하는 유용한 도구입니다. 비밀번호 보안 문제의 종결로 제시하기보다, 검증자 도난, 엔드포인트 침해, 복구 위험과 함께 실제 장점을 설명할 때 그 가치가 더 분명해집니다.
