회원 가입 API를 만들다 보면 데이터베이스의 비밀번호 열을 어떻게 채워야 할지 고민하게 됩니다. 평문을 그대로 넣으면 안 된다는 사실은 알겠는데, AES로 암호화해야 할까요? 아니면 SHA-256으로 해시하면 충분할까요? 둘 다 안전한 답은 아닙니다. 비밀번호 저장은 일반 데이터 암호화나 파일 무결성 검사와 다른 위협을 상대하기 때문인데요. 공격자가 데이터베이스를 통째로 가져간 뒤에도 사용자의 원래 비밀번호를 알아내기 어렵게 만들어야 합니다. 이번 글에서는 비밀번호를 저장하고 검증하는 기본 흐름부터 우리에게 익숙한 범용 해시 알고
JWS로 이해하는 JSON 데이터 서명에서 서명이 토큰의 위변조를 막아준다는 걸 봤는데요. 한 가지 짚고 넘어간 점이 있습니다. 서명은 내용을 숨겨주지 않는다는 것이죠. JWS나 JWT의 페이로드는 그냥 Base64로 인코딩됐을 뿐이라 누구나 디코딩해서 들여다볼 수 있습니다. 그렇다면 토큰 내용 자체를 진짜로 가려야 할 때는 어떻게 할까요? 이때 등장하는 것이 **JWE(JSON Web Encryption)**입니다. 이번 글에서는 JWE가 JWS와 무엇이 다른지, 독특한 5조각 구조와 2단계 암호화 방식이 무엇인지를 직접 암호화/
JWT나 JWS로 토큰에 서명하려고 보면 alg 자리에 뭘 넣어야 할지부터 막히는데요. HS256, RS256, ES256, EdDSA... 이름은 비슷비슷한데 막상 고르려니 뭐가 다른지 감이 안 옵니다. 🤔 이 알고리즘들은 모두 JWA(JSON Web Algorithms, RFC 7518)가 정의한 서명 알고리즘인데요. 그냥 아무거나 골라도 토큰은 만들어지지만, 대칭이냐 비대칭이냐, 토큰이 얼마나 커지느냐, 검증 부하가 어디에 실리느냐에 따라 분명한 트레이드오프가 있습니다. 이번 글에서는 자주 쓰이는 네 가지를 비교하고 상황별로
클라우드에 서버를 하나 만들고 나면 대개 이런 명령어부터 입력하게 됩니다. 명령어 한 줄로 멀리 있는 서버의 터미널이 열리니 무척 간단해 보이는데요. 처음 접속할 때 나타나는 지문이 무엇인지, 비밀번호 없이 어떻게 로그인이 되는지, ~/.ssh에는 왜 여러 파일이 생기는지 파고들기 시작하면 이야기가 금세 복잡해집니다. SSH를 단순히 원격 접속 명령어로만 외우면 연결 오류가 났을 때 어디부터 확인해야 할지 막막합니다. 반대로 서버 확인과 사용자 인증을 구분해서 이해하면 키를 안전하게 관리하는 방법도 자연스럽게 보이죠. 이번 글에서는
인터넷에서 받은 프로그램이 개발자가 배포한 그대로인지, 로그인 요청이 정말 등록된 기기에서 왔는지, 웹사이트가 접속하려던 서버가 맞는지는 어떻게 확인할까요? 내용을 암호화하면 제삼자가 읽지 못하게 숨길 수는 있지만 누가 만들었고 중간에서 바뀌지 않았는지까지 저절로 증명되지는 않습니다. 이때 사용하는 도구가 디지털 서명(digital signature)입니다. 디지털 서명은 종이에 하는 서명처럼 데이터에 신원을 연결하지만 눈으로 필체를 비교하는 대신 개인 키와 공개 키를 사용해 수학적으로 검증하는데요. TLS의 서버 인증, JWS와
결제 서비스가 우리 서버로 다음과 같은 웹훅(webhook)을 보냈다고 해볼까요? HTTPS로 받았으니 무조건 믿고 결제 완료 처리를 해도 될까요? HTTPS는 전송 구간을 보호하지만, 이 요청이 정말 결제 서비스가 만든 것인지 애플리케이션이 확인할 방법은 따로 필요합니다. 공격자가 우리 웹훅 주소를 알아내고 가짜 요청을 직접 보낼 수도 있으니까요. 메시지의 SHA-256 해시를 함께 받으면 해결될 것 같지만, 공격자는 가짜 메시지의 해시도 다시 계산할 수 있습니다. 누구나 계산할 수 있는 해시만으로는 메시지를 만든 상대를 가려낼
운영체제 이미지나 개발 도구를 내려받다 보면 파일 옆에 길고 낯선 문자열이 붙어 있는 경우가 있습니다. SHA-256이나 checksum이라는 이름 아래 16진수 숫자가 빼곡하게 적혀 있죠. 내려받기가 끝났으니 파일을 바로 실행해도 될 것 같은데, 왜 굳이 이 값을 함께 제공할까요? 전송 도중 일부가 깨졌거나 저장 장치에서 데이터가 손상돼도 파일명과 용량만으로는 알아채기 어려울 수 있기 때문입니다. 이때 원본과 내려받은 파일이 같은지 확인하는 짧은 값이 체크섬(checksum)입니다. 이번 글에서는 체크섬이 오류를 어떻게 찾아내는지
브라우저에서 자물쇠 아이콘을 누르면 인증서 발급자와 유효 기간, 도메인 이름 같은 정보가 나타납니다. 서버를 운영하다 보면 fullchain.pem, privkey.pem, .crt, .p12처럼 비슷해 보이는 파일도 한꺼번에 마주치고요. 인증서가 만료됐다는 경고는 익숙하지만, 이 파일이 왜 서버의 신원을 증명하는지는 선뜻 설명하기 어렵습니다. 현대의 전송 계층 보안(Transport Layer Security, TLS) 인증서는 단순한 암호화 키도, 사이트가 안전하다는 보증서도 아닙니다. 누구의 공개 키인지, 어느 이름에 사용할