[영상 리뷰] 비밀번호 규제

시작하기 전에

해당 글은 코딩애플님의 영상 '한국에만 있는 이상한 비밀번호 규제' 에 대한 리뷰 및 추가 공부를 위해 작성된 정리글입니다.

영상 자체가 매우 알기 쉽게 잘 설명되어 있으니, 본문을 읽기 전에 아래 링크의 영상을 먼저 시청하시는 것을 추천드립니다:

https://www.youtube.com/watch?v=LtvPRQuw81Y

 

 

영상을 보신 분들은 'Refresh token이란?'부터 보시면 됩니다.

---

0. 상황

비번을 교체하라는 페이지, 비번에 특수문자를 포함시키라는 알림 등을 본 적이 있을 거다.

보안이 중요한 은행 사이트들은 이해라도 되는데, 일반 사이트들까지 이렇게 하는 이유는 뭘까?

---

1. 법

IT가 워낙 빠르게 들어온 국가다 보니 웹사이트 관련 규정들이 몇 개 있었다:

• 매출 100억 이상 서비스들은 개인정보 이용내역을 매년 스팸메일로 통지해야 하고,
• 1년 이상 미접속한 회원은 별도로 분리해서 보관해야 해서 휴면기능을 구현해야 하며,
• 문자, 숫자, 특수문자를 어떻게 조합해서 비밀번호를 만들어라,
• 유효기간을 정해서 해당 기간이 지나면 비번을 변경해야 하도록 하는 등.

이러한 규정들은 쓸데없다는 걸 깨닫고 몇 년 전에 폐지가 되었다.

하지만 여전히 이를 일반 유저한테 적용하는 경우가 많다.

왜 그럴까?

---

2. 인증

매출액이 100억 이상인 웹 서비스들은 ISMS라는 인증 도장을 꼭 받아야 한다.

이는 내 서비스가 정보 보호를 잘하는지 검사를 받고, 통과하면 도장을 찍어주는 제도다.

이를 받으려면 가이드북에 따라 개발을 해야 하는데, 그 안에 쓸데없는 비번 제도들이 있다.

원래 있던 비번 관련 법 규정들은 잦은 비번 변경은 불편만 초래한다는 이유로 몇 년 전에 폐지되었는데,

ISMS에는 반영이 안 되어있다.

---

3. 보안에 좋은데요?

보안에 좋지 않은가라는 반박을 할 수 있지만,

실제 우리를 생각해보면 '다음에 변경하기' 버튼이 있으면 그 버튼을 누르고,

그 버튼이 없는 사이트의 경우에는 원래 비번 뒤에 숫자나 특수문자 같은 거 하나 추가해서 바꾼다.

따라서 이게 보안적으로 의미가 있는 것인지는 전혀 모르겠다.

---

4. 특수문자

미국 국립표준기술연구소(NIST)에서 주기적으로 발행하는 가이드라인(Digital Identity Guidelines)의 패스워드 권장사항을 보면

비번을 주기적으로 변경하는 것은 하지 말라고 나와있으며

연속된 문자 금지, 특수문자 강제도 하지 말라고 한다.

더 안전하게 만들려면 차라리 길게 만들거나 2단계 인증을 쓰라고 한다.

또한 별표로 표시되는 비번을 눈 버튼 누르면 비번이 보이게 하는 기능도 좋다는 말도 써있다.

비번칸에 복붙도 허용하라고 되어있다. 그렇게 해야 어려운 패스워드 입력이 쉬워지니까.

 

세션정보를 로컬 스토리지에 보관하지 마라,

쿠키는 이렇게 써라,

등의 내용도 나와있다고 한다.

---

5. 잦은 로그인

최근에 개발자들 사이에서 인기를 끄는 글이 있는데, 로그인을 자주 시키는 게 오히려 안 좋다는 내용이다.

자주 로그인하는 것보다 인증할 때마다 추가 인증하는 게 도움되지 않느냐는 의견이 대세다.

왜냐하면 패스워드는 입력할 때마다 노출될 위험이 늘어나는 것이기 때문이다. (피싱, 스니핑, 키로깅, 숄더서핑)

