사용자 계정, 인증, 비밀번호 관리에 대한 13가지 권장사항 (2021년 버전)

* 본 아티클의 원문은 2021년 5월 7일 Google Cloud 블로그(영문)에 게재되었습니다.  

2021년 업데이트: 이 게시물에는 사용자 및 시스템 아키텍트 모두를 대상으로 작성된 Google의 비밀번호 관리 권장사항 백서의 최신 정보를 비롯하여 업데이트된 권장사항이 포함되어 있습니다.

계정 관리, 인증, 비밀번호 관리는 까다로운 작업일 수 있습니다. 계정 관리는 개발자나 제품 관리자의 우선순위에서 밀려날 때가 많습니다. 그 결과, 데이터 보안 및 사용자 경험이 사용자 기대에 못 미치는 경우가 종종 발생합니다.

다행히 Google Cloud에서는 사용자 계정(고객이나 내부 사용자 등 시스템에 자신을 식별하는 대상)의 생성, 안전한 처리, 인증과 관련해 적절한 결정을 내릴 수 있도록 도와주는 여러 가지 도구를 제공하고 있습니다. Google Kubernetes Engine에 호스팅된 웹사이트, Apigee의 API, Firebase를 사용하는 앱 또는 인증된 사용자가 있는 기타 서비스 등 담당하고 있는 업무가 무엇이든 상관없이 이 게시물은 안전하고 확장 및 사용 가능한 계정 인증 시스템을 마련하려면 따라야 할 권장사항을 제시합니다.

1. 비밀번호를 해시(hash)하세요.

계정 관리에서 가장 중요한 규칙은 비밀번호를 포함한 민감한 사용자 정보를 안전하게 저장하는 것입니다. 이 데이터를 신중하게 취급하고 적절하게 처리해야 합니다.

어떤 상황에서도 일반 텍스트 비밀번호를 저장해서는 안 됩니다. 대신 서비스에서 Argon2id 또는 Scrypt를 통해 생성된 복원 불가능하며 강력하게 암호화된 비밀번호 해시를 저장해야 합니다. 이 해시는 특정 로그인 사용자 인증 정보에 고유한 값으로 솔트 처리되어야 합니다. MD5, SHA1 등 지원 중단된 해싱 기술을 사용하지 말고 어떤 상황에서도 복원 가능한 암호화를 사용하면 안 되며 자체 해싱 알고리즘을 고안하려고 해서도 안 됩니다. 데이터베이스에 저장되지 않는 페퍼를 사용하면 보안 침해가 발생했을 때 데이터를 추가적으로 보호할 수 있습니다. 비밀번호를 여러 차례 반복적으로 다시 해싱할 때의 이점을 고려해 보세요.

결국에는 시스템이 손상될 것이라는 가정 하에 설계하세요. '오늘 데이터베이스가 무단 반출된다면 내 서비스나 사용자가 이용하는 다른 서비스에서 사용자의 안전과 보안이 위험에 처하게 될 것인가?', '데이터 유출 시 잠재적인 피해를 줄이기 위해 무엇을 할 수 있을 것인가?'를 자문해 보세요.

또한 사용자가 비밀번호를 제공한 직후를 제외하고 언제든지 일반 텍스트로 사용자 비밀번호를 생성할 수 있다면 구현에 문제가 있는 것입니다.

'Password'를 'pAssword1'로 변경하는 등 중복에 가까운 비밀번호를 시스템에서 감지해야 한다면 모든 문자를 정규화하고 소문자로 변환하여 금지하고자 하는 일반적인 변형의 해시를 저장합니다. 비밀번호가 생성될 때 또는 기존 계정에 로그인할 때 이러한 작업을 수행할 수 있습니다. 사용자가 새 비밀번호를 만들면 동일한 유형의 변형을 생성하여 해시를 이전 비밀번호와 비교합니다. 실제 비밀번호와 동일한 수준의 해싱 보안을 사용하세요. 

2. 가능하다면 타사 ID 공급업체를 허용하세요.

타사 ID 공급업체를 이용하면 신뢰할 수 있는 외부 서비스로 사용자 ID를 인증할 수 있습니다. 흔히 사용되는 공급업체로는 Google, Facebook, Twitter가 있습니다.

