우리가 비밀번호를 보호하는 방법

이전 기사에서는 HTTPS가 앱과 서버 간의 경로를 보호하고, SSH가 서버 자체를 보호하는 방법에 대해 살펴보았습니다. 이제 서버 내부를 들여다볼 차례입니다. Splync가 비밀번호를 서버에 도착한 후 어떻게 안전하게 유지하는지 알아보겠습니다. 누군가 비밀번호를 획득하면, 그 사람은 계정에 로그인하고 비용 기록을 포함한 민감한 정보를 접근할 수 있습니다. 그래서 Splync는 절대 비밀번호를 평문으로 저장하지 않습니다. 대신 각 비밀번호는 데이터베이스에 저장되기 전에 해시된 버전으로 변환됩니다. 이는 정확히 무엇을 의미할까요? 해싱은 한 방향으로만 변환되는 것으로, 변환된 후에는 원래 비밀번호로 다시 변환할 수 없습니다. 이 방법은 은행에서부터 주요 클라우드 서비스까지 인터넷 전반에 걸쳐 표준으로 사용되지만, 많은 사람들이 실제로 어떻게 작동하는지 잘 모릅니다. 일상적인 비유를 통해 이를 알아봅시다.

비밀번호 보호가 어떻게 작동하는지 이해하기 위해 SHA-256이라는 간단한 해싱 방법부터 시작해 봅시다. 이는 항상 같은 방식으로 재료를 혼합하는 블렌더와 같습니다. 같은 비밀번호를 블렌더에 넣고 버튼을 누르면 항상 동일한 유일한 스무디, 즉 문자와 숫자로 뒤섞인 결과가 나옵니다. 중요한 점은 이 과정이 절대 되돌릴 수 없다는 것입니다. 스무디를 원래의 바나나와 우유로 분리할 수 없는 것처럼, 뒤섞인 해시 결과에서 원래 비밀번호를 복구할 수 없습니다.

SHA-256은 가장 흔히 사용되는 해싱 알고리즘 중 하나입니다. 예를 들어, "splync1234" 비밀번호를 해싱하면 "9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41"로 변환됩니다. 기존 사용자가 로그인할 때 입력한 비밀번호는 밀리초 단위로 SHA-256을 통해 항상 같은 해시된 비밀번호를 생성합니다. 앱은 입력된 비밀번호를 다시 해싱하여 저장된 해시와 일치하는지 확인합니다. 시스템은 어느 시점에서도 사용자의 원래 비밀번호를 알지 못합니다. 하지만 공격자가 일반적인 비밀번호와 그들의 해시 목록(레인보우 테이블 공격)을 미리 계산하여 사용자의 비밀번호를 빠르게 추측한다면 어떻게 될까요? 이는 매우 현실적인 우려입니다. 그래서 Splync를 포함한 현대 시스템은 일반적인 SHA-256에 의존하지 않습니다.

Bcrypt는 사용자별로 무작위 솔트를 사용하며, 그 솔트와 비용 요소를 저장된 해시 문자열에 직접 인코딩합니다. bcrypt를 비밀 양념(솔트)과 느린 모터(작업 요소)가 있는 블렌더로 생각해 보세요. 이는 모든 혼합물을 고유하게 만들고 복제하기 어렵게 만듭니다. 솔트는 128비트(≈3×10³⁸의 가능성)이며, 동일한 비밀번호가 천문학적으로 많은 서로 다른 저장 해시로 매핑될 수 있습니다. 이는 대규모로 사전 계산된 레인보우 테이블을 무용지물로 만듭니다. 로그인할 때 Splync는 저장된 bcrypt 문자열에서 솔트와 비용을 읽어, 입력된 비밀번호에 대해 이 파라미터로 bcrypt를 다시 실행하고 저장된 해시와 결과를 비교합니다. 일치하면 비밀번호가 정확한 것입니다. 그러나 bcrypt는 의도적으로 느리고 솔트가 고유하기 때문에, 공격자에게는 무차별 대입 공격이 훨씬 더 비용이 많이 듭니다.

이것이 실제로 어떻게 보이는지 보겠습니다. bcrypt로(비용 12를 사용하여) "splync1234" 비밀번호를 해싱하면 다음과 같은 문자열이 생성될 수 있습니다: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. 이 bcrypt 문자열에서 `$2b`는 알고리즘 버전을 나타내고, `$12`는 비용 요소(비밀번호가 처리되는 횟수)를 나타내며, `gBeouKYdue9uvvuV0HtGgeV`는 고유한 무작위 솔트, `PymnrojMqP/wcRw28HFlGEGIQbyw7O`는 최종 해시된 비밀번호입니다. 해시 자체가 솔트와 비용을 포함하고 있기 때문에 Splync는 저장된 문자열에서 이러한 값을 추출하고 결과를 비교하여 동일한 해싱 과정을 검증할 수 있습니다. 반면, 공격자가 솔트와 비용을 모른다면, 모든 사용자에게 적용되는 단일 레인보우 테이블을 만들 수 없습니다.

이 방식에는 또 하나의 중요한 장점이 있습니다. Splync는 평문 비밀번호를 절대 저장하지 않기 때문에, 데이터베이스가 유출되거나 도난당하더라도 사용자는 즉각적인 위험에 노출되지 않습니다. 공격자는 도난당한 데이터로 직접 로그인할 수 없습니다. 그들이 가진 것은 뒤섞인 문자열뿐입니다. 이 설계는 서버 자체를 둘러싼 안전 장치 외에 사용자에게 추가 보안 레이어를 제공합니다. 비밀번호 해싱은 Splync만의 것이 아니며, Google, Apple, Amazon 같은 대기업에서도 사용되는 기술 산업의 표준입니다. Splync는 매우 안전하게 설계되었으며, 이메일 인증, 무차별 대입 보호, 지속적인 모니터링 같은 기능으로 보안을 계속 강화하면서 더욱 안전해질 것입니다.