본문 바로가기
공부/KISA

비밀번호 관리 - KISA 소프트웨어 개발 보안 가이드

by Skogkatt의 개인 블로그 2020. 7. 10.
반응형

https://www.kisa.or.kr/public/laws/laws3.jsp

 

기술안내서 가이드 < 관련법령·기술안내서 < 자료실 : 한국인터넷진흥원

기술안내서 가이드 한국인터넷진흥원 기술안내서 가이드 입니다. 게시판 목록 보기 기술안내서 가이드 표 대분류 소분류 기술안내서 가이드 대상 수준 인터넷 진흥 및 이용 활성화 인터넷 진흥

www.kisa.or.kr


분석∙설계단계 SW 보안강화 - 설계보안항목 정의 및 설계 시 고려 사항 - 비밀번호 관리

설명

  • 안전한 비밀번호 조합규칙(비밀번호 길이, 허용 문자 조합 등)을 설정하고, 안전한 저장 정책, 재설정 및 변경 정책, 패스워드 관리규칙(주기적 변경 등)이 적용되도록 설계해야 한다.

설계항목내용

  • 패스워드를 설정할 때 한국인터넷진흥원의 『암호이용안내서』 의 패스워드 생성 규칙을 적용해야 한다.
  • 네트워크를 통해 패스워드를 전송하는 경우 반드시 패스워드를 암호화하거나 암호화된 통신 채널을 이용해야 한다.
  • 패스워드 저장 시, 솔트가 적용된 안전한 해쉬 함수를 사용해야 하며, 해쉬함수 실행은 서버에서 해야 한다.
  • 패스워드 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.
  • 패스워드 관리 규칙을 정의해서 적용해야 한다.

가. 취약점 개요

사례 1: 취약한 비밀번호 사용
  • 회원가입 시에 안전한 패스워드 규칙이 적용되지 않아서 취약한 패스워드로 회원가입이 가능할 경우 무차별 대입 공격을 통해 패스워드가 누출될 수 있다.
사례 2: 취약한 비밀번호 복구
  • 패스워드 복구 메커니즘(아이디/패스워드 찾기 등)이 취약한 경우 공격자가 불법적으로 다른 사용자의 패스워드를 획득, 변경, 복구할 수 있다.
사례 3: 하드코드 된 비밀번호
  • 프로그램 코드 내부에 하드코드된 패스워드를 포함하고, 이를 이용하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우, 관리자 정보가 노출될 수 있어 위험하다. 또한, 코드 내부에 하드코드 된 패스워드가 인증 실패를 야기하는 경우, 시스템 관리자가 그 실패의 원인을 파악하기 쉽지 않다

 

나. 설계 시 고려사항

1. 패스워드를 설정할 때 한국인터넷진흥원 『암호이용안내서』의 패스워드 설정 규칙을 적용해야 한다.

2. 네트워크를 통해 패스워드를 전송하는 경우 반드시 패스워드를 암호화하거나 암호화된 통신 채널을 이용해야 한다.

  • 웹브라우저와 같은 클라이언트와 웹서버 간의 통신이나 서버와 서버 간의 통신 등 인터넷과 같은 공중망 환경에서는 패스워드와 같은 중요정보를 송·수신하는 경우 보호대책이 필요하다. 이러한 보호대책으로 TLS, VPN 등과 같은 다양한 통신 암호기술을 적용할 수 있다.
  • 시스템 관리자 및 보안 관리자는 TLS를 적용하거나 관련 솔루션을 도입할 때 제품이 표준에 맞게 구현되었는지와 상호 호환성을 보장하는지 및 검증된 제품인지, 오픈소스를 이용하는지 등을 확인해야 한다.
  • 아래는 NIST에서 제정한 TLS버전별로 안전하게 이용할 수 있는 암호화 알고리즘 구성이다.

3. 패스워드 저장 시, 솔트가 적용된 안전한 해쉬함수를 사용해야 하며, 해쉬함수 실행은 서버에서 해야 한다.

  • 패스워드는 복호화되지 않는 일방향 해시 함수를 사용해서 암호화하여 저장해야 한다.
일방향 해시함수는 수학적인 연산을 통해 원본 메시지를 변환하여 암호화된 메시지인 다이제스트를 생성한다. 원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 '일방향성'이라고 한다.

 

