4P by GN⁺ | ★ favorite | 댓글 1개
  • 시스템 내부의 장기 계정 ID를 만들 때 OIDC가 이메일 주소를 돌려준다는 이유만으로 영구 ID로 쓰면 변경과 재사용 문제를 함께 떠안게 됨
  • 이메일 주소는 한 조직 안에서도 이름이나 로그인처럼 바뀔 수 있어, 계정의 기준값으로 삼기에는 안정적이지 않음
  • 예전 주소로 메일 접근이나 전달이 남아 있더라도, 그 주소가 OIDC 인증 같은 비메일 용도에서 계속 작동한다는 보장은 없음
  • 계정 복구에는 이메일 주소가 필요할 수 있지만, 인증 시스템이 별도의 고유하고 영구적인 ID를 제공한다면 내부 ID로는 그 값을 써야 함
  • 사용자에게 보이지 않는 값이라도 계정 내부 식별자는 의미 없는 ID로 두는 편이 장기 운영과 보안 측면에서 단순함

이메일 주소를 영구 ID로 쓰고 싶어지는 이유

변경될 수 있는 주소는 기준값이 되기 어려움

  • 가장 큰 문제는 이메일 주소가 변경될 수 있음
    • 한 조직 안에서도 사람의 이메일 주소는 바뀔 수 있음
    • 사람의 일상적으로 쓰는 이름이나 로그인이 바뀌는 이유와 같은 종류의 이유로 변경될 수 있음
    • 조직이 할당한 이메일 주소의 변경이나 재발급을 거부하는 것은 여러 곳에서 법적으로 지속되기 어려울 만큼 가혹할 수 있음
  • 예전 이메일 주소가 완전히 사라지지 않더라도 영구 식별자로는 부족함
    • 예전 주소로 접근하거나 포워딩이 남아 있을 수 있음
    • 그래도 예전 주소가 OIDC 인증 같은 비메일 용도에서 계속 작동하지 않을 수 있음
    • 사용자는 불편할 수 있는 예전 이메일 주소 대신 현재 새 주소를 쓰고 싶어함

재사용과 복구 이메일은 별도로 다뤄야 함

  • 더 작은 문제로, 조직이 이메일 주소를 재사용하지 않는다는 보장이 없음
    • 일반적으로 재사용될 수도 있음
    • 특히 선호도가 높은 주소는 영향력 있는 사람이 원해 예외적으로 재사용되거나 재할당될 수 있음
  • 계정 복구가 등록된 이메일 주소를 통해 이뤄져야 하는 경우에는 이메일을 저장해야 할 수 있음
    • 하지만 OIDC처럼 이론상 고유하고 영구적인 내부 ID가 있는 경우에는 그 내부 ID를 써야 함
  • 계정 복구용 이메일을 저장해야 하더라도, 계정의 내부 식별자는 의미 없는 ID여야 함
    • 이 값이 사용자에게 노출되지 않더라도 장기적으로 운영이 더 단순해짐
  • 이메일 주소에 지나치게 많은 의미를 부여하면 보안 문제도 숨어 있을 수 있음

댓글과 토론