Identity Platform과 같은 플랫폼을 사용하면 기존의 내부 인증 시스템과 함께 외부 ID 공급업체를 구현할 수 있습니다. Identity Platform에는 관리 간소화, 공격에 노출되는 영역 감소, 멀티 플랫폼 SDK 등 여러 가지 이점이 있습니다. 이 목록에서 그 밖의 이점을 자세히 살펴보겠습니다.

3. 사용자 ID와 사용자 계정의 개념을 구분하세요.

사용자는 이메일 주소가 아닙니다. 전화번호나 고유한 사용자 이름도 아닙니다. 계정의 콘텐츠나 개인 식별 정보(PII)를 변경하지 않고도 이러한 인증 요소를 바꿀 수 있어야 합니다. 사용자는 단순히 사용자 인증 정보를 합친 것이 아닌, 서비스 내의 고유하고 개인화된 데이터 및 경험을 종합한 다차원적인 개념입니다. 잘 설계된 사용자 관리 시스템에서는 여러 사용자 프로필 요소 간의 결합이 느슨하고 응집도가 높습니다.

사용자 계정과 사용자 인증 정보의 개념을 구분하면 타사 ID 공급업체를 구현하는 프로세스가 크게 간소화되어 사용자가 사용자 이름을 변경할 수 있고 여러 ID를 단일 사용자 계정에 연결할 수 있습니다. 실질적으로 모든 사용자에게 추상적인 내부 전역 식별자가 있고 사용자의 프로필을 한 레코드에 모두 쌓아두는 것이 아니라 해당 ID를 통해 하나 이상의 인증 데이터 세트와 연결하는 것이 도움이 될 수 있습니다.

4. 여러 ID를 단일 사용자 계정과 연결하도록 허용하세요.

사용자 이름과 비밀번호를 사용해 서비스에 인증한 사용자가 이후 중복 계정이 생성될 수 있다는 사실을 모른 채 Google 로그인을 선택할 수도 있습니다. 마찬가지로 사용자에게 여러 이메일 주소를 서비스에 연결해야 할 합당한 사유가 있을 수 있습니다. 사용자 ID와 인증을 구분한 상태라면 간단한 프로세스를 통해 여러 인증 방법을 단일 사용자에게 연결할 수 있습니다.

백엔드에서는 사용자가 가입 프로세스를 일부 또는 전부 진행하고 나서야 시스템의 기존 계정에 연결되어 있지 않은 새로운 타사 ID를 사용하고 있음을 깨달을 가능성을 고려해야 합니다. 가장 간단하게 해결하는 방법은 사용자에게 이메일 주소, 전화번호 또는 사용자 이름과 같은 일반적인 식별 세부정보의 제공을 요청하는 것입니다. 해당 데이터가 시스템의 기존 사용자와 일치하면 사용자에게 알려진 ID 공급업체를 통해 인증하고 새 ID를 기존 계정에 연결하도록 요청하세요.

5. 길거나 복잡한 비밀번호를 차단하지 마세요.

NIST에서는 비밀번호 복잡성 및 안전성 강도에 대한 가이드라인을 발표하고 있습니다. 비밀번호 저장에 강력한 암호화 해시를 사용하고 있거나 조만간 사용할 예정이라면 많은 문제가 해결됩니다. 해시는 입력 길이에 관계없이 항상 고정된 길이의 출력을 생성하므로 사용자가 원하는 만큼 긴 비밀번호를 사용할 수 있습니다. 비밀번호 길이를 제한해야 한다면 인프라 한도에 따라 길이를 제한하세요. 보통 메모리 사용량(로그인 작업당 메모리 사용량 * 머신당 잠재적 동시 로그인 수)이나 서버에서 허용하는 최대 POST 크기를 기준으로 합니다. 수백 KB에서 1MB 이상에 이르는 길이의 입력이 발생할 수 있습니다. 대량 입력으로 인한 악용을 방지하기 위해 애플리케이션을 미리 강화해야 합니다. 크리덴셜 스터핑을 막고 최대한 빨리 입력을 해시하여 메모리를 확보하는 제어 기능을 구현하면 악용 기회가 새로 발생하지 않습니다.

