Sign-In with Ethereum(SIWE): 지갑 로그인 원리와 확인법

사이트에서 지갑을 연결한 뒤 메시지 서명을 요청합니다. 가스비도 없고 트랜잭션도 전송되지 않아요. 단순 로그인일까요, 아니면 다른 권한까지 넘기는 걸까요? **Sign-In with Ethereum(SIWE)**은 지갑 로그인을 일정한 형식으로 만들지만, 요청을 읽는 책임까지 없애주지는 않아요. 이 글에서는 크립토 지갑 보안에 필요한 SIWE 확인법을 차근차근 살펴봅니다.

정보 제공 목적이며 투자 조언이 아닙니다(NFA). 형식이 올바른 로그인도 사이트·지갑·세션의 안전을 보장하지 않아요. 도메인과 메시지를 직접 확인하고, 키를 보호하며, 스스로 조사하세요(DYOR).

Sign-In with Ethereum은 ERC-4361에 정의된 오프체인 인증(Authentication) 표준이에요. 비밀번호를 만드는 대신 지갑에서 구조화된 메시지에 서명해 이더리움 주소를 제어한다는 사실을 증명합니다. 서비스는 서명을 검증한 뒤 쿠키 같은 일반적인 웹 세션을 만들 수 있어요.

건물 안내 데스크에 서명된 방문증을 내는 상황을 떠올려 보세요. 방문증에는 건물 이름, 방문자, 발급 시각, 한 번만 쓰는 일련번호가 적혀 있습니다. 직원이 서명과 내용을 확인한 뒤 임시 출입증을 내줘요. 지갑 서명이 방문증이고, 웹사이트 세션이 임시 출입증인 셈입니다.

SIWE는 인증이지 블록체인 트랜잭션이 아니에요. 보통 가스비가 들지 않고, 서명만으로 토큰이 전송되지 않습니다. 하지만 “가스비 0원”이 “위험 0”을 뜻하지는 않아요. 피싱 사이트가 다른 서명을 로그인처럼 꾸미거나, 정상 로그인으로 민감한 계정 데이터에 접근할 수 있습니다.

SIWE 로그인은 어떻게 작동하나요?

ethereum.org의 인증 가이드가 설명하는 지갑 로그인 흐름은 다음과 같아요.

사이트가 지갑에 공개 이더리움 주소를 요청합니다.
서비스가 도메인, 주소, 체인 ID, 논스(Nonce), 발급 시각과 선택적 제한 조건을 담은 SIWE 메시지를 만들어요.
지갑이 메시지를 보여주고, 사용자가 승인하면 계정 키로 기기 안에서 서명합니다.
사이트가 메시지와 서명을 받아 유효성 및 자신이 발급한 요청과의 일치 여부를 확인해요.
검증에 성공하면 이더리움 주소에 연결된 웹 세션을 만듭니다.

개인키(Private Key)는 지갑 밖으로 나갈 필요가 없어요. 서명은 이 계정이 특정 요청을 승인했다는 증거입니다. 사이트가 나중에 다른 곳에 입력할 수 있는 비밀번호를 건네는 방식과 달라요.

일반 외부 소유 계정(EOA)은 ERC-191 서명 메시지 방식을 사용합니다. 스마트 컨트랙트 계정은 메시지에 적힌 체인에서 ERC-1271로 검증할 수 있어요. 컨트랙트 서명의 유효성은 온체인 상태에 따라 달라질 수 있으므로, 서비스는 그 변화를 고려해 세션 정책을 설계해야 합니다.

서명창에서 읽어야 할 필드

SIWE 메시지는 기계가 해석할 수 있으면서 사람도 이해할 수 있도록 설계됐어요. 각 필드는 누가, 어떤 계정에, 어느 범위로 인증을 요청하는지 정합니다.

필드	의미	확인할 내용
Domain	로그인을 요청한 서비스	브라우저에 열린 사이트와 일치하는지
Address	인증할 계정	사용하려던 지갑 주소가 맞는지
Statement	사람이 읽는 목적·약관	예상한 행동과 일치하는지
URI	로그인의 대상 리소스	예상한 서비스 소속인지
Chain ID	네트워크 맥락	계정·스마트 월렛에 맞는 체인인지
Nonce	고유한 일회용 요청값	과거 메시지를 복사한 것이 아닌지
Issued At	메시지 발급 시각	지금 시도한 로그인과 가까운지
Expiration / Not Before	선택적 유효 기간	만료됐거나 아직 시작 전이 아닌지
Resources	선택적 리소스 목록	모든 URI를 이해하고 예상했는지

