Hashing, 생각보다 훨씬 중요한 기본기

해싱(Hashing)은 데이터를 고정 길이의 임의 값으로 변환하는 과정이다.

예를 들어:

hello
↓
2cf24dba5fb0...

입력값이 아무리 길어도 결과는 항상 일정한 길이로 나온다.
실제로는 웹 서비스 전반에 엄청 깊게 들어가 있다.

로그인
JWT 서명
파일 무결성 검사
캐시 키
CDN
블록체인
Git

생각보다 해시는 거의 모든 곳에 존재한다.

해시의 핵심 특징

1. 단방향성

해시값으로 원본 데이터를 복원할 수 없다.

password123
↓
ef92b778bafe...

결과값만 보고 원래 문자열을 알아내는 건 사실상 불가능하다.

그래서 비밀번호 저장에 사용된다.

복호화가 아니라 검증을 한다.

입력값을 해싱해서 저장된 값과 비교만 한다

2. 결정론적

같은 입력은 항상 같은 결과를 만든다.

SHA-256("hello")
=> 항상 동일한 결과

이 특징 덕분에 데이터 비교나 무결성 검증이 가능하다.

Node.js에서의 crypto

import crypto from 'node:crypto';

const hash = crypto
  .createHash('sha256')
  .update('hello')
  .digest('hex');

console.log(hash);

처음 보면 그냥 “문자열 변환기” 같지만,
사실 여기엔 엄청 중요한 보안 개념들이 숨어 있다.

특히 나는 여기서 가장 크게 착각했던 게 있었다.

SHA-256을 쓰면 비밀번호 저장도 안전한 줄 알았던 것.

근데 그건 절반만 맞는 이야기였다.

SHA-256이 안전한데 왜 비밀번호 저장엔 위험할까?

SHA-256 자체는 현재까지 매우 안전한 해시 알고리즘이다.

문제는

너무 빠르다.

라는 점이다.

“빠른 해시”는 비밀번호에선 오히려 위험하다

처음엔 이해가 안 갔다.

빠르면 좋은 거 아닌가?

근데 공격자 입장에서 생각해보면 달라진다.

GPU 하나로 초당 수십억 번의 해시 계산이 가능하다.

123456
password
qwerty
admin123

이런 비밀번호를 엄청난 속도로 무차별 대입할 수 있다는 뜻이다.

SHA-256은 데이터 검증엔 훌륭하지만,
비밀번호 저장엔 너무 효율적이다.

보안에서 “효율적”이라는 건 가끔 공격자에게도 효율적이라는 뜻이 된다.

이 지점이 꽤 인상 깊었다.

그래서 bcrypt, scrypt, Argon2가 등장했다

이 알고리즘들은 공통적으로

일부러 느리게 만든다.

처음엔 왜 일부러 느리게 만드는지 이해가 안 됐는데,
이게 핵심이었다.

서버 입장에선 로그인 1번 느린 건 괜찮다.

근데 공격자는 수억 번 시도해야 한다.

즉, “조금 느림”이 공격자에겐 엄청난 비용이 된다.

bcrypt

가장 오래되고 널리 사용되는 비밀번호 해시 알고리즘이다.

bcrypt.hash(password, saltRounds);

bcrypt의 핵심 특징

Salt 자동 생성
같은 비밀번호여도 결과가 매번 다름
연산 intentionally slow
cost factor 조절 가능

특히 Salt 개념이 중요했다.

예전엔

1234
→ 같은 해시

라서 Rainbow Table 공격이 가능했는데,

bcrypt는 랜덤 Salt를 섞는다.

1234 + random salt

그래서 같은 비밀번호라도 결과가 전부 달라진다.

처음 bcrypt를 보면 가장 헷갈리는 부분이 바로 그거다.

“Salt가 랜덤이면 로그인할 때마다 결과가 달라지는데 어떻게 비교하지?”

핵심은

bcrypt 해시 결과 안에 Salt 정보가 같이 들어있다.

bcrypt는 결과 안에 Salt를 저장한다

예를 들어

$2b$10$KYVbZ5JFVfqu0oV98LnF5eTk4QTe2e4PQG7QNYfhumEpGdi/867AO

이 문자열 전체가 단순 해시값이 아니다.

안에는:

알고리즘 정보 (2b)
cost factor (10)
salt
실제 hash

가 전부 들어있다.

즉 bcrypt는

"해시 결과만 저장"

하는 게 아니라

"검증에 필요한 정보까지 통째로 저장"

한다.

왜 Salt가 중요한가

Salt가 없으면

은 전 세계 모든 서비스에서 같은 해시가 된다.