SHA‐256과 같은 해시 함수를 사용해 패스워드를 암호화해 저장하고 값을 비교하는 것만으로 충분한 암호화 메커니즘을 적용했다고 생각하지만, 동일한 메시지는 동일한 다이제스트를 가지게 되는 구조 이므로 무작위 대입을 통한 원본 문자열의 인식 가능성(recognizability)의 문제가 있고, 또한 해쉬함수의 빠른 처리 속도 덕분에 공격자도 매우 빠른 속도로 임의의 문자열을 다이제스트 할 수 있으므로 속도 (speed)의 문제점을 가질 수 있다. 이 문제점을 해결하기 위해 솔트(salt) 값을 추가하여 해시함수를 실행한다. 솔트(salt)는 일방향 해시 함수에서 다이제스트를 생성할 때 추가되는 바이트 단위의 임의의 문자열이다. 예를 들어 패스워드가 "!t0Et67d3" 이라면 여기에 랜덤하게 생성된 솔트인 "rG7f32‐1 dYjfgfd‐9F3fgd‐l4fGdg‐f4Tmlf"를 추가해 다이제스트를 생성하게 되면, 공격자가 "!t0Et67d3"의 다이 제스트를 알아내더라도 솔트 값이 추가된 다이제스트를 대상으로 패스워드 일치 여부를 확인하는 것이 어렵게 된다. 솔트와 패스워드의 다이제스트를 데이터베이스에 저장하고, 사용자가 로그인할 때 입력한 패스워드를 해쉬하여 일치 여부를 확인한다. 즉 모든 패스워드가 고유의 솔트를 갖고 솔트의 길이가 32바이트 이상이면 솔트와 다이제스트를 추측하기 어렵다.

 

4. 패스워드 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

  • 패스워드 변경은 주기적인 변경과 분실 시 재설정으로 나누어 볼 수 있다.
(ㄱ) 패스워드 변경
  • 사용자 및 관리자는 안전한 패스워드 관리를 위해 주기적으로 패스워드를 변경하여 패스워드의 노출 위협을 최소화하여야 한다. 일반적으로 사용자 패스워드 변경주기는 3개월에서 6개월 이하로 설정하는 것을 고려할 수 있다.
  • 사용자는 자신의 패스워드가 제삼자에게 노출되었을 경우 즉시 새로운 패스워드로 변경해야 한다. 패스워드 변경 시 이전에 사용하지 않은 새로운 패스워드로 변경해야 하며, 패스워드 변경 시 이전의 패스워드와 연관 성이 없어야 한다.
(ㄴ) 패스워드 재설정
  • 패스워드를 잊어버렸거나 분실하는 경우 패스워드 재설정이 필요하다. 이 경우에 “패스워드 찾기” 기능을 사용해야 한다면 이메일과 질의‐답변을 통해 반드시 해당 사용자에게만 패스워드 정보를 전달해야 하며 올바른 패스워드가 입력되기 전에는 이메일 등 개인정보를 수정할 수 없도록 해야 한다. 질의‐답변 검증 시 일정 횟수 이상 정답을 맞히지 못하면 패스워드 찾기 기능을 잠금 해야 한다. 검증 후 기존의 패스워드가 아닌 임시 패스워드를 발급하도록 설계해야 하며 사용자는 임시패스워드를 발급받은 즉시 새로운 패스워드로 재설정해야 한다.
  • 시스템은 언제든지 사용자가 자신의 패스워드를 변경할 수 있게 패스워드 변경 기능을 제공하도록 설계한다.

5. 패스워드 관리 규칙을 정의해서 적용해야 한다.

  • 안전한 패스워드 관리를 위해 다음과 같은 항목을 고려할 수 있다.
(ㄱ) 변경주기
  • 패스워드는 3개월(또는 6개월)마다 주기적으로 변경하도록 해야 한다.
(ㄴ) 만료기간 설정
  • 일정기간 시스템 사용자에 대해서는 패스워드 만료기간을 설정해야 한다
  • 사용자 테이블에 개인정보 변경주기를 추가한 뒤 일단위로 해당 필드가 업데이트되도록 한다. 패스워드 기간이 만료되면 로그인 시 사용자에게 패스워드 변경을 요청하고, 패스워드 변경 시 개인정보 변경주기를 초기화하도록 시큐어코딩 규칙을 정의한다.
(ㄷ) 성공한 로그인 시간 관리
  • 마지막으로 성공한 로그인 시간 정보를 관리해야 한다.
  • 사용자 테이블에 마지막으로 로그인한 시간 정보를 저장하고 사용자에게 알림으로써 계정 도용 여부를 점검할 수 있도록 개발 가이드 구현 단계를 작성한다.
A. 패스워드 생성 개인 패스워드는 사용자가 직접 생성하고 그룹 패스워드는 그룹의 장이 생성하여 구성원들에게 안전한 방법을 통해 전달한다. 
B. 패스워드 사용 패스워드는 제삼자에게 노출되지 않도록 해야 하며, 자신의 패스워드와 관련된 정보 및 힌트를 제공하지 않아야 한다. 패스워드 변경주기는 3개월(또는 6개월)이다. 시스템 및 소프트웨어의 초기 패스워드는 설치 시 즉시 변경해야 한다.
C. 패스워드 폐기 패스워드는 사용용도가 끝나거나 사용주기가 지난 경우 폐기한다. 인증 패스워드는 시스템 담당자가 사용자 계정의 삭제와 함께 폐기하고, 암호화 패스워드는 사용자가 직접 폐기한다.

참고자료

 

 

반응형

댓글