매직/트래직 이메일 링크를 유일한 로그인 옵션으로 만들지 말아야 함

 (recyclebin.zip)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 이메일로 로그인 링크를 보내는 매직 링크는 비밀번호 피싱과 재사용 비밀번호 유출 위험을 줄일 수 있지만, 단독 옵션이 되면 사용자에게 로그인 마찰이 전가됨
  • 여러 컴퓨터를 쓰거나 업무용·개인용 기기를 분리하는 사용자는 이메일을 받은 기기와 로그인하려는 브라우저가 달라 흐름이 쉽게 끊김
  • SMTP 지연과 링크 전달 과정 때문에 로그인은 2초에서 수분까지 늦어질 수 있고, 인앱 브라우저와 RSS 리더 앱에서는 모바일 사용성도 깨질 수 있음
  • 이메일이나 SMS로 받은 OTP를 직접 입력하는 방식도 번거롭지만, 이메일 클라이언트와 브라우저 사이에 링크를 옮기기 어려울 때는 매직 링크보다 나을 수 있음
  • 매직 링크를 기본값으로 쓰더라도 기술적이고 프라이버시를 중시하는 사용자층에는 passkeys 같은 견고한 대안을 함께 제공해야 함

매직 링크가 불편해지는 상황

  • “Magic Links”는 과거 미래형 PDA를 뜻했지만, 지금은 Auth0 같은 회사가 이메일에 포함된 로그인 링크를 가리킬 때 쓰는 말임
  • 404 Media는 “We Don’t Want Your Password”에서 매직 링크를 옹호하며, 이메일 링크가 비밀번호보다 피싱이 어렵고 비밀번호 유출로 이어지지 않으며 유출된 비밀번호 재사용 위험도 줄인다고 봄
  • 단일 노트북과 모바일 기기 중심의 생활에서는 쉬워 보여도, 여러 기기와 브라우저를 쓰는 사용자에게는 복잡도가 그대로 넘어감
  • 불편한 사례:
    • 여러 기기: 게임용 PC나 업무용 노트북에 개인 이메일을 두지 않는 사용자는 로그인 링크를 바로 열기 어려움
    • 속도: SMTP 지연과 올바른 브라우저로 링크를 옮기는 과정 때문에 2초에서 수분까지 느려질 수 있음
    • 모바일: 인앱 브라우저 사용이 깨져 RSS 리더 앱에서 로컬 링크를 다루기 불편해짐
    • 보안: 개인 이메일을 업무 기기에서 열거나 그 반대로 유도하는 흐름은 보안상 이점이 아님