Hacker News 의견들
  • 좋은 신원 식별자는 없음
    이메일은 바뀌고, 예전 이메일 접근 권한을 잃기도 함
    사용자명도 싫어하는 사람이 많아서 user53267 같은 무의미한 고유 이름보다, 고유하지 않은 이름을 고르고 싶어함
    기기도 잃어버리기 때문에 쿠키에 비밀 UUID를 저장하거나 기기의 패스키를 쓰는 것만으로는 해결되지 않음
    이상적인 해법은 없고 여러 방식을 섞어야 함. 어떤 사람에게는 이메일이 오래 안정적이고 신원 식별자로 좋지만, 다른 사람에게는 사용자명이 안정적이라 그쪽을 선호함. 다만 수십 년은커녕 몇 년 넘게 같은 주 기기를 쓰는 사람은 거의 못 봐서, 기기 기반 식별은 아마 잘 안 될 듯함
    특히 직장 이메일 first.last@company.com에서 자주 드러남. 많은 벤더 소프트웨어가 Sign in with Google을 쓰고, 그 이메일 주소를 벤더 앱 안의 식별자로 저장함
    결혼, 이혼, 트랜지션, 문화권 이동, 새 이름 선택 등으로 이름은 바뀌고 이메일 주소도 바뀜
    어쩌면 OIDC 같은 것에는 사용자명 변경 표준 API와 이메일 주소 변경 표준 API 같은 새 확장이 필요함

    • 접근 가능한 가장 오래된 이메일은 20년 이상 됐음. 지금은 쓰지 않지만, 지금까지의 어떤 전화번호나 실제 주소보다 오래됨
      공식 신분증이나 사회보장번호 같은 공적 식별자를 제외하면 이보다 더 낫게 하기는 어려워 보임
    • 사람에게는 모든 것을 잃고 새 삶을 시작할 권리도 있음. 불과 몇십 년 전에는 실제로 가능했던 일임
    • OIDC는 이미 sub 클레임이 재할당되지 않고 고유해야 한다고 요구해서 이 문제를 다룸: https://openid.net/specs/openid-connect-core-1_0.html#IDToke...
      물론 이는 ID 토큰의 sub에 이메일 주소를 넣으면 안 된다는 뜻임
    • 이런 이메일 변경 중 가장 “좋아하는” 경우는 계약직 접미사 변경처럼 스스로 만든 문제임
      직원으로 전환되면 완전히 새 계정을 만들어야 하는 회사를 겪었고, 단순하고 단일화된 권한 시스템이 없어서 전환 직후에는 전날까지 접근하던 시스템 권한을 되찾는 데 3주쯤 걸림
      더 재미있는 건 그 회사가 고객에게 복잡한 계정 체계를 제공하는 사업을 많이 하고, 이런 문제를 쉽게 처리하는 외부용 신원 시스템도 갖고 있다는 점임. 정작 그 외부용 신원 시스템을 유지하는 내부 직원에게는 적용하지 않음
    • Discord의 예전 방식, 즉 이메일과 표시 이름을 따로 두는 구조가 좋았음
      모두에게 숫자가 붙어 있었으니 숫자는 별 의미가 없었음. 고유 계정 ID로 바뀌었을 때 좀 아쉬웠고, 왜 바꿨는지는 아직도 궁금함
  • 개인으로서 이 문제를 다루는 최선의 접근은 뭘까?
    Gmail은 AI 알고리즘 때문에 갑자기 잠기거나 계정이 금지될 수 있고, 뭔가 잘못돼도 구제 수단이 없음
    Yahoo는 최근 로그인할 때 15년 동안 접근 못 한 비활성 이메일로 인증하라고 요구해서 접근을 잃었음. 운 좋게 이메일 클라이언트에는 접근할 수 있어서 중요한 계정들을 옮길 수 있었음
    Yahoo/AOL/Tutanota/Protonmail/그 외 다수는 충분히 자주 로그인하지 않으면 계정을 자동 삭제함. Protonmail은 아직 아니지만 약관상 허용하고 있음
    자체 호스팅도 애초에 모든 인프라에 이메일이 필요함. 그 이메일 접근을 잃으면 결제 알림도 놓치고 호스팅 계정도 잃을 수 있음. IMAP을 지원하지 않아 거의 확인하지 않는 이메일로 결제 알림이 가서 도메인을 잃을 뻔했음. 전문 시스템 관리자이고 유지보수 시간이 충분하지 않으면 해킹 위험도 더 커짐
    Duo 푸시는 휴대폰이 망가지면 끝이고, SMS 인증은 휴대폰 파손, 요금제 접근 상실, 내부 직원의 코드 유출 같은 문제가 있음
    결국 대학 Gmail 주소를 쓰기로 했음. 졸업생도 계속 보유할 수 있다고 약속했고, 뭔가 잘못되면, 아마 휴대폰 분실로 2단계를 잃는 경우겠지만, 괜찮은 졸업생 지원 센터가 있음
    어딘가에 대화할 수 있는 사람 지원 창구가 꼭 필요함. 그래도 이게 최선인지는 확신이 없고, 여전히 Google 쪽 위험이 남아 있는지 궁금함

    • 빠뜨린 최선의 해법은 자기 도메인과 Gmail 같은 호스팅 이메일을 쓰는 것임
      말한 것처럼 잠기면 “그냥” 제공자를 바꾸면 되고, 많아야 몇 시간치 이메일만 잃음
    • iCloud는 어떨까? 이론상 계정 금지는 가능하겠지만, 적어도 Apple은 대체로 구제 수단이 있고 사람과 이야기할 수 있다는 느낌이 있음
  • 이메일이 영구 식별자로 좋지 않다는 데 동의함. 다만 식별의 일부로 전화번호를 쓰는 건 더 나쁨
    자기 도메인으로 거의 20년 같은 이메일을 써 왔지만, 같은 기간 전화번호는 거의 12개쯤 바뀌었음. 웹사이트가 예전 번호로 2단계를 켜 두었거나, 애초에 그 사이트에 예전 번호를 등록했다는 사실을 잊은 경우를 자주 봄
    해외 거주 중에도 아직 그 번호로 로그인 코드를 받는 사이트들 때문에, 그리고 버리면 업데이트를 잊었거나 미국 번호가 필요해서 바꿀 수 없는 중요한 서비스 접근을 잃을까 봐 AT&T에 매달 약 150달러 세금을 내며 미국 번호를 유지 중임

    • DIDww 같은 VoIP 업체로 번호를 이전하면 월 2.50달러로 유지할 수 있고, 원하면 받은 SMS를 받은편지함으로 보낼 수도 있음
      나중에 다시 모바일 계정에서 그 번호를 쓰고 싶으면 원하는 통신사로 다시 이전하면 됨
    • 해외에서 쓰려고 미국 번호를 유지하는 데 그렇게 많이 낼 필요는 없음
      가능한 2단계 인증은 Google Authenticator 같은 앱으로 바꾸고, 번호는 Google Voice로 옮기면 예전 번호로 문자를 무료로 받을 수 있음
      Google을 아예 엮고 싶지 않다면 다른 시간 기반 인증 앱도 많고, 문자용으로 www.tossabledigits.com을 쓸 수도 있음
    • 왜 그렇게 많이 내는지 모르겠음. 번호를 VoIP 제공자로 이전하면 월 몇 달러면 됨
      일반 휴대폰 서비스로 봐도 과한 금액임. 두 회선에 월 100달러도 안 냄
    • VoIP로 옮겨 보라는 데 동의함
      예전에 이사할 때 개인 사무실 전화번호가 새 지역에서 허용되지 않았지만 VoIP 계정으로 이전할 수 있어 운이 좋았음
      당시에는 인터넷이 느려서 한동안 이더넷 전화 어댑터를 쓰다가, 이후에는 그 번호를 수신 전용으로만 사용함. 음성 통화와 팩스는 모두 이메일로 전달됨
      20년 넘게 잘 작동하고 있음. 연결할 기기가 없어서 연간 비용도 꽤 낮음
      언젠가 전화기를 연결해 최신 인터넷을 활용할 수도 있겠지만, 지금 방식이 마음에 들고 특정 위치에 묶이지 않는다는 점이 좋음
    • 통신사를 바꾸더라도 전화번호는 가져갈 수 있음. 이메일 주소는 그렇지 않음
  • 내 경험도 같음. 개인적으로는 무작위 UUID가 가장 낫다고 봄
    사용자의 최초 이메일 해시조차 이상적이지 않음. 솔팅만으로 충분하지 않을 수 있고, 다른 사람들이 어떤 입력 이메일도 안전하게 해시해도 된다고 가정할 수 있기 때문임

    • 데이터베이스 수업에서 배운 자연 키 같은 게 합리적인 경우가 있긴 할까?
      실무에서는 항상 자동 증가 정수나 무작위 문자열/UUID를 기본 키로 씀
    • 식별자가 “영구적”이길 보장하는 유일한 방법은 사람들이 바꿀 이유가 전혀 없게 고르는 것임
      전화번호, 이메일 주소, 주민등록식 국가 ID, 이름, 지문처럼 사람들이 신경 쓰는 현실 세계 속성과 아무 관계가 없어야 함
      무작위 문자열은 이 조건에 딱 맞음. 순차 정수도 괜찮지만 추측하기 쉬우므로 추가 보안 조치가 필요할 수 있음
    • UUID보다는 순차 UID를 선호하지만, 핵심은 여전히 같음
  • 공개 키 이메일 주소를 지원하면 어떨까? 예를 들어 . 같은 것과 . 같은 것을 둘 다 동등하게 취급하는 방식임
    한쪽으로 가입한 뒤 다른 쪽으로도 로그인하거나 계정 복구를 할 수 있게 함. Google이 나를 금지하거나 Hotmail이 망해도, 다른 서비스에 가서 개인 키로 인증해 같은 계정을 열 수 있음
    당연히 편한 이름을 쓰기 위한 별칭 절차가 필요하겠지만, 메일 클라이언트가 그런 주소를 매핑하거나 최소한 공개 키와 함께 추적해야 할 것 같음
    종단 간 암호화 이메일을 끼워 넣는 계기가 될 수도 있음. 이건 대규모로 자리 잡은 적이 거의 없었음
    실제로 작동하려면 큰 업체들이 지원해야 하겠지만, 짧게 생각해 보면 꽤 탄탄해 보임. 아직 아무도 지원하지 않는다는 점만 빼면

    • 이 스레드에서 Decentralized Identity Foundation이 아직 안 나온 게 놀라움: https://identity.foundation/
      제공자나 중앙 권위에 의존하지 않고, 자신이 신원을 소유하는 방식으로 웹에서 식별하고 소통하는 새 방법들이 만들어지고 있음
  • 이전 에너지 공급사인 British Gas(Centrica 소유)는 이메일 주소 하나를 두 개 이상의 실제 주소에 쓰는 걸 허용하지 않았음
    이사 후 온라인 계정을 “설정”하려고 했더니 현재 주소 상세 정보를 볼 때마다 HTTP 500이 났음
    전화로 문의하니, 이전 주소의 에너지 계정이 닫혀 있어도 “같은 이메일 주소를 여러 우편 주소에 쓸 수 없다”고 했음

    • +whatever 트릭을 쓸 수 있음. Gmail이면 점 . 트릭도 가능함
    • 나쁜 방식이긴 하지만, 이메일에 자기 도메인을 쓰면 실제 문제는 아님
  • 지금 계정 하나에 여러 연결 이메일 주소를 허용하도록 이메일 시스템을 바꾸는 중임
    주요 이유 중 하나는 학생 할인을 제공하기 때문임. 계정에 할인을 적용하는 가장 쉬운 방법은 이메일이 교육기관 주소인지 확인하는 것임. .edu, .ac.uk 같은 것들임
    그런데 대부분은 실제로 그 이메일로 가입하고 싶어 하지 않는 듯함. 여러 이메일을 허용하면 양쪽 장점을 모두 얻을 수 있음
    처음부터 이렇게 했으면 좋았을 것 같음

    • 미국에서는 대학을 졸업한 뒤에도 .edu 졸업생 전달 주소를 받을 수 있는 사람이 많다는 점을 알아둬야 함
      꽤 멋진 주소를 하나 갖고 있음. 일찍 신청해서 그냥 내 이름만 들어간 주소임
      다만 많이 쓰지는 않음. 초창기에는 전달이 가끔 불안정했지만 지금은 더 나아졌을 거라고 봄
      현실적으로 내 Gmail 주소가 이미 수십 년 가까이 안정적이었고, 바뀔 것 같지도 않음
      어쨌든 내 edu 주소는 아주 적은 사람에게만 알려줌
  • 가장 우아하진 않아도 클라이언트 쪽 해법은 있음
    도메인을 직접 비용 내고 유지하면 이메일 별칭을 100% 통제할 수 있음
    현재 제공자인 Google이 망하더라도 직접 메일을 호스팅해서 계정을 복구하고 별칭 소유권을 유지할 수 있음

    • 도메인이 만료되면 어떡함?
  • 이건 백엔드 문제라고 봄. 사용자에게 보이는 ID는 이메일일 수 있지만, 시스템 데이터 안의 기본 키가 이메일이면 안 됨
    아직도 이렇게 하는 곳이 있나? 이메일 같은 것을 식별자로 쓰지 말고, 진짜 고유 ID(UUID나 시퀀스 기반 자동 증가값)에 매핑하는 조회 테이블을 두는 건 가장 기본적인 데이터베이스 설계 문제임
    글에서는 이 구분을 잘 하지 않아서, 사용자가 이 추상화를 인식해야 한다는 식으로 읽히기도 함

    • 맞음. 이건 고등학교 수준 데이터베이스 수업 시험 문제 같은 건데, 생각보다 많은 성인 개발자가 데이터베이스 쪽을 멈춰서 생각하지 않음
  • 영원한 것은 없음. 인간의 전체 수명 동안 안정적인 것조차 거의 없음
    쉽게 스캔 가능한 생체 표지도 충분히 큰 인구 집단에서는 안정적으로 고유하지 않음
    이메일 주소는 꽤 긴 기간 동안 안정적으로 고유하기 때문에 이런 용도로 선택됨
    전화번호도 예전보다 더 끈적한 식별자가 됐고, 이제는 유용한 식별자로서 이메일과 비슷해짐
    이메일과 전화번호는 둘 다 자주 잃어버리며, 종종 동시에 잃음
    백업 이메일 주소가 답임
    GitHub는 신원 처리를 잘하는 편이라고 보지만, 아직도 비밀번호를 쓰고 있음. 비밀번호는 나쁨