▲

일회용 코드를 이메일로 보내는 것은 비밀번호보다 더 나쁩니다

 (blog.danielh.cc)
7P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • 최근 많은 서비스가 이메일 또는 전화번호 기반 6자리 코드 로그인 방식을 도입함
    • 이메일/전화번호 입력하면 6자리 인증 코드 발송하고, 이를 입력하여 로그인
  • 이 방식은 계정 보안에 심각한 취약점을 초래함
    • 공격자가 단순히 타인의 이메일 주소를 legitimate 서비스에 입력하여 인증 코드 발송을 요청할 수 있음
    • 사용자는 받은 인증 코드가 정말 제대로 사용되어야 할 상황인지 또는 피싱 시도인지 쉽게 알 수 없는 문제가 발생함
    • Password manager(비밀번호 관리자)와 같은 기존 피싱 방지 도구의 효과가 없음
  • 이러한 인증 코드 방식은 실제로 악용 사례가 지속적으로 발생함
    • 실제 Microsoft에서 운영하는 Minecraft 계정 로그인에서도 유사한 방법이 사용되고 있음
    • Reddit, YouTube 등 다양한 온라인 커뮤니티와 미디어에서 여러 계정 도난 사례가 보고됨

결론

6자리 코드 이메일 인증 방식은 보안상 예상보다 더 취약한 방식임

  • 기존 비밀번호 방식에 비해 오히려 피싱 위험이 크게 증가함
  • 사용자 경험 개선이나 보안을 위해 도입된 방법이지만 실제로는 더 나쁜 결과 유발 가능성 있음
