비밀번호 규칙 정하기
가입 화면이 손님 비밀번호에 거는 조건이에요. 너무 빡세면 손님이 가입을 포기하고, 너무 느슨하면 계정이 털려요. 요즘 권장 기준은 예전 상식과 거의 반대예요.
쉽게 말하면
가게 출입문의 자물쇠 개수예요. 손님이 들어올 때마다 자물쇠 세 개를 풀고 지문까지 대야 한다면, 손님은 그냥 옆 가게로 가요. 반대로 문을 활짝 열어 두면 도둑이 들고요. 비밀번호 규칙은 도둑이 아니라 손님이 매번 통과하는 문이라서, 무조건 세게 거는 게 아니라 한 동작으로 열리면서도 튼튼한 자물쇠를 고르는 일이에요.
비밀번호 규칙이란 가입 화면이 손님 비밀번호에 거는 조건이에요. "몇 자 이상으로 하세요", "특수문자를 섞으세요" 같은 것들이요.
이 조건은 양쪽 다 돈으로 이어져요. 너무 빡세면 조건을 못 맞춘 손님이 가입 도중에 나가고, 너무 느슨하면 계정이 도용돼서 환불과 문의가 몰려와요.
손님은 조건 맞추다 지쳐 나가고, 남은 손님은 뻔한 패턴으로 조건만 채워요. 빡센데 안전하지도 않아요.
손님은 한 번에 통과하고, 기계 공격은 길이 앞에서 막혀요. 편한데 더 안전해요.
요즘 권장 기준은 예전 상식과 반대예요
"특수문자 넣고 석 달마다 바꿔라"는 오랫동안 상식이었는데, 보안 기준을 만드는 기관들이 실제 유출 사고를 분석하고 나서 권고를 공식적으로 뒤집었어요. 지금 새로 만드는 가입 화면은 바뀐 기준으로 만드는 게 맞아요.
| 항목 | 예전 상식 | 요즘 권장 | 왜 바뀌었나 |
|---|---|---|---|
| 길이 | 6~8자면 충분 | 최소 8자, 위로는 넉넉하게 허용 | 기계가 대입해 보는 공격에는 글자 수 하나하나가 벽이에요. 길이가 강도의 몸통이에요 |
| 특수문자 | 반드시 섞게 강제 | 강제하지 않기 | 강제하면 사람들이 끝에 !와 1을 붙이는 식으로 뻔하게 채워요. 공격 프로그램은 그 패턴을 이미 알아요 |
| 정기 변경 | 90일마다 바꾸게 하기 | 유출 정황이 있을 때만 바꾸게 하기 | 강제로 자주 바꾸게 하면 사람들은 뒤 숫자만 하나 올려요. 보안은 안 늘고 짜증만 늘어요 |
| 흔한 비밀번호 | 따로 검사 안 함 | 유출 목록·흔한 조합은 차단 | 실제 도용은 기발한 해킹보다 12345678 같은 뻔한 비밀번호와 유출된 비밀번호에서 나요 |
핵심은 길이예요
짧고 복잡한 것보다 길고 단순한 것이 강해요. 공격 프로그램은 특수문자에 안 속고 길이에 지쳐요. 그래서 손님에게 특수문자를 강요하는 대신, 긴 비밀번호를 넉넉히 받아 주는 쪽이 정답이에요.
확인해 보세요
손님 계정을 지키는 데 더 강한 비밀번호는 어느 쪽일까요?
내 가입 화면에 이렇게 걸어요
규칙은 코드가 아니라 말로 정하는 것이에요. 스튜디오에서 가입 화면을 만들 때 아래 다섯 가지를 그대로 말하면 돼요.
- 1"비밀번호는 8자 이상으로 받고, 긴 비밀번호도 다 받아 주세요" 라고 말해요. 아래 기준은 8자, 위 기준은 사실상 없는 게 요즘 방식이에요.
- 2"12345678 같은 흔한 비밀번호는 막아 주세요" 라고 덧붙여요. 가게 이름이나 password 같은 뻔한 조합도 같이요. 실제 도용의 큰 몫이 여기서 막혀요.
- 3"비밀번호 칸에 붙여넣기를 막지 말아 주세요" 라고 챙겨요. 비밀번호 앱을 쓰는 손님이 가장 안전한 손님인데, 붙여넣기를 막으면 그 손님부터 내쫓는 셈이에요.
- 4"조건을 입력칸 아래에 미리 보여 주고, 비밀번호 보기 단추도 달아 주세요" 라고 해요. 제출한 뒤에야 반려당하면 손님은 두 번째 시도를 잘 안 해요.
- 5"로그인을 연달아 틀리면 잠깐 막아 주세요" 로 마무리해요. 규칙이 좋아도 무한정 대입해 볼 수 있으면 소용없어요.
실제로 이런 일이 생겨요
장면 하나 · 조건이 빡센 가입 화면
“가입 버튼을 누른 사람은 많은데 완료한 사람이 적어요. 화면이 고장 난 걸까요?”
고장이 아니라 문턱인 경우가 많아요. 특수문자와 대문자 조건에 세 번 반려당한 손님은 네 번째 시도를 안 하고 나가요. 조건을 길이 위주로 줄이고, 무엇이 틀렸는지 입력칸 바로 아래에서 알려 주게 바꾸면 완료율이 눈에 띄게 달라져요. 어느 단계에서 나가는지 보는 법은 깔때기에 있어요.
장면 둘 · 로그인한 적 없는 손님의 항의
“손님이 "내 계정에서 모르는 주문이 결제됐다"고 연락이 왔어요. 우리가 해킹당한 건가요?”
우리 서버가 뚫린 게 아니라 다른 사이트에서 새어 나온 비밀번호가 여기서 재사용된 경우가 훨씬 흔해요. 손님들이 같은 비밀번호를 여러 곳에 돌려쓰기 때문이에요. 흔한 비밀번호 차단과 로그인 실패 횟수 제한이 이 공격의 성공률을 크게 낮추고, 그래도 뚫린 계정이 나오면 사고가 났을 때 순서대로 움직이면 돼요.
자주 묻는 것
- Q. 손님 비밀번호를 제가 확인할 수 있어야 하지 않나요?
- 아니에요, 사장님도 못 보는 게 정상이에요. 제대로 만든 서비스는 비밀번호를 되돌릴 수 없는 형태로 바꿔 저장해서 아무도 원문을 못 봐요. 관리 화면에서 손님 비밀번호가 글자로 보인다면 그게 오히려 위험 신호이고, 바로 고쳐 달라고 해야 해요.
- Q. 석 달마다 바꾸라고 안내 메일을 보내야 하나요?
- 보내지 않는 게 요즘 권장이에요. 주기적 변경을 강요하면 손님은 뒤 숫자만 올린 비슷한 비밀번호를 만들어요. 바꾸게 하는 건 유출 정황이 있을 때 한 번이면 되고, 그때는 이유를 함께 알려 주는 게 예의예요.
- Q. 비밀번호 강도 막대는 달아야 하나요?
- 있으면 좋지만 순서가 뒤예요. 길이 기준, 흔한 비밀번호 차단, 붙여넣기 허용이 먼저이고, 강도 막대는 그 위에 얹는 안내 장치예요. 막대만 있고 차단이 없으면 빨간 막대를 보고도 그냥 가입할 수 있어요.
- Q. 아예 비밀번호 없이 받을 수는 없나요?
- 있어요. 카카오나 구글로 들어오는 소셜 로그인을 쓰면 비밀번호 규칙 고민 자체가 그쪽으로 넘어가요. 손님 입장에서도 버튼 하나라 문턱이 낮고요. 방식별 차이는 로그인과 인증에서 비교해요.
- Q. 한글 비밀번호도 받아야 하나요?
- 받는 서비스가 드물어요. 비밀번호 입력칸은 대부분 영문·숫자·기호 기준으로 만들어져 있고, 손님도 그 습관에 익숙해요. 무리해서 예외를 만들기보다, 영문 기준에서 길이를 넉넉히 받아 주는 쪽이 실속 있어요.
하나 더
가입 완료율이 낮아서 규칙을 손보려고 해요. 어느 쪽이 맞을까요?
직접 해보기
가입 화면에 규칙을 직접 걸어 보세요
스튜디오에서 회원가입이 있는 화면을 만들 때 "비밀번호는 8자 이상으로 받고, 흔한 비밀번호는 막고, 붙여넣기는 허용해 주세요" 라고 말해 보세요. 이 한 문장이 이 문서의 절반이에요.
스튜디오 열기더 깊이 (안 읽어도 괜찮아요)
특수문자 강제가 왜 역효과인가 · 규칙이 빡세지면 사람은 창의적으로 강해지는 게 아니라 예측 가능하게 순응해요. 대문자를 요구하면 첫 글자만 대문자로 쓰고, 숫자를 요구하면 끝에 1을 붙이고, 특수문자를 요구하면 그 옆에 !를 붙여요. 공격 프로그램은 사람들의 이 습관을 규칙으로 넣어서 대입하기 때문에, 강제 조건이 만들어 낸 복잡함은 계산에 이미 포함돼 있어요. 그래서 조건을 늘릴수록 손님만 힘들고 공격자는 별로 안 힘들어지는 결과가 나와요.
자물쇠 비유가 다른 점 하나 · 출입문 자물쇠는 문 앞의 도둑만 상대하지만, 비밀번호는 다른 동네에서 훔친 열쇠 꾸러미로도 공격당해요. 손님이 다른 사이트에 쓰던 비밀번호가 그쪽 사고로 유출되면, 공격자는 그 목록을 우리 로그인 창에 자동으로 넣어 봐요. 손님도 우리도 잘못한 게 없는데 문이 열리는 거예요. 흔한 비밀번호 차단, 실패 횟수 제한, 그리고 2단계 인증이 이 공격을 각각 다른 지점에서 끊어요.
규칙의 반은 저장 방식이에요 · 아무리 좋은 규칙으로 받아도 서버가 비밀번호를 원문 그대로 저장하면 유출 사고 한 번에 전부 무너져요. 그래서 제대로 만든 서비스는 받자마자 되돌릴 수 없는 형태로 바꿔서 저장하고, 로그인 때는 변환 결과끼리만 비교해요. 스튜디오에서 만든 로그인도 이 방식이 기본이지만, 외주로 만들었다면 "비밀번호를 원문으로 저장하나요?"라고 한 번 물어볼 가치가 있어요. 답이 "네"면 그 자리에서 고쳐 달라고 하세요.
이것만 기억하세요
- ·비밀번호 규칙은 손님이 매번 지나는 문이에요. 무조건 세게가 아니라 편하면서 튼튼하게 거는 거예요
- ·요즘 기준은 길이가 몸통이에요. 8자 이상으로 받고 긴 비밀번호를 환영해요
- ·특수문자 강제와 주기적 변경 강요는 옛 방식이에요. 이탈만 늘고 보안은 거의 안 늘어요
- ·12345678 같은 흔한 비밀번호 차단과 로그인 실패 횟수 제한이 실제 도용을 막아요
- ·손님 문은 낮게, 관리자 문은 높게요. 직원 계정은 2단계 인증까지 켜요