해싱된 비밀번호는 이미 소규모의 ASCII 문자 집합으로 구성되어 있을 가능성이 높습니다. 그렇지 않다고 해도 바이너리 해시를 쉽게 Base64로 변환할 수 있습니다. 이를 염두에 두고 사용자가 자신이 원하는 모든 문자를 비밀번호에 사용하도록 허용해야 합니다. 사용자가 클링온어, 이모티콘, 양쪽 끝에 공백이 있는 ASCII art로 구성된 비밀번호 사용을 원하더라도 이를 거부할 기술적 이유가 없어야 합니다. 다만 유니코드 정규화를 수행해 크로스 플랫폼 호환성을 보장하세요. 유니코드와 비밀번호에 지원되는 문자에 대한 자세한 내용은 Google 시스템 설계자 백서(PDF)를 참조하세요.

사용자가 매우 복잡한 비밀번호를 사용하기를 원한다면 제한된 휴대기기 키보드에서도 복잡한 비밀번호를 입력할 수 있는 비밀번호 관리자의 사용을 포함한 비밀번호 권장사항(PDF)을 따르면 됩니다. 사용자가 첫 번째 자리에 문자열을 입력할 수 있다면(즉, 비밀번호 입력의 HTML 사양에서 줄 바꿈 및 캐리지 리턴을 허용하지 않는 경우) 비밀번호가 허용되어야 합니다.

6. 사용자 이름에 부당한 규칙을 적용하지 마세요.

사이트나 서비스에서 2~3자(영문 기준)가 넘는 사용자 이름을 요구하고 숨겨진 문자를 차단하며 사용자 이름의 시작과 끝에 공백을 허용하지 않는 것은 부당합니다. 그럼에도 8자(영문 기준) 이상의 길이를 요구하거나 7비트 ASCII 문자 및 숫자 이외의 문자를 차단하는 사이트도 있습니다.

사이트에서 사용자 이름을 엄격하게 제한하는 것이 개발자의 작업을 수월하게 만들 수 있지만 그 대가로 사용자가 불편을 겪게 되며 극단적인 경우 사용자 이탈을 초래하기도 합니다.

사용자 이름을 할당하는 것이 가장 좋은 방법인 경우도 있습니다. 서비스가 이러한 경우에 해당한다면 사용자가 할당된 사용자 이름을 기억하고 소통할 수 있도록 사용자 친화적이어야 합니다. 영숫자로 생성된 ID의 경우 'Il1O0'과 같이 시각적으로 모호한 기호는 피해야 합니다. 또한 사용자 이름에 의도하지 않은 메시지가 포함되지 않도록 임의로 생성한 문자열에 대한 사전 검사를 수행하는 것이 좋습니다. 자동 생성된 비밀번호에도 동일한 가이드라인이 적용됩니다.

7. 사용자 ID를 검증하세요.

사용자에게 연락처 정보를 요청하는 경우 최대한 빨리 연락처를 검증해야 합니다. 이메일 주소나 전화번호로 검증 코드 또는 링크를 보내세요. 검증을 거치지 않으면 사용자가 오타가 있는 연락처 정보를 입력한 후 다음에 로그인하려고 할 때 서비스에서 상당한 시간을 들인 후에야 자신의 정보와 일치하는 계정이 없음을 깨닫게 될 수 있습니다. 이러한 계정은 고립되어 수동 개입 없이는 복구가 불가능할 때가 많습니다. 더욱 심각한 상황은 입력한 연락처 정보가 타인의 정보여서 계정에 대한 모든 권한이 제3자에게 넘어가는 것입니다.

8. 사용자가 사용자 이름을 변경할 수 있도록 허용하세요.

기존 시스템이나 이메일 계정을 제공하는 플랫폼에서 사용자가 사용자 이름을 변경할 수 없도록 금지하는 경우가 매우 흔합니다. 사용자 이름을 다시 사용할 수 있도록 자동으로 해제하지 않는 데에는 타당한 근거가 있습니다. 그러나 시스템의 장기 사용자는 다른 사용자 이름을 사용해야 할 유의미한 이유가 생겼지만 새로운 계정을 만들고 싶지는 않은 경우가 발생할 수 있습니다.