어차피 로그인 로직을 구현할 때 "refresh token"이라는 걸 쓸 수 있는데,

이는 로그인할 때마다 랜덤문자를 발급해주고, 로그인이 만료되었을 때 이걸 자동 제출되게 하는 것이다.

그래서 그 토큰이 아무 이상이 없으면 로그인 연장이 되도록 한다.

refresh token은 재사용 못하게 일회용으로도 만들 수 있어서 훨씬 더 안전하게 쓸 수 있다.

---

6. 은행은

더 엄격한 기준이 있다.

'코딩을 어떻게 하라'는 가이드라인이 빡세게 있다.

5회 틀렸을 때 거래 정지하는 이유도 여기에 있다.

은행앱 접속하면 이상한 보안패드로 비번 입력하게 하는 이유도 여기에 있다.

 

올해 개정판 보면 항목을 절반이나 날려버렸다.

보안 정책 같은 건 자율적으로 결정하고 결과만 책임지면 된다고 써있다.

그래서 앞으로 은행앱 UI도 달라지지 않을까 싶다.

---

여기까지가 코딩애플님의 영상 내용입니다. 비밀번호에 굉장히 불필요한 프로세스가 많았네요.

Refresh token만 한 번 더 자세히 다뤄보겠습니다.

---

Refresh token이란?

Refresh token은 사용자 인증 시스템에서 access token이 만료되었을 때 새로운 access token을 발급받기 위해 사용하는 토큰이다.

주로 OAuth 2.0, JWT(Json Web Token) 기반 인증 시스템에서 사용된다.

---

개념 요약

Access Token

• 유효 시간이 짧음 (예: 15분 ~ 1시간)
• 클라이언트가 서버에 요청할 때 인증 수단으로 사용됨
• 보안 강화를 위해 자주 만료됨

Refresh Token

• 유효 시간이 김 (예: 며칠 ~ 몇 주)
• Access token이 만료되었을 때, 새 access token을 받기 위해 사용
• 보통 서버에 안전하게 저장하거나 HTTP-only cookie로 관리

---

동작 흐름 예시

사용자가 로그인하면:

• 서버가 access token과 refresh token을 발급
• Acess token은 API 요청에 사용
• Refresh token은 백그라운드에 사용

Access token이 만료되면:

• 클라이언트는 refresh token을 이용해 서버에 새 access token을 요청
• 서버는 refresh token이 유효하면 새 access token을 발급

Refresh token도 만료되거나 탈취되면:

• 사용자는 다시 로그인해야 함

---

Refresh token을 사용하는 이유

• 보안 강화: access token은 짧은 시간만 유효하므로 탈취되어도 위험이 낮음
• 사용자 경험 개선: 사용자가 자주 다시 로그인할 필요 없이 자동으로 토큰 갱신 가능
• 서버 측 통제 가능: refresh token을 통해 로그인 상태를 보다 세밀하게 제어할 수 있음 (예: 강제 로그아웃 등)

---

HTTP-only Cookie란?

HTTP-only cookie는 Javascript로 접근할 수 없는 쿠키이다.

오직 웹 서버와의 HTTP 요청/응답에서만 전송되고, 브라우저 내 스크립트(예: XSS 공격)는 읽을 수 없습니다.

 

즉, refresh token을 HTTP-only cookie에 저장하는 이유도

악성 스크립트가 refresh token을 훔칠 수 없어 훨씬 안전하기 때문이다.

저장 방식	설명	보안 측면
LocalStorage	JS에서 쉽게 접근 가능	XSS에 취약
SessionStorage	페이지 세션 동안만 유지	XSS에 취약
HTTP-only Cookie	JS에서 접근 불가, 서버만 읽을 수 있음	XSS 방지

---

마치며

비밀번호 규정에 대해 공부해봤는데 흥미로운 내용이 많네요.

예전에 스타트업에서 로그인 기능을 직접 개발할 때, 쿠키와 세션 관해서 엄청 검색했던 기억이 떠오르네요.

이런 규제나 보안 이슈들도 하나하나 맥락을 알고 보면 훨씬 재밌게 다가오는 것 같습니다.