공격자는 미리 계산해둔 Rainbow Table을 사용할 수 있다.

근데 Salt가 들어가면:

123456 + 랜덤 salt

라서 사이트마다 결과가 전부 달라진다.

공격자가 미리 계산 불가능
같은 비밀번호 사용자도 구분 가능
대규모 크랙 효율 감소

효과가 생긴다.

그래서 bcrypt API가 좋은 이유

직접 구현할 필요가 거의 없다.

await bcrypt.hash(password, 10)
await bcrypt.compare(password, hash)

만 쓰면

Salt 생성
Salt 저장
재해싱
비교

를 전부 내부에서 처리한다.

scrypt

bcrypt의 한계는 “메모리”

bcrypt는 CPU 연산량을 늘리는 데 집중한다.

"계산을 느리게 만들자"

에 가까운 접근이다.

문제는 현대 GPU가 이런 반복 계산에 엄청 강하다는 거다.

GPU는 원래

그래픽 렌더링
대규모 병렬 처리
반복 계산

에 최적화되어 있다.

그래서 공격자는 GPU 수백~수천 코어를 이용해 엄청난 속도로 bcrypt를 병렬 시도할 수 있다.

물론 bcrypt도 여전히 강력하지만, 하드웨어 성능이 발전할수록 한계가 드러나기 시작했다.

여기서 처음 느꼈다.

보안 알고리즘은 수학만의 문제가 아니구나.

실제로는

CPU 구조
GPU 구조
메모리 대역폭
병렬 처리

같은 하드웨어 레벨까지 연결되어 있었다.

scrypt가 등장한 이유

scrypt는 여기서 접근 자체를 바꾼다.

"계산을 많이 시키자"

가 아니라,

"메모리도 엄청 쓰게 만들자"

라는 전략을 선택했다.

이걸 Memory-hard라고 부른다.

왜 메모리를 많이 쓰게 만드는 게 중요할까?

CPU는 비교적 메모리 접근에 강하다.

근데 GPU는 다르다.

GPU는

병렬 계산엔 매우 강함
하지만 대용량 메모리를 각 코어에 충분히 제공하기 어렵다

계산만 많은 알고리즘
→ GPU 매우 유리

하지만:

메모리까지 많이 필요한 알고리즘
→ GPU 효율 급감

하게 된다.

쉽게 비유하면

bcrypt는

"문제를 엄청 많이 풀어라"

에 가깝다.

GPU는 이런 걸 잘한다.

근데 scrypt는

"문제를 많이 풀고,
책상도 엄청 크게 써라"

같다.

그러면 GPU가 가진 제한이 드러난다. 수천 개 코어를 동시에 돌리려면
수천 개가 각각 큰 메모리를 필요로 하기 때문이다. 이 순간부터 공격 비용이 폭발적으로 증가한다.

결국 보안은 “공격 비용” 싸움이었다

이걸 공부하면서 보안에 대한 관점이 꽤 바뀌었다.

예전엔

"절대 못 뚫게 만들기"

가 보안이라고 생각했다.

근데 실제론

"뚫는 비용을 말도 안 되게 높이기"

에 더 가까웠다.

그런데 왜 지금은 Argon2가 더 권장될까?

scrypt도 충분히 강력하다.

근데 시간이 지나면서 또 새로운 요구사항이 생겼다.

더 유연해야 하고
더 세밀한 튜닝이 가능해야 하고
다양한 공격 모델을 대응해야 했다.

그래서 나온 게 Argon2다.

세밀하게 조절가능한 Argon2

Argon2의 핵심

Argon2는 다음 요소들을 세밀하게 조절할 수 있다.

메모리 사용량
반복 횟수
병렬성
CPU 사용량

즉:

"얼마나 느리게?"
"메모리를 얼마나?"
"병렬 실행을 얼마나?"

를 상황에 맞게 튜닝 가능하다.

이게 엄청 중요하다. 왜냐면 서버 환경마다 다르기 때문이다.

예를 들어

작은 서버
고성능 서버
모바일 환경
클라우드 환경

전부 최적값이 다르다.

Argon2는 그걸 조절 가능하게 만든다.

내 생각

지금은 이렇게 느낀다.

SHA-256 → 데이터 검증
bcrypt → 여전히 강력한 현실적 선택
scrypt → GPU 방어 강화
Argon2id → 현재 가장 현대적인 접근

예전엔 충분히 안전했던 방식도, 하드웨어가 발전하면 다시 재설계된다.

결국 보안은 “완벽한 방패”를 만드는 게 아니라,

계속 변화하는 공격 환경에 맞춰 비용을 조절하는 과정

인것 같다