별칭을 허용하고 사용자가 기본 별칭을 선택할 수 있도록 허용하면 사용자 이름 변경에 대한 사용자의 의사를 존중할 수 있습니다. 이 기능 외에도 필요한 모든 비즈니스 규칙을 적용할 수 있습니다. 조직에서 연간 사용자 이름 변경 횟수를 제한하거나 사용자가 기본 사용자 이름 외의 다른 사용자 이름을 표시하거나 다른 사용자 이름으로 연락할 수 없도록 막는 경우도 있습니다. 이메일 주소 제공업체는 이메일 주소를 재발행하지 않는 것이 좋습니다. 하지만 이전 이메일 주소를 새 이메일 주소의 별칭으로 지정할 수는 있습니다. 혁신적인 이메일 주소 제공업체에서는 사용자가 자신의 도메인 이름을 가져오고 원하는 주소를 사용하도록 허용하기도 합니다.

기존 아키텍처를 사용한다면 이 권장사항을 충족하는 것이 매우 어려울 수 있습니다. Google과 같은 기업에도 이를 실제로 구현하기 어렵게 만드는 기술적 장애 요소가 존재합니다. 새로운 시스템을 설계할 때 사용자 ID와 사용자 계정의 개념을 구분하고 여러 ID를 단일 사용자 계정에 연결할 수 있도록 노력을 기울이면 문제가 크게 줄어들 것입니다. 기존 코드를 사용하든 새로운 코드를 사용하든 시간이 지나면서 사용자가 성장하고 변화할 수 있도록 지원하는 데 중점을 두고 조직에 적합한 규칙을 선택하세요.

9. 사용자가 계정을 삭제할 수 있도록 허용하세요.

사용자가 계정 및 연결된 PII를 삭제할 수 있는 셀프서비스 수단을 제공하지 않는 서비스가 상당히 많습니다. 서비스 성격에 따라 게시물 및 업로드 등 사용자가 만든 공개 콘텐츠가 포함되거나 포함되지 않을 수 있습니다. 사용자가 계정을 영구적으로 해지하고 모든 PII를 삭제해야 할 이유에는 여러 가지가 있습니다. 이러한 우려사항이 사용자 경험, 보안, 규정 준수 요구사항과 균형을 이루어야 합니다. 대부분은 아닐지라도 많은 시스템이 적어도 일부 사용자 데이터의 데이터 보관에 관한 구체적인 가이드라인을 제공하는 규제 통제(PCI 또는 GDPR 등) 하에 작동합니다. 규정 준수 우려를 해소하고 정보 유출 가능성을 제한할 수 있는 일반적인 해결책은 사용자가 예약을 통해 향후 계정을 자동으로 삭제할 수 있도록 지원하는 것입니다.

사용자의 PII 삭제 요청을 적시에 처리해야 한다는 준수해야 할 법적 의무가 있는 경우도 있습니다. 또한 '폐쇄'된 계정에서 데이터가 유출되는 정보 유출에 노출될 위험이 매우 커집니다.

10. 세션 길이를 신중하게 결정하세요.

보안 및 인증에서 종종 간과되는 요소가 바로 세션 길이입니다. Google은 사용자 정보의 진위 여부를 확인하는 데 많은 노력을 기울이며 특정 이벤트나 동작을 기반으로 다시금 확인합니다. 사용자가 보안을 더 강화하는 조치를 취할 수 있습니다.

서비스에 중요하지 않은 분석을 위해 세션을 무기한 열어 두어야 할 충분한 이유가 있을 수도 있지만 특정 기준을 충족하면 비밀번호, 2단계 인증 또는 기타 사용자 확인을 요청해야 합니다.

다시 인증하기 전에 사용자가 비활성 상태로 있을 수 있는 기간을 고려하세요. 누군가가 비밀번호를 재설정하는 경우에는 모든 활성 세션에서 사용자 ID를 확인해야 합니다. 사용자가 프로필의 핵심 요소를 변경하거나 민감한 작업을 수행할 때는 인증 또는 2단계 인증을 요청하세요. 사용자 위치가 단기간 내에 크게 바뀐 경우 재인증해야 합니다. 동시에 하나 이상의 기기나 위치에서 로그인하지 못하도록 막는 것이 적합할지 고민해 보세요.

서비스에서 사용자 세션을 만료하거나 재인증해야 하는 경우 사용자에게 실시간으로 메시지를 표시하거나 마지막으로 인증한 이후 저장되지 않은 활동을 보존할 수 있는 메커니즘을 제공하세요. 오랜 시간을 들여 양식을 작성했는데 입력한 내용이 모두 사라지고 다시 로그인해야 한다면 사용자가 큰 불편을 느끼게 됩니다.