대안과 최소한의 보완

  • 이메일 또는 SMS로 받은 OTP를 직접 입력하는 passwordless 방식도 불편하지만, 이메일 클라이언트에서 로그인할 브라우저로 링크를 쉽게 옮길 수 없는 상황에서는 더 실용적일 수 있음
  • Stratechery는 Passport를 통해 링크 클릭 또는 OTP 입력을 제공하며, passkeys 구현 없이 불편을 사용자에게 넘기는 한계가 있지만 매직 링크 단독보다는 사용자 상황을 더 고려함
  • 매직/트래직 링크를 기본값으로 고집하더라도, passkeys 같은 견고한 대안을 함께 제공하는 편이 좋음
  • Ricky Mondello의 Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over는 passkeys로 이 문제를 완화하는 방법을 다룬 참고 글임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 매직 링크로 앱을 만들면서 겪은 문제들: 사용자가 이메일 접근이 불편한 기기에서 로그인해야 할 수 있으니 대체 로그인 코드를 매직 링크에 포함해야 함
    또한 이메일 클라이언트가 미리보기 스크린샷을 만들려고 링크를 자동으로 여는 경우를 처리해야 하고, 사용자가 선호하는 브라우저 대신 인앱 브라우저로 여는 이메일 클라이언트도 고려해야 함
    예를 들어 iOS 사용자는 Firefox 모바일을 선호해도 이메일 앱이 Safari 기반 인앱 브라우저로 강제로 열 수 있음

    • 피싱 방지 소프트웨어, 회사 링크 검사기 등과 함께 동작하도록 매직 링크 구현을 맞추느라 꽤 고생했고, 그 과정 일부가 https://github.com/FusionAuth/fusionauth-issues/issues/629에 정리돼 있음
      일회용 코드 입력 페이지로 연결하는 방식이면 이런 문제를 많이 피할 수 있다고 봄
    • 요즘은 Microsoft Defender in Exchange Online 같은 메일 위협 보호 도구가 검사 목적으로 메일 안의 링크를 클릭한다는 점도 고려해야 함
      최근 새 메일 계정이 자동으로 확인되고, 사용자가 클릭할 때는 매직 링크가 이미 무효가 되는 문제를 겪었는데, Microsoft가 검사 중에 그 링크로 먼저 로그인했기 때문이었음
    • 모바일에서는 로그인 링크가 모바일 앱과 제대로 연결되는지도 확인해야 함
      McDonald's가 이메일/비밀번호에서 매직 링크로 바꾼 뒤 McD 앱에서 링크를 동작시키기가 정말 어려웠고, 보통 McD 웹사이트만 열렸음
      McD를 먹을 때 98% 정도는 앱으로 주문할 수 없으면 안 먹는 편이라 꽤 짜증났고, 결국 “Sign in With Apple”(SIWA)로 갈아탔음
      기존 McD 계정에 SIWA를 추가하는 방법을 찾지 못해서 실제 이메일을 McD에 숨기는 SIWA를 써야 했고, 새 계정이 만들어져 예전 계정의 리워드 포인트는 잃었지만 적어도 다시 McD 앱은 쓸 수 있게 됨
      앱에는 매주 금요일 1달러 이상 주문 시 “Free Medium Fries on Friday” 딜이 있어서, 금요일 점심마다 집에서 샌드위치를 만들고 McD에서 쿠키와 무료 감자튀김을 받아 곁들이곤 함
    • Slack에서 최근 짜증났던 점은 회사 채팅은 휴대폰에 두고 싶었지만, 휴대폰에 회사 이메일은 두고 싶지 않았다는 것임. 휴대폰에 대한 제어 권한이 너무 넓기 때문임
      그래서 회사 컴퓨터에서 매직 링크를 받고 QR 코드를 만들었는데, 이메일 격리 시스템이 전체 링크를 바꿔놔서 원본을 추출해야 했음
      거기서 끝이 아니라 Slack으로 돌아가는 리디렉션 URL이 URL 인코딩 때문에 깨져 있어서 직접 고친 뒤 QR 코드를 만들어야 했음
      그냥 원래 매직 링크 이메일에 QR 코드나 코드를 같이 넣어주면 될 일임
    • 매직 링크의 가장 큰 장점 중 하나는 패스키와 달리 쓰기 쉬우면서도 피싱이 불가능하다는 점임
      코드를 넣는 순간 그 장점은 완전히 사라지고, 공격자는 코드를 요구하는 가짜 웹사이트만 만들면 됨
      매직 링크는 클릭한 기기에서 로그인되어야지, 로그인 세션을 요청한 기기에서 로그인되면 안 됨
      그 외의 방식은 조금 덜 귀찮을 수는 있어도 보안 문제이고, 그렇게 다뤄야 함

  • 몇 년 동안 매직 링크를 써왔고, MVP 단계에서 사용자 비밀번호 저장이라는 보안 부담을 피하려는 이유도 있었음. 가장 큰 문제는 일부 사용자 약 0.1%가 이메일을 아예 못 받는다는 것임
    자체 IP, MailGun, PostMark, 여러 트랜잭션 메일 도구를 순차 재시도하는 방식까지 써봤지만, 여전히 절대 로그인할 수 없는 사람들이 있음
    또 사람들이 6개월 전 매직 링크를 클릭하고 “안 된다”며 답답해하므로, 오류 메시지 대신 Docusign처럼 상황을 설명하고 링크를 다시 보내는 페이지를 보여주기로 함
    사람들은 이메일 주소를 자주 틀리게 입력한 뒤 코드를 못 받으면 시스템 탓을 하기도 함
    그래도 이메일+비밀번호 방식보다 지원 티켓은 훨씬 적다고 느껴서 여전히 매직 링크를 선호함

    • 이메일 주소를 틀리게 쓰거나, 받은편지함이 너무 가득 차서 더 이상 메일을 못 받는 사람이 꽤 많다는 점이 흥미로움
      매직 링크는 써본 적 없지만 몇 달 전 SaaS에 Google Sign in을 추가했더니 신규 가입의 90% 이상을 차지하게 됨
      사용자층이 개발자라 기술 이해도와 개인정보 민감도가 높은 편인데도 그렇고, 이제 다른 방식이 우선순위라고는 생각하지 않음. 물론 이메일/비밀번호는 여전히 유지함
    • 매직 링크는 유용할 수 있지만, 일부 사용자에게는 매직 링크만 지원하는 것이 문제임
    • 웃긴 건 이런 문제 대부분이 비밀번호에도 똑같이 적용된다는 것임. 예전 비밀번호를 쓰고 안 된다고 불평하거나, 뭔가 잘못 입력해놓고 시스템 탓을 하거나, 비밀번호 재설정 메일을 요청했는데 메일을 못 받는 식임. 그래서 장점만 보임
    • 하지만 사용성은 악몽임
    • 이메일은 안전한 채널로 봐서는 안 됨
      비밀번호 관리자와 함께 쓰는 사용자명+비밀번호 또는 패스키가, HTTPS 위에서 일반 대중에게 좋은 사용자 경험을 주면서 자격 증명을 종단 간 암호화 방식으로 교환하는 거의 유일한 방법일 가능성이 큼
      비밀번호 관리자는 자격 증명이 올바른 도메인에서만 쓰이도록 보장해줌

  • Mercury의 충성 고객이었지만, 안전한 비밀번호와 비밀번호 관리자, 유효한 TOTP까지 통과한 뒤에도 IP 주소가 바뀔 때마다 세 번째 인증 요소로 매직 링크를 강제해서 회사 은행을 다른 곳으로 옮길 생각까지 하게 됨
    지난 5년 동안 쓰던 위치나 ISP가 아닌 곳에서 로그인한다면 이해하겠지만, 어제 로그인했을 때와 달라진 게 DHCP 주소의 마지막 옥텟뿐이라면 말이 안 됨
    이메일은 웹 브라우징과 다른 컴퓨터에서 SSH로 읽기 때문에, 수백 글자짜리 로그인 링크를 복사해 붙여넣는 건 정말 고역임
    Emacs에서는 여러 줄에 걸쳐 표시되어 줄 경계의 \도 직접 제거해야 함
    로그인할 때마다 마찰을 추가하면 앱에서 이어지는 모든 상호작용의 인상이 나빠지고, 쓰기 싫어짐

    • Mercury CTO임
      이전에 쓴 기기라면 기기 확인 요구가 뜨면 안 됨. 이를 확인하려고 영구 쿠키를 저장하고 있고, 같은 IP에서도 요구하지 않음. 혹시 쿠키가 주기적으로 지워지고 있는지 궁금함
      이 기능은 공격자들이 http://mercury.com 복제 사이트를 만들고 Google 광고까지 집행한 뒤 추가한 것임
      고객이 피싱 사이트에 비밀번호와 TOTP를 입력하면 피셔가 그 자격 증명으로 로그인해 가상 카드를 만들고 암호화폐, 금 등을 샀고, 사용자는 진짜 Mercury로 리디렉션해서 일시적 오류라고 여기길 기대했음
      우리가 보내는 이 기기 확인 링크는 링크를 연 IP/기기를 승인하며, 이 방식으로 피셔를 거의 완전히 막았음
      WebAuthn은 이런 피싱 공격에 면역이므로 WebAuthn을 쓰면 기기 확인을 요구하지 않음
      가능하다면 TouchID/FaceID 또는 기기별 WebAuthn을 강력히 추천함. 더 편하고 더 안전하며, 여기서 추가할 수 있음: https://app.mercury.com/settings/security
      다만 내부적으로 이 글을 논의 중이고, IPv6가 더 확산되면 IP가 훨씬 더 자주 바뀔 것이라는 점도 인식하고 있음. 같은 IP 매칭 제한을 완화해야 할지 고민해보겠음

  • 지난주 404 글에 대한 반응으로 아주 좋다고 봄. 404를 좋아하지만, 글쓴이가 말한 같은 이유로 매직 링크는 짜증남
    Ricky Mondello가 지난주에 쓴 글[1]은 패스키가 글 끝에서 암시된 것처럼 매직 링크와 함께 쓰일 수 있음을 잘 설명해서 읽어볼 만함
    [1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/

    • 매직 링크에서 이 특정 문제를 겪은 적은 없지만, Epic이 Epic Games Store를 출시했을 때 로그인용 이메일 2단계 코드를 보내던 일이 떠오름
      스토어에 로그인하려고 하면 이메일로 보낸 2단계 코드를 입력하라고 했고, 몇 분 동안 메일이 안 와서 새 코드를 요청해도 안 왔고, 포기하고 다른 일을 하면 30분 뒤에 두 코드가 모두 도착하곤 했음
      사실 이메일은 아무리 좋은 때에도 신뢰하기 어려움. 스팸함으로 가거나, 회사 스팸 필터가 링크를 막거나, 받은편지함이 가득 찰 수도 있음
      개인적으로 이메일은 iPhone에만 있고, 회사 노트북이나 게임용 PC에서는 icloud.com에 로그인해야 확인할 수 있어 번거로움
      비밀번호를 입력하게 해주거나, 임베디드 기기처럼 QR 코드를 스캔하게 해주거나, 최소한 다른 선택지를 하나는 줬으면 함
    • 원문보다 이 글이 더 나음. 원문을 읽을 때는 패스키가 매직 링크의 대안이라는 점이 꽤 혼란스러웠는데, 보완재로 보는 편이 훨씬 말이 됨
      매직 링크는 패스키에 접근할 수 있게 해주고, 패스키는 기본적으로 “이 컴퓨터 기억하기”의 강화판임
    • 그 링크는 못 봤고, Ricky Mondello가 그 글을 쓴 줄 알았다면 아마 이 글은 굳이 쓰지 않았을 것임
      아직도 Apple 쪽 사람들이 공개적으로 거의 보이지 않던 시절에 익숙함

  • 뭔가 오해한 건지 모르겠지만, 패스키가 실제로 매직 링크의 대안은 아닌 것 같음
    지금까지 본 모든 패스키 구현은 다른 방식으로 이미 로그인한 뒤 패스키를 만들라고 제안했음
    깊이 파본 건 아니지만, 사용자 경험상 패스키는 비밀번호 전반의 대안이라기보다 “이 컴퓨터 기억하기” 버튼의 대안처럼 보임
    어떤 식으로든 서비스는 이 새 기기가 승인됐다는 사실을 알아야 함
    제공자에 따라 패스키 동기화가 있긴 하지만, 최초 인증을 어떻게 하느냐는 해결하지 못함
    매직 링크의 핵심 통찰은 보안 시스템이 복구 메커니즘보다 강할 수 없다는 것임
    패스키만 유일한 인증 수단으로 취급되는 세상은 오지 않을 것이고, 항상 복구 메커니즘이 남으며 대부분은 이메일을 통한 자동 복구일 것임
    그렇다면 매직 링크는 그 위에 더 안전한 계층이 있는 척하지 않고 단순화한다는 점에서 정직함
    복구 메커니즘을 인증 흐름의 주된 상호작용 수단으로 만들면, 인증 시스템의 실제 보안 수준에 대해 더 솔직해지는 셈임
    편집: filmgirlcw가 두 방식이 실제로 어떻게 보완되는지 설명하는 더 나은 글 링크를 남김: https://news.ycombinator.com/item?id=42628226

    • Ricky가 지난주 글[1]에서 썼듯, 패스키는 매직 링크나 다른 인증 수단을 보강해야 한다고 봄
      매직 링크에도 장점은 있지만, 이메일을 더 강력한 공격 벡터로 만드는 것이 장점인지는 모르겠음
      비밀번호 관리자를 쓰는 사람들에게 매직 링크는 분명한 마찰 지점이고, 패스키가 이를 확실히 줄일 수 있음
      패스키의 사용자 경험 문제도 개선 여지가 있고, 내보내기가 가능해지면 시스템 간 동기화가 훨씬 좋아질 것임
      1Password를 기본 비밀번호·패스키 시스템으로 쓰는 이유 중 하나도 기기 간 패스키 사용 때문이며, 회사도 1Password를 써서 개인 계정과 기업 계정에 로그인해두고 필요하면 개인 또는 업무 기기에서 인증할 수 있음
      다만 404가 정의한 문제가 비밀번호나 인증 제어 저장 책임을 지고 싶지 않다는 것이라면, 일부 사용자에게는 패스키가 매직 링크보다 낫다고 봄
      그래도 Ricky처럼 둘 중 하나가 아니라 둘 다여야 한다고 생각함
      [1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
    • 패스키는 지금 전환기에 있음
      패스키를 쓴다고 해서 반드시 대체 로그인 방법이 있어야 하는 것은 아니지만, 아직 어떤 서비스도 패스키 전용으로 전환하지 않았음
      오래된 OS나 Linux 사용자는 아직 패스키를 생성하고 저장하지 못할 수 있고, 많은 사용자가 크로스플랫폼 자격 증명 관리자를 쓰지 않음
      예를 들어 iCloud Passwords로 패스키를 만들었다면 지금은 Linux에서 로그인할 방법이 없음
      몇 년 더 지나면 서비스가 처음부터 패스키를 만들게 하고 비밀번호는 아예 수집하지 않는 흐름을 보기 시작할 것 같음
      패스키 이동성 명세가 구현되고, Gnome/KDE도 패스키 지원을 구현하길 바람
    • 이 글을 읽고 처음 든 생각은, 링크나 OTP 코드의 구체적 문제를 비판한 뒤 어떻게 패스키를 제안할 수 있느냐는 것이었음. 패스키도 거의 같은 문제가 10배로 있음
      업무용 PC에서 웹사이트를 방문할 때 휴대폰의 OTP를 쓰거나 휴대폰에서 링크를 복사하는 게 고통이라면, 업무용 컴퓨터가 노트북 같은 곳의 개인 패스키와 연동되게 하는 건 얼마나 더 쉽고 나은지 의문임

  • 인증에 매직 링크만 지원하는 서비스는 쓰지 않음. 사용자에게 매우 적대적이고, 보안 관점에서도 비밀번호 관리자와 함께 쓰는 비밀번호보다 분명히 더 나쁨
    가장 치명적인 건 내 개인 설정에서는 아예 동작하지 않는다는 점임
    보안과 계정 안전을 위해 로그인에 쓰는 기기에서는 이메일 계정에 접근하지 않기 때문임
    Anthropic만은 Claude가 최고의 LLM이라 예외로 두고 있지만, 다시 로그인해야 할 때마다 엄청난 고통이고 여러 번 불만을 보냈음

    • 비밀번호보다 보안 관점에서 정말 더 나쁠까? 자주 쓰는 서비스 대부분, 어쩌면 전부가 비밀번호를 잊었을 때 이메일 복구를 제공함
    • 비밀번호 관리자를 쓰는 사람이 충분히 많지 않아서, 회사들이 그 흐름을 목표로 삼을 만큼 가치가 크지 않은 게 아쉬움

  • 매직 링크를 볼 때마다 늘 “애초에 이메일 링크를 클릭하면 안 되는 것 아니었나?”라는 생각이 듦
    이메일 링크를 떠올리면 피싱도 같이 떠오름
    매직 링크가 정말 싫음

    • 그걸 헷갈리는 사람이 있나? 비밀번호 재설정 링크는 예전부터 이메일로 보내왔음
      핵심은 의심스러운 링크를 클릭하지 말라는 것임. 매직 링크가 전송된 걸 알고 있다면 의심스러운 링크는 아님
      그래도 지연 때문에 매직 링크는 싫음
    • 이미지도 로드하지 않음. 이메일 주소가 IP 주소로 이어질 수 있음
      Apple의 이메일 개인정보 보호 방식은 흥미로워 보임. Apple이 항상 모든 이미지를 로드하는 방식인데, 단점이 있는지는 모르겠음

  • 내가 본 가장 나은 구현은 이메일을 받은 기기에서 링크를 클릭해야 하지만, 세션을 그 기기로 옮기지는 않고 처음 로그인 절차를 시작한 기기에서 로그인을 완료하게 하는 방식임

    • 이건 피싱 때문에 나쁨
      더 나은 해결책은 링크를 연 기기에서만 로그인이 되게 하고, 기기 간 사용을 위해서는 수신 기기에서 읽어 원래 기기에 쉽게 입력할 수 있는 OTP 코드도 제공하는 것임
      또는 링크 없이 OTP 코드만 제공해도 됨
    • 동의함. 전부 이렇게 동작한다면 만족스러울 것 같음
      한 브라우저에서 작업 중인데 이메일을 열면 기본 브라우저에서 인증되거나, 더 심하면 다른 기기에서 인증되어 그쪽으로 링크를 전달한 뒤 다시 열어야 하는 것보다 나쁜 건 없음
      특정 기기에서는 특정 이메일에 접근하지 않으려는 경우도 있으니 이상한 시나리오만은 아님
      사이트가 crazy-pink-horse-3837 같은 OTP를 보내서 복사해 붙여넣게 해주는 방식은, 원래 요청을 인증하는 링크 구현이 너무 어렵다면 괜찮은 중간 지점임
    • 그럼 이메일을 받고 실수로 클릭하기만 해도 누구나 내 계정으로 로그인할 수 있는 것 아닌가?
    • 알기로 McDonald’s 모바일 앱이 이런 방식을 씀. 비밀번호 로그인을 허용하지 않았음
      그런데 구현의 문제는 보내는 매직 링크가 클릭 추적기로 감싸져 있고, 그 도메인이 pihole 같은 도구에 막힌다는 점이었음
      그래서 실제 인증 URL에 도달해 로그인 절차를 끝낼 수 없었음
    • 보안팀이 조금이라도 유능하다면 절대 허용하지 않을 방식임. 사용자에게 피싱당하라고 부탁하는 셈임

  • 인앱 브라우저는 사라져야 함. 특히 “일반 브라우저에서 열기”를 선택할 수 없는 인앱 브라우저는 더 그렇고, RSS 리더라면 당연히 그 선택지를 제공해야 함

    • 진지하게 법이 허용하는 가장 강한 처벌로 끝내야 함
      사용자에게 인앱 브라우저를 강제한 제품 관리자들은 전부 감옥에 보내야 함
    • RSS 리더가 뭐임?

  • 훨씬 나은 선택지는 이메일로 보낸 OTP 코드와 Conditional Mediation UI를 쓰는 패스키임
    사용자가 이미 패스키가 있는 기기에서 로그인한다면 CM UI가 바로 선택하게 해 즉시 로그인할 수 있음
    패스키가 없는 기기라면 이메일 코드를 입력하게 하고, 성공하면 즉시 패스키를 설정해 다음부터 바로 로그인하게 만드는 사용자 경험을 설계할 수 있음
    이렇게 하면 기존 기기에서는 패스키의 보안을 얻고, 새 기기에서는 비밀번호 없는 설정과 계정 복구를 얻을 수 있음
    덤으로 클라우드 제공자가 모든 패스키를 가진 벤더 종속도 피할 수 있음

    • 사용자에게 이메일 코드를 입력하게 하는 방식은 안타깝게도 중간자 공격을 막지 못함
답변달기