ERC-4361은 도메인, 주소, URI, 버전, 체인 ID, 논스, 발급 시각을 필수로 요구해요. 논스는 영문·숫자 8자 이상이어야 하지만 길이만 길다고 안전하지 않습니다. 서버가 예측하기 어려운 값을 만들고 정확히 대조해야 해요.

표준을 구현한 지갑은 메시지의 스킴(Scheme)·도메인과 실제 요청 출처(Origin)를 비교해야 합니다. 도메인 바인딩(Domain Binding)은 핵심 피싱 방어선이에요. 브라우저는 example.net인데 메시지가 example.com 로그인을 요청한다면 거절하세요.

논스와 도메인이 중요한 이유

한번 만들어진 서명은 시간이 지나도 수학적으로는 유효할 수 있어요. 새로운 도전값이 없다면 공격자가 과거 로그인 메시지를 훔쳐 다시 제출하는 재생 공격(Replay Attack)을 시도할 수 있습니다. 논스는 방문증의 일회용 일련번호와 같아요. 서비스는 자신이 예상한 값을 한 번 확인한 뒤 폐기해야 합니다.

공식 SIWE 보안 고려사항은 용도에 충분한 엔트로피(Entropy)를 가진 논스를 선택하고 서버가 예상값과 일치하는지 확인하라고 안내해요. 백엔드는 단순히 서명에서 어떤 주소가 복구되는지만 볼 게 아니라, 실제로 받은 메시지 전체가 예상한 요청인지 검증해야 합니다.

도메인 바인딩은 “이 방문증을 어디에서 쓰도록 만들었는가?”에 답해요. 가짜 도메인이 요청한 서명으로 진짜 서비스에 로그인할 수 없어야 합니다. 지갑과 서버의 검사가 함께 작동해야 해요. 읽기 쉬운 도메인은 사용자가 불일치를 발견하게 돕고, 엄격한 구현은 잘못된 요청의 수락을 막습니다.

SIWE가 기본적으로 허용하지 않는 것

ERC-4361이 표준화하는 것은 인증입니다. 토큰 지출, 스왑 실행, 운영자 승인, 모든 서버 리소스 접근 권한을 자동으로 정의하지 않아요. 표준은 인증과 인가(Authorization)를 구분합니다.

정상적인 SIWE 메시지는 로그인 요청처럼 보여야 해요. 토큰 퍼밋(Permit)이나 컨트랙트 호출과 달라야 합니다. 사이트가 “로그인”이라고 설명하는데 지갑에는 승인, 전송, 퍼밋, 불투명한 타입 데이터가 보인다면 멈추세요. SIWE 필드와 비교하고, 승인 전 클리어 사이닝 확인법을 적용해야 합니다.

선택 항목인 Resources도 주의해서 읽으세요. 인증 요청과 연결된 URI 목록이지만, ERC-4361 자체는 각 URI가 어떤 권한을 뜻하는지 정의하지 않아요. 모든 항목을 읽고 서비스의 최신 공식 문서에서 의미를 확인해야 합니다.

리스크와 한계

피싱 가능성은 남아요

“wants you to sign in”이라는 익숙한 문구만으로 표준 메시지라고 판단하면 안 됩니다. ERC-4361은 형식이 틀린 메시지에 이 문구가 들어가면 지갑이 경고하도록 권고해요. 브라우저 도메인을 독립적으로 확인하고, 다른 도메인·예상 밖 서브도메인·갑작스러운 QR 요청은 거절하세요.

하나의 주소가 추적 식별자가 될 수 있어요

같은 공개 주소로 여러 서비스에 로그인하면 서비스와 외부 관찰자가 활동을 연결할 수 있습니다. ENS 이름, 토큰·NFT 보유 내역, 공개 트랜잭션은 이메일 별칭보다 많은 맥락을 드러낼 수 있어요. 연결이 걱정된다면 공개 로그인용 계정을 분리할 수 있지만, 복구 수단은 다른 지갑처럼 철저히 관리해야 합니다.

키를 잃으면 복구 방식도 달라져요

셀프 커스터디(Self-Custody) 키에는 자동 “비밀번호 찾기”가 없어요. 서비스가 별도 복구 수단을 제공할 수 있지만, SIWE 자체는 지갑 제어권으로 신원을 증명합니다. 중요한 데이터에 접근하는 유일한 방법으로 쓰기 전 시드 문구를 안전하게 보호하고 서비스 복구 정책을 확인하세요.