Password Managers는 왜 이메일이 필요할까요?

Source: Dev.to

비밀번호 관리자가 이메일을 요구하는 이유

인기 있는 비밀번호 관리자를 포함한 온라인 서비스를 한 번이라도 가입해 본 적이 있다면, 모두 이메일을 요구한다는 것을 눈치챘을 것입니다. 이는 여러 이유로 표준적인 관행입니다:

• 뉴스레터
• 계정 복구 옵션
• 분석, 마케팅 및 기기 간 동기화

불투명 식별자를 대안으로 사용하기

이메일 주소를 기본 식별자로 사용하는 대신, 시스템은 각 사용자에게 불투명 식별자—무작위 문자열—를 생성할 수 있습니다. 이 접근 방식은 저장되는 개인 식별 정보(PII)를 최소화함으로써 프라이버시를 더욱 강조합니다.

보안 향상 방식

• 자격 증명 스터핑 완화: 공격자는 다른 사이트에서 유출된 이메일/비밀번호 조합을 재사용하는 경우가 많습니다. 무작위 식별자를 사용하면 유출된 이메일만으로는 동일한 계정을 다른 곳에서 타깃팅할 수 없습니다.
• 침해 가치 감소: 이메일이 없는 데이터베이스는 스팸 전송이나 판매가 가능한 활성 이메일 목록이 없기 때문에 해커에게 매력도가 낮아집니다.
• 계정 열거 제한: 식별자가 충분히 무작위인 값(예: UUIDv4)이라면, 유효한 ID를 추측하는 것이 계산적으로 불가능에 가깝습니다.

불투명 식별자의 단점

• 사용자 책임: 이메일 복구 수단이 없으므로 사용자는 로그인 자격 증명을 기억하거나 안전하게 보관해야 합니다.
• 복구 어려움: 기존 이메일 기반 비밀번호 재설정이 불가능합니다. 한 가지 대안은 가입 시 복구 키를 생성하고 사용자가 이를 안전하게 보관하도록 하는 것입니다.

이메일 vs. 불투명 식별자 선택

결정은 시스템의 보안 요구 사항에 따라 달라집니다:

• 저위험 서비스(예: 단순 포럼)는 무작위 사용자 이름으로부터 큰 이점을 얻지 못할 수 있습니다.
• 고위험 서비스(예: 비밀번호 관리자)는 이메일을 기본 식별자로 사용하지 않음으로써 사용자 신뢰를 얻고 특정 공격군을 차단할 수 있습니다.

구현 예시

가능한 설계 중 하나는 데이터베이스의 GUID를 AccountId로 사용하는 것입니다. 무작위 UUIDv4로 생성된 경우, 이 식별자는 열거 공격에 대한 강력한 보호를 제공합니다.

-- Example: Creating a user with a UUIDv4 as the primary identifier
INSERT INTO users (account_id, password_hash, recovery_key)
VALUES (uuid_generate_v4(), :password_hash, :recovery_key);

열린 질문

현재 학사 논문 프로젝트의 일환으로 이 불투명 식별자 모델을 구현하고 있으며, 다른 개발자들의 피드백을 받고 싶습니다:

• 불투명 AccountId가 제공하는 보안 및 프라이버시 향상이 사용자에게 추가되는 책임을 감당할 만큼 가치가 있을까요?
• 아니면 이메일 기반 로그인 편의성이 너무 커서 포기하기 어려운가요?