11. 2단계 인증을 사용하세요.

2단계 인증(MFA 또는 2FA) 방법을 선택할 때는 계정을 도난당한 사용자에게 미칠 실질적인 영향을 고려하세요. 시간 기반의 일회용 비밀번호(TOTP), 이메일 인증 코드 또는 '매직 링크'는 소비자 친화적이며 비교적 안전합니다. SMS 2단계 인증은 여러 가지 취약점으로 인해 NIST에서 지원 중단했지만 사용자가 중요하지 않다고 여기는 서비스에서 수용하는 가장 안전한 옵션일 수 있습니다.

합리적으로 제공할 수 있는 가장 안전한 2단계 인증을 제공하세요. 애플리케이션에서 구현할 수 있다면 Titan 보안 키와 같은 하드웨어 2단계 인증이 이상적입니다. 애플리케이션에서 TOTP 라이브러리를 사용할 수 없더라도 타사 ID 공급업체에서 제공하는 이메일 인증 또는 2단계 인증을 사용하면 큰 비용이나 노력 없이 간단하게 보안을 강화할 수 있습니다. 사용자 계정은 가장 약한 2단계 인증 또는 계정 복구 방법만큼만 안전하다는 사실을 기억하세요.

12. 대소문자를 구분하지 않는 사용자 ID를 지원하세요.

사용자가 사용자 이름의 대소문자를 대수롭지 않게 여기거나 정확히 기억하지 못할 수 있습니다. 사용자 이름에서 대소문자를 구분하지 않아야 합니다. 사용자 이름과 이메일 주소를 모두 소문자로 저장하고 비교 전에 입력을 소문자로 변환하는 것은 간단한 작업입니다. 변환 시 언어를 지정하거나 유니코드 정규화를 사용하세요.

스마트폰이 사용자 기기에서 차지하는 비율이 계속 증가하고 있습니다. 대부분의 스마트폰은 일반 텍스트 필드의 자동 수정과 자동 대문자 표시 기능을 제공합니다. UI 수준에서 이 동작을 막는 것은 바람직하지 않거나 큰 효과가 없을 수 있으며 의도치 않게 자동으로 대문자로 표시된 이메일 주소나 사용자 이름을 서비스에서 처리할 수 있어야 합니다.

13. 안전한 인증 시스템을 구축하세요.

Identity Platform과 같은 서비스를 사용하는 경우 많은 보안 우려사항이 자동으로 해결됩니다. 그렇더라도 악용을 방지하도록 서비스를 항상 적절하게 엔지니어링해야 합니다. 핵심 고려사항으로는 비밀번호 가져오기가 아닌 비밀번호 재설정 구현, 자세한 계정 활동기록 로깅, 크리덴셜 스터핑 방지를 위한 로그인 시도 횟수 제한, 특정 횟수 이상 로그인 시도 실패 후 계정 잠금, 인식되지 않은 기기 또는 장기간 유휴 상태가 지속된 계정에 2단계 인증 요청 등이 포함됩니다. 아래의 추가 자료 섹션에서 보안 인증 시스템의 여러 측면에 대한 자세한 내용을 참조하세요.  

추가 자료

계정 및 인증 관리 시스템을 개발, 업데이트 또는 마이그레이션하는 프로세스를 안내하는 여러 유용한 자료가 있습니다. 먼저 다음 자료부터 살펴보시기 바랍니다.

• Google의 시스템 설계자를 위한 최신 비밀번호 보안 백서(PDF)
• 관련 가이드인 사용자를 위한 최신 비밀번호 보안 백서(PDF)
• NIST 800-063B의 인증 및 수명 주기 관리 
• OWASP에서 지속적으로 업데이트하는 비밀번호 저장 요약본 
• OWASP에서 자세한 내용을 설명한 인증 요약본
• Google Cloud Identity Platform: 강력한 인증 기능이 포함된 멀티 프로토콜 고객 ID 및 액세스 관리 솔루션
• Google의 Firebase 인증 사이트에서 제공하는 가이드, 참조 자료, 샘플 코드 라이브러리