▲
GN⁺ 8시간전  [-]
Hacker News 의견

  • 공격 패턴은 다음과 같은 방식임
    1) 사용자가 사기성 사이트에 가입함
    2) 그 사이트가 “GOOD 사이트에서 로그인 코드를 이메일로 보냈으니 입력해달라”고 안내함
    3) 사기 사이트가 사용자의 이메일로 GOOD 사이트에서 “이메일로 일회용 코드로 로그인” 플로를 시작함
    4) GOOD 사이트가 로그인 코드를 사용자에게 이메일로 전송함
    5) 사용자는 이메일이 GOOD에서 왔으니 믿고 그 코드를 입력함
    6) 사용자가 사기 사이트에 코드를 입력함
    7) 사기 사이트가 그 코드를 사용해 GOOD 사이트에 사용자가 된 것처럼 로그인함
    이런 이유로 인해 “이메일로 일회용 코드를 보내는” 인증 방식은 피싱 공격에 매우 취약함
    “이메일 내 링크 클릭” 방식이 약간 더 나음, 왜냐면 사용자가 GOOD 사이트로 바로 이동하고 사기 사이트에 그 링크를 복사/붙여넣는 게 더 번거롭고 수상하기 때문임
    다만, 인기있는 이메일 서비스가 갑자기 로그인 이메일 혹은 링크 자체를 차단하기 시작하면, 다수의 사용자가 로그인 자체를 못 하게 되는 문제도 있음
    Passkeys가 가장 올바른 방식임
    패스워드 매니저의 패스키 지원이 갈수록 좋아지고 있음
    만약 패스키를 저장한 기기를 분실해서 모든 패스키를 잃게 돼도, 기존의 패스워드 체계보다 훨씬 안전하다고 확신함
    할머니가 계정 접근을 위해 은행을 방문해야 하는 게, 누군가 피싱으로 할머니 돈을 모두 훔쳐가는 것보단 낫다고 생각함

    • Passkeys 문제는 “기기를 분실하면 접근권한을 잃는 것”보다 더 복잡함 (설정에 따라 기기 분실 시에도 해결책이 있음)
      가장 큰 문제는 Attestation임
      서비스가 사용자의 자유를 늘려주는 도구(예: 오픈소스 인증 솔루션 등)를 사용한 사람을 차단할 수 있게 허용함
      Passkeys나 challenge-response 프로토콜 방식은 원래 비밀번호를 대체할 수 있는 엄청난 개선책이 될 수 있었음
      그런데 현실은 BigTech의 지배 체제만 더 견고하게 만들고 사용자 자유는 줄어드는 쪽으로 설계됨

    • “할머니가 계정 복구하러 은행 방문하는 게 낫다”는 얘기에 대해서
      총으로 위협받아 계정 강제로 해제하고 돈까지 전부 털리게 된다면 그땐 어떨지 생각해봐야 함
      내가 사는 제3세계 국가에서는 스마트폰 강도 문제가 너무 심각해서 2FA조차 현실적으로 불가능함
      예전에 한번 2FA 복구해본 적이 있는데 지옥 같았음
      패스워드는 어디에서나 Bitwarden만 접속하면 해결됐었음

    • Passkey를 github에 설정했고, Chrome에 저장되어 있음을 확인함
      github에 passkey로 로그인하려 하면 Chrome에서 구글 패스워드 매니저 핀을 입력하라고 팝업이 뜸
      이 핀 번호가 뭔지 모르고, 재설정할 방법도 찾을 수 없음
      구글 프로필, 패스워드 매니저, 보안설정 어디에도 핀에 대한 안내가 없음

    • 할머니가 은행 방문해서 계정 복구하는 건 괜찮다는 의견에
      내가 직접 은행이나 회사 IT 헬프데스크에 찾아가 계정 복구는 할 수 있지만,
      구글·페이스북·Xitter 본사에 찾아가서 그렇게 해줄 순 없음
      기기 결합형 패스키는 이런 경우 오류 발생 확률이 매우 높음
      사용자 대부분은 이런 상황을 고려하지 못함

    • Passkeys만으로 충분하지 않음
      기존의 실수 반복 말자는 얘기임
      Password manager가 기본이 되어야 하고, 정말 예외적인 경우(예: 이메일 계정, 금융 계좌 등)에만 전용 MFA 도입해야 함
      MFA 설정도 최소 3가지를 세팅하도록 강제하고 그중 2개 이상 써야 한다고 생각함
      인쇄된 코드, 운영체제 독립 인증 앱, yubikey 같은 하드웨어 키 등 거의 모든 방식 지원 안 하면 그 MFA는 쓸 가치 없다고 봄

  • 하루에 네 번씩 Microsoft 계정 비밀번호 재설정 요청 알림 메일을 받음
    6자리 숫자가 적힌 메일로, 이걸로 계정 복구할 수 있게 되어 있음
    결국 공격자는 매일 100만분의 1 확률로 내 계정 탈취 시도 4번씩 할 수 있다는 뜻
    이걸 수천 계정 대상으로 시도한다면, 매일 공짜로 계정 일부를 뚫을 수 있음
    이 내용으로 보안 보고서까지 냈으나, 수학적으로 취약점 증명이 충분치 않다고 하며 대응 거부됨
    남은 방법은 그냥 스팸 맞으면서 계정이 털리지 않길 기도하는 수밖에 없음

    • 로그인 별칭(alias)을 추가해서 해결함
      로그인 시 기존 계정 이메일(공개된 이메일)은 차단되고, 비공개 랜덤 스트링인 별칭으로만 로그인할 수 있게 했음
      그 이후로 한 번도 외부 로그인 시도가 없었음
      [설정법: account.microsoft.com > 내 정보 > 로그인 환경설정 > 이메일 추가 > 별칭 추가 후 기본값 설정 > 로그인 환경설정에서 별칭만 허용 선택]

    • 나도 같은 경험을 함
      아마 Microsoft Teams 써야 했을 때 남은 영향이 아닐까 생각함

    • 공격자가 125,000개 계정 대상으로 이 방법을 쓴다면 하루에 한 계정꼴로 얻어걸릴 수 있음
      특정 계정 겨냥하지 않고 전체 대상으로 시도한다면 시간 대비 효율이 상당히 괜찮음
      이 문제 해결하려면 고정 4회 시도 제한 대신 실패할 때마다 대기 시간을 늘리는 exponential backoff 적용해야 함

    • 나도 인스타그램 옛날 계정에서 비슷한 메시지를 계속 받음
      “로그인에 문제가 있나요? 비밀번호 변경하려면 여기를 클릭하세요!”

    • 오래된 쓸모없는 계정에도 똑같은 일이 있었음
      로그인 시도한 IP 주소를 확인해보니 전세계 여러 ISP에서 들어왔고, 대부분이 서로 다른 /16 네트워크였음
      이렇게 “쓸모없는” 계정에도 botnet까지 동원하는 걸 보니 위협에 노출된 사람들은 얼마나 더 심각할지 걱정임
      2FA 추가했더니 완전히 해결됨
      이들이 처음 어떻게 6자리 코드를 사용하는 로그인 흐름을 찾았는진 아직도 모르겠음(난 매번 비밀번호 입력 후 바로 로그인만 됐으므로)
      그래도 2FA 추가 후론 추가 시도 한 번도 못 봤음
      2FA 코드 역시 패스워드 매니저에 저장함
      Microsoft의 자동 6자리(영어도 아닌 숫자만!) “비밀번호” 추첨을 더 이상 공격 못 하니 만족함

  • 가장 최악인 건 이런 인증 방식이 사용자 습관과 기대치를 더 나쁘게 만든다는 점임
    1password같은 현대적 패스워드 매니저 쓰면, 이메일 토큰 방식보다 훨씬 쉽고 안전하고 빠름
    몇 대 장치에서 초기 설정과 검증만 조금 신경 쓰면 됨
    새로운 곳에 이사 와서 문 열쇠 복사하듯, 패스워드 매니저에 저장한 후 다른 기기에서 동기화까지 확인해야 안심할 수 있다고 생각함
    사람은 충분히 할 수 있음
    암호화, 2FA 개념 몰라도, “새 비밀번호 만들기” 클릭하고 앱이 저장해주는 무작위 비밀번호 쓰면 됨
    패스키도 마찬가지, 단 저장 위치를 기기 내장 저장소가 아니라 백업/복구까지 고려해서 써야 함
    아이러니하게도 예전 방식(이메일과 비밀번호 입력)이 오히려 더 잘 작동함
    패스워드 매니저가 무조건 바로 자동입력해주니까 실제로 훨씬 빠름
    패스키는 그보다도 더 빠를 수 있음

    • 약간만 신경 쓰면 되는데, 이 “약간”이 대부분 사람에겐 너무 크고 힘든 진입 장벽임
      나도 답답하지만, 내 주위의 비IT 직종인 사람 80%는 보안에 관해선 무지하고, 포기하고 사는 듯함
      그나마 성공 사례는 계정 정보를 작은 수첩에 아예 적어두고, 비밀번호에 숫자와 영문이 반드시 포함하게 하는 정도였음

  • 이 흐름의 문제점은 이해함
    내가 겪은 바로는, 이 일회용 비밀번호 방식이 내 주변의 비IT인 사람들에겐 비밀번호 다음으로 익숙한 인증임
    내가 사는 작은 마을 기준, 비밀번호 관리자나 패스키는 오히려 더 난해하고, 사용법을 눈앞에서 설명해도 절대 이해 못 시킴
    정신적 모형 자체가 너무 낯설고, UX도 너무 복잡해 이해 불가임
    대중이 직관적으로 이해할 수 있는 무언가가 나올 때까지는, 비밀번호와 “문제 많은” 일회용 코드 방식이 단순함 때문에 계속 대세일 것 같음

    • 그냥 비밀번호나 계속 쓰자는 생각임

  • 제대로 된 비밀번호만 쓰더라도, 비밀번호를 “잊어버렸을 때” 계정 복구 방식이 똑같은 일회용 코드 패턴임
    결국 비밀번호를 “잊은 것처럼” 행동한 공격자는 그 복구 흐름으로 로그인해버릴 수 있음
    나도 내가 만든 서비스를 위한 로그인을 일회용 코드 방식으로 쓰긴 함
    다만 민감하지 않은 서비스라 인증을 빡세게 하는 게 목적이 아님
    나도 ICGAFAS(“I Couldn't Give A Factor” Auth System)라고 부르며, 애초에 보안에 별 신경 안 씀을 드러냄
    이메일 기반 인증은 관리자 입장에서도 SMTP 발송/배달 문제 등 신경 쓸 게 많아짐
    결국 블랙리스트에 걸리거나 스팸 필터에 막히지 않으려면, 3rd party relay 서비스 써야 하는 현실임

    • 제대로 된 비밀번호가 있어도 대부분의 계정 복구 플로우가 이 일회용 코드 방식이라, 결국 이 부분이 “가장 약한 고리”가 되는 것임

  • 대부분의 서비스가 기존의 이메일+PW, 소셜 로그인 대신 이 일회용 코드 방식을 강제하는 게 너무 불쾌함
    내 100자짜리 비밀번호를 쓰게 해달라는 생각임

    • 당신은 타겟 사용자가 아님
      오히려 아주 특이한 소수에 속함
      장기적으로 “다수”와 연결될 수 있는 솔루션을 고민해야 함

    • 100자짜리처럼 긴 패스워드는 의미 없다고 봄
      아래 암호화에 실제 사용되는 key length에 따라 길이가 truncate됨

  • NIST 문서(NIST 800-63b section 5.1.2.1)에서 이런 인증 방식이 공식적으로 허용되는지 확인해봤음
    “Look-up Secret Authenticator”로 간주한다면 특별한 문제점은 없음
    원래 사전 배포된 인증코드(복구코드 등)를 의미했던 방식을, 실시간 발송, 단일 선택으로 남용하는 셈임
    이 방식이 피싱에 약하다고는 생각하지만, 사실 기존의 username/password 방식보다 더 위험하다고 단정하기도 어려움
    가령 사용자 이메일로 6자리 코드 요청해서 입력하라고 하면, 코드가 진짜인지 가짜인지 구분을 못함
    단, 공격자는 Google 계정처럼 모양만 그럴듯하게 만든 페이지로 유저를 속여 정보를 뺏어올 수도 있음
    결국 피싱 저항성이 있는 인증만이 진짜 미래라고 생각함

  • gofundme 계정을 삭제해야 했던 이유가, 오늘 갑자기 이런 인증 사이클에 빠졌기 때문임
    여러 해 동안 계정 쓰고 후원도 했지만, 이제는 휴대폰 번호와 MFA 코드를 의무적으로 요구하면서 거부 옵션도 제공하지 않음
    결국 절차 다 거치고, 계정 비활성화 해버림
    이런 인증이 인생에 불필요하다고 생각함, gofundme 없이도 살 수 있음
    요즘 집 구하고 있는데, Zillow 앱도 마찬가지로 로그인을 요구하고, 받은 메시지 읽으려면 매번 MFA도 요구함
    한 시간이면 세션 만료
    이런 인증 방식에 진절머리가 남
    완전 미친 세상임

    • Ticketmaster도 비슷하게 함
      Google Voice 번호는 허용 안 하고, SIM에 연결된 번호만 요구함
      내 SIM 번호는 자주 바뀌는 “구현상의 세부사항”일 뿐인데, 지금은 그 번호 없으면 계정 로그인이 불가능함
      결과적으로 이런 식 티켓팅을 포기하거나, SIM 바꿀 때마다 계정 락아웃을 감수해야 함

    • 구글이 내 계정에 2FA를 직접 켜버렸고, 계정에 등록된 전화번호가 옛날 거라 완전히 계정 잠김 상태임

  • 아무런 예고 없이 서비스가 비밀번호와 2차 인증을 바꿔버릴 때, 계정에 묶여있는 폰이 없는 여행 중에는 영원히 접근 막힐 수 있음
    대부분의 서비스가 2차 인증을 내 20자짜리 무작위 비밀번호(로컬 패스워드 매니저에 저장)보다 더 안전하다고 간주함
    그런데 2차 인증 방식이란 게, 결국 SMS로 평문 전달, 이메일로 평문 전달 등 별 시시한 수준임

    • 사람들이 비밀번호 재사용률이 얼마나 되는지, 패스워드 매니저 쓰는 비율은 얼마나 되는지 궁금함

  • 이 문장이 네 번이나 읽어도 이해가 안 됐음
    “공격자가 사용자의 이메일 주소를 정상 서비스에 보내고 6자리 코드를 요청하면, 정작 사용자는 그 코드가 진짜 로그인용인지 알 수 없다”와 같은 설명임

    • 왜 이해 안 되는지 알겠음. 저자가 진짜 말하고 싶었던 건
      • 사용자 입장에선 사기 사이트(정상 사이트처럼 보이는 곳)에서 이메일, 로그인 입력
      • 해커는 이 이메일을 정상 서비스에 집어넣고, 정상 서비스는 사용자에게 6자리 코드를 보냄
      • 사용자는 “이메일로 받은 코드가 정상 서비스에서 왔다”는 사실만 믿고 그대로 입력함
      • 공격자가 그 코드를 가지고 즉시 계정에 접근함
      • 이런 식으로 정보가 털리는 플로우임
답변달기