인증대상 및 방식

인증대상 및 방식

보안대책

-       중요기능이나 리소스에 대해서는 인증 후 사용 정책이 적용되어야 한다

-       안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

-       중요기능에 대해 2단계(2 factor)인증을 고려해야 한다

 

취약전 개요

중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는

경우 중요 정보나 리소스가 노충될 수 있다.

설계 시 고려사항

a.     중요기능이나 리소스에 대해서는 인증 후 사용정책이 적용되어야 한다

분석 단계에 분류된 중요기능에 대해 인증 후 사용 정책이 반드시 적용될 수 있도록 한다

각각의 중요기능에서 인증을 요청하도록 구현하는 것은 쉽지 않다 시스템 설계 시 중요기능을

분류하고 식별된 중요기능에 대해 일괄적으로 인증을 요구하도록 시스템이 구성되도록 설계한다

이 경우 직접적으로 기능과 인증을 매핑시켜 처리하는 컴포넌트를 개발하거나 인증기능을

제공하는 프레임워크 또는 라이브러리를 활용하여 중앙집중식 인증이 적용되도록 설계한다

 

b.     안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

인증정보는 서버 측에 저장하여 인증이 필요한 기능이나 리소스에 접근을 시도할 때 서버에서 인증 여부를

확인할 수 있도록 해야한다

. 일회용 패스워드 사용시

일회용 패스워드를 적용하는 경우 타서비스나 시스템과의 연동이 보장되도록 설계해야 한다.

일회용 패스워드를 도입하는 경우 다음과 같은 규칙을 적용하여 설계한다.

  ./ 일회용 패스워드는 시각정보, 이벤트정보, 질의 응답 방식으로 취득한 정보를 이용해 생성할 수 있다

  ./ 시각정보 기반의 연계정보는 특정시간 동안만 유효하여야 하며, 이벤트/질의 응답 방식을 사용할 경우에는

     연계 정보를 추측할 수 없도록 보호방안을 제공할 수 있어야 한다.

  ./ 일회용 패스워드에는 시간적 제한을 설정해야 한다(금융영역에서는 30-60초)

  ./ 일회용 패스워드는 중복 및 유추가 불가능하도록 6자리 이상의 숫자 및 문자로 구성한다.

  ./ OTP 발생기와 인증서버에서 동일한 정보를 생성해야 한다

 

c.     중요기능에 대해 2단계(2 factor)인증을 고려해야 한다.

중요기능에 대해 멀티 디바이스(SMS,ARS 등)를 이용한 추가인증이나, 공인인증서, 바이오정보(지문, 홍채 등)를

이용한 전자서명 인증기술을 이용한 2단계 인증을 고려해야 한다.

2단계인증은 Type1(패스워드/PIN등 지식기반인증), Type2(토큰/스마트카드 등 소유기반 인증), Type3(지문/홍채 등

생체기반 인증)중 2개 이상의 인증기번을 사용하도록 설계한다.

 

 

연관된 구현단계 보안약점 항목

입력 데이터 검증 및 표현 : 서버사이드 요청 위조

보안 기능 : 적절한 인증 없는 중요기능 허용

           부적절한 인증서 유효성 검증

API오용  : DNS lookup에 의존한 보안 결정

 

인증 수행 제한

보안 대책 : 로그인 기능 구현 시, 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

             실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야 한다.

 

취약점 개요

로그인 시도에 대한 횟수를 검사하지 않으면 로그인 시도 횟수와 상관없이 지속적으로 로그인 시도가 이루어지는

패스워드 무차별 대입 공격이 시도되어 계정정보가 노출될 수 있다.

 

설계시 고려사항

a.     로그인 기능 구현 시 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

로그인 시도횔수를 3-5번 이내로 제한하고 이를 초과하여 로그인에 실패하는 경우 추가 입력값을 요구하거나

계정 잠금을 수행하도록 다음과 같은 메커니즘으로 설계한다.

. 사용자ID별,세션ID별 로그인 횟수를 추적하기 위해 사용자 DB테이블에 로그인 실패 횟수,

계정 잠금 여부, 마지막으로 성공 실패한 로그인 시간정보, 로그아웃 시간정보등을 저장할 수 있도록 설계하고

일정 횟수 이상 연속적으로 로그인 실패 시 사용자 ID와 패스워드 이외 추가적인 정보를 확인하도록한다.

 

계정정보 입력시 자동입력 방지문자와 같은 장치를 마련하도록 설계한다.

 

b.     실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야한다.

반복된 로그인 실패에 대한 로깅 정책을 설정하고 로그 기록으로 허용되지 않은 로그인 시도를 분석 할 수 있도록 설계한다.

 

연관된 구현단계 보안약점 항목

  보안 기능 : 반복된 인증시도 제한기능 부재

 

 

 

비밀번호 관리

보안대책 : 비밀번호 설정 시 한국인터넷진흥원 패스워드 선택 및 이용 안내서 의 패스워드 보안 지침을 적용한다.

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

            비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록 해야한다.

            비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

            비밀번호 관리 규칙을 정의해서 적용해야 한다.

 

취약점 개요

 

    취약한 비밀번호 사용

     회원가입 시 안전한 비밀번호 생성 규칙이 적용되지 않아서 취약한 비밀번호호 회원가입이 가능할 경우 무차별 대입 공격으로 패스워드가 누출될 수 있다

    

 

취약한 비밀번호 복구

비밀번호 복구 메커니즘(아이디/패스워드 찾기 등)이 취약한 경우 공격자가 불법적으로 다른 사용자의 비밀번호를 획득 변경 복구할 수 있다.

하드코드된 비밀번호

  프로그램 코드 내부에 비밀번호를 하드 코딩하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우

  관리자용 계정 정보가 노출될 수 있어 위험하다, 또한 코드 내부에 하드코드된 비밀번호가 인증실패를 야기하는 경우

  시스템 관리자가 그 실패의 원인을 파악하기 쉽지 않다

 

설계시 고려 사항

a.     비밀번호 설정시 한국인터넷진흥원 패스워드 선택 및 이용안내서 의 안전한 패스워드 생성 규칙을 적용

안전한 패스워드

-       두 종류 이상의 문자구성과 8자리 이상의 길이로 구성된 문자열

-       문자 종류는 알파벳 대소문자 특수문자 숫자 등 4가지

-       10자리 이상의 길이로 구성된 문자열

-       숫자로만 구성할 경우 취약할 수 있음

 

안전하지 않은 패스워드

-       특정 패턴을 갖는 패스워드

-       동일한 문자의 반복(예 : 123123), 키보드 상 연속한 위치에 존재하는 문자열(예:qwerty),수자가 제일 앞이나 뒤에 오는 구성 (예: 1security)

-       제3자가 알 수 있는 개인정보를 바탕으로 구성

-       가족,이름,생일,주소,휴대전화 번호를 포함하는 패스워드

-       이용자 ID를 이용

-       이용자 ID가 kisa일 경우 패스워드를kisa1등으로 설정

-       한글,영어 등 사전적 단어로 구성 (예 바다나라 , love12 등)

-       특정 인물이나 널리 알려진 단어를 포함하는 패스워드

-       사이트,기업명,연예인 이름등의 특정 명칭을 의미

-       숫자와 염누자를 비숫하 문자로 치환한 형태로 구성

-       영문자 O를 숫자 0으로 영문자 I를 숫자 1로 치환등

-       시스템에서 초기 설정되거나 예제로 제시된 패스워드

-       한글의 발음을 영문으로 영문단어의 발음을 한글로 변경한 형태의 패스워드

 

b.     네트워트로 비밀번호를 전송하는 경우 반드시 비밀번호를 암호화하거나 암호화된 통신 채널을 이용해야 한다.

웹브라우저와 같은 클라이언트와 웹서버 간의 통신 서버와 서버간의 통신 등 인터넷과 같은 공중망 환경에서는

패스워드와 같은 중요정보를 송 수신하는 경우 보호대책이 필요하다 이러한 보호대책으로 TLS,VPN 등과 같은 다양한 통신 암호기술을 적용할 수 있다

시스템관리자 및 보안관리자는 TLS를 적용하거나 관련 솔루션을 도입할 때 제품이 표준에 부합하는지 상호호환성을 보장하는지

검증된 제품인지 오픈소스를 이용하는지 안전한 암호 알고리즘을 적용하는지 등을 확인해야 한다.

- TLS 최신 버전(예 : TLS 1.2 및 TLS 1.3)만 지원하고 한국인테넷진흥원 암호 알고리즘 및 키 길이 이용안내서를 참고하여 안전한 암호 알고리즘 조합 적용

 

c.     비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록해야 한다

비밀번호는 복호화 되지 않는 일방향 해시 함수를 사용해서 암호화하여 저장해야 한다.

 

           일방향 해시 함수

           일방향 해시함수는 수학적인 연산으로 원본메세지를 변환하여 암호화된 메시지인 다이제스트를 생성한다

           원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 일방향성 이라고 한다

 

        일방향 해시 함수의 문제점

           일부에서는 SHA-256과 같은 해시 함수를 사용해 비밀번호를 암호화하여 저장하고 인증 요청시 저장된 값과 비교하는 것만으로

           충분한 암호화 메커니즘을 적용했다고 행각하지만, 해시 함수는 동일한 메시지는 동일한 다이제스트로 생성되는 구조이므로 무차별 대입으로

           원본 문자열의 인식 가능성의 문제가 존재하며, 해시함수의 빠른 처리 속도 덕분에 공격자도 매우 빠른 속도로 임의의 문자열을 가질 수 있다

           이러한 문제점을 해결하기 위해 솔트(salt)값을 추가하여 해시함수를 실행한다. 솔트(salt)는 일방향 해시 함수에서 다이제스트를 생성할 때

           추가되는 바이트 단위의 임의의 문자열이다. 예를 들어 비밀번호가 "!t0Et67d3" 이라면 여기에 랜덤하게 생성된 솔트인 “rG7f32‐1dYjfgfd‐9F3fgd‐l4fGdg‐f4Tmlf”를

           추가해 다이제스트를 생성하면 공격자가 "!t0Et67d3" 의 다이제스트를 알아내더라도 솔트 값이 추가된 다이제스트를 대상으로 비밀번호 일치

여부를 확인하는 것이 어렵게 된다.

솔트와 비밀번호의 다이제스트를 데이터베이스에 저장하고 사용자가 로그인할 때 입력한 비밀번호를 해시하여 일치 여부를 확인하므로 즉 모든 패스워드가

고유의 솔트를 갖고 솔트의 길이가 32바이트 이상이면 솔트값이 노출되지 않은 이상 다이제스트를 추측하기 어렵다

 

d.     비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

비밀번호 변경은 주기적인 변경과 분실 시 재설정으로 나누어 볼 수 있다.

./ 비밀번호 변경

   사용자 및 관리자는 안전한 비밀번호 관리를 주기적으로 비밀번호를 변경하여 비밀번호의 노출위협을 최소화하여야 한다.

사용자는 자신의 비밀번호가 제3자에게 노출되었을 경우 즉시 새로운 비밀번호로 변경해야 하며 비밀번호 변경 시 이전의 비밀번호와 연관성이 없어야 한다

        ./ 비밀번호 재설정

          비밀번호를 잊어버렸거나 부실하는 경우 비밀번호 재설정이 필요한다. 이 경우에 비밀번호 찾기 기능을 사용해야 한다면 이메일과 질의 답변으로 반드시 해당

          사용자에게만 비밀번호 정보를 전달해야 하며 올바른 비밀번호가 입력되기 전에는 이메일 등 개인정보를 수정할 수 없도록 해야 한다. 질의-답변 검증 시 일정

          횟수 이상 정답을 맞히지 못하면 비밀번호 찾기 기능을 사용하지 못하도록 설정해야 한다. 검증 후 기존의 비밀번호가 아닌 임시비밀번호를 발급하도록 설계해야

          하며 사용자는 임시 비밀번호를 발급받은 즉시 새로운 비밀번호로 재설정해야 한다.

 

e.     비밀번호 관리 규칙을 정의해서 적용해야 한다.

안전한 비밀번호 관리를 위해 다음과 같은 항목을 고려할 수 있다.

./ 변경주기

   비밀번호는 3개월(또는 6개월)마다 주기적으로 변경하도록 해야 한다.

./ 만료기간 설정

   일정기간 시스템 사용자에 대해서는 비밀번호 만료기간을 설정해야 한다.

   사용자 테이블에 개인정보 변경주기를 추가한 뒤 일단위로 해당 필드가 업데이트되도록 한다.

   비밀번호 기간이 만료되면 로그인 시 사용자에게 비밀번호 변경을 요청하고 비밀번호 변경 시

   비밀번호 변경주기를 초기화 하도록 시큐어코딩 규칙을 정의한다.

./ 성공한 로그인 시간관리

   마지막으로 성공한 로그인 시간 정보를 관리해야 한다. 사용자 테이블에 마지막으로 로그인한 시간정보를 저장하고

   사용자에게 알림으로써 계정도용 여부를 점검할 수 있도록 개발가이드 구현단계를 작성한다.

 

비밀번호 관리 주기

비밀번호 생성

  개인 비밀번호는 사용자가 직접 생성하고 그룹 비밀번호는 그룹의 장이 생성하여 구성원들에게 안전한 방법으로 전달한다.

비밀번호 사용

  비밀번호는 제 3자에게 노출되지 않도록 해야 하며, 자신의 비밀번호와 관련된 정보 및 힌트를 제공하지 않아야 한다.

  비밀번호 변경주기는 3개월(또는 6개월)이다. 시스템 및 소프트웨어의 초기 비밀번호는 설치 시 즉시 변경해야 한다.

비밀번호 폐기

  비밀번호는 사용용도가 끝나거나 사용주기가 지난 경우 폐기한다. 인증 비밀번호는 시스템 담당자가 사용자 계정의

  삭제와 함께 폐기하고 암호화 비밀번호는 사용자가 직접 폐기한다.

 

 

연관된 구현 단계 보안 약점 항목

  보안기능 하드코딩된 중요정보, 취약한 비밀번호 허용보안대책

-       중요기능이나 리소스에 대해서는 인증 후 사용 정책이 적용되어야 한다

-       안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

-       중요기능에 대해 2단계(2 factor)인증을 고려해야 한다

 

취약전 개요

중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는

경우 중요 정보나 리소스가 노충될 수 있다.

 

설계 시 고려사항

a.     중요기능이나 리소스에 대해서는 인증 후 사용정책이 적용되어야 한다

분석 단계에 분류된 중요기능에 대해 인증 후 사용 정책이 반드시 적용될 수 있도록 한다

각각의 중요기능에서 인증을 요청하도록 구현하는 것은 쉽지 않다 시스템 설계 시 중요기능을

분류하고 식별된 중요기능에 대해 일괄적으로 인증을 요구하도록 시스템이 구성되도록 설계한다

이 경우 직접적으로 기능과 인증을 매핑시켜 처리하는 컴포넌트를 개발하거나 인증기능을

제공하는 프레임워크 또는 라이브러리를 활용하여 중앙집중식 인증이 적용되도록 설계한다

 

b.     안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

인증정보는 서버 측에 저장하여 인증이 필요한 기능이나 리소스에 접근을 시도할 때 서버에서 인증 여부를

확인할 수 있도록 해야한다

. 일회용 패스워드 사용시

일회용 패스워드를 적용하는 경우 타서비스나 시스템과의 연동이 보장되도록 설계해야 한다.

일회용 패스워드를 도입하는 경우 다음과 같은 규칙을 적용하여 설계한다.

  ./ 일회용 패스워드는 시각정보, 이벤트정보, 질의 응답 방식으로 취득한 정보를 이용해 생성할 수 있다

  ./ 시각정보 기반의 연계정보는 특정시간 동안만 유효하여야 하며, 이벤트/질의 응답 방식을 사용할 경우에는

     연계 정보를 추측할 수 없도록 보호방안을 제공할 수 있어야 한다.

  ./ 일회용 패스워드에는 시간적 제한을 설정해야 한다(금융영역에서는 30-60초)

  ./ 일회용 패스워드는 중복 및 유추가 불가능하도록 6자리 이상의 숫자 및 문자로 구성한다.

  ./ OTP 발생기와 인증서버에서 동일한 정보를 생성해야 한다

 

c.     중요기능에 대해 2단계(2 factor)인증을 고려해야 한다.

중요기능에 대해 멀티 디바이스(SMS,ARS 등)를 이용한 추가인증이나, 공인인증서, 바이오정보(지문, 홍채 등)를

이용한 전자서명 인증기술을 이용한 2단계 인증을 고려해야 한다.

2단계인증은 Type1(패스워드/PIN등 지식기반인증), Type2(토큰/스마트카드 등 소유기반 인증), Type3(지문/홍채 등

생체기반 인증)중 2개 이상의 인증기번을 사용하도록 설계한다.

 

 

연관된 구현단계 보안약점 항목

입력 데이터 검증 및 표현 : 서버사이드 요청 위조

보안 기능 : 적절한 인증 없는 중요기능 허용

           부적절한 인증서 유효성 검증

API오용  : DNS lookup에 의존한 보안 결정

 

인증 수행 제한

보안 대책 : 로그인 기능 구현 시, 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

             실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야 한다.

 

취약점 개요

로그인 시도에 대한 횟수를 검사하지 않으면 로그인 시도 횟수와 상관없이 지속적으로 로그인 시도가 이루어지는

패스워드 무차별 대입 공격이 시도되어 계정정보가 노출될 수 있다.

 

 

설계시 고려사항

a.     로그인 기능 구현 시 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

로그인 시도횔수를 3-5번 이내로 제한하고 이를 초과하여 로그인에 실패하는 경우 추가 입력값을 요구하거나

계정 잠금을 수행하도록 다음과 같은 메커니즘으로 설계한다.

. 사용자ID별,세션ID별 로그인 횟수를 추적하기 위해 사용자 DB테이블에 로그인 실패 횟수,

계정 잠금 여부, 마지막으로 성공 실패한 로그인 시간정보, 로그아웃 시간정보등을 저장할 수 있도록 설계하고

일정 횟수 이상 연속적으로 로그인 실패 시 사용자 ID와 패스워드 이외 추가적인 정보를 확인하도록한다.

 

계정정보 입력시 자동입력 방지문자와 같은 장치를 마련하도록 설계한다.

 

b.     실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야한다.

반복된 로그인 실패에 대한 로깅 정책을 설정하고 로그 기록으로 허용되지 않은 로그인 시도를 분석 할 수 있도록 설계한다.

 

연관된 구현단계 보안약점 항목

  보안 기능 : 반복된 인증시도 제한기능 부재

 

 

 

비밀번호 관리

보안대책 : 비밀번호 설정 시 한국인터넷진흥원 패스워드 선택 및 이용 안내서 의 패스워드 보안 지침을 적용한다.

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

            비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록 해야한다.

            비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

            비밀번호 관리 규칙을 정의해서 적용해야 한다.

 

취약점 개요

 

    취약한 비밀번호 사용

     회원가입 시 안전한 비밀번호 생성 규칙이 적용되지 않아서 취약한 비밀번호호 회원가입이 가능할 경우 무차별 대입 공격으로 패스워드가 누출될 수 있다

     

 

취약한 비밀번호 복구

비밀번호 복구 메커니즘(아이디/패스워드 찾기 등)이 취약한 경우 공격자가 불법적으로 다른 사용자의 비밀번호를 획득 변경 복구할 수 있다.

 

하드코드된 비밀번호

  프로그램 코드 내부에 비밀번호를 하드 코딩하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우

  관리자용 계정 정보가 노출될 수 있어 위험하다, 또한 코드 내부에 하드코드된 비밀번호가 인증실패를 야기하는 경우

  시스템 관리자가 그 실패의 원인을 파악하기 쉽지 않다

 

 

설계시 고려 사항

a.     비밀번호 설정시 한국인터넷진흥원 패스워드 선택 및 이용안내서 의 안전한 패스워드 생성 규칙을 적용

안전한 패스워드

-       두 종류 이상의 문자구성과 8자리 이상의 길이로 구성된 문자열

-       문자 종류는 알파벳 대소문자 특수문자 숫자 등 4가지

-       10자리 이상의 길이로 구성된 문자열

-       숫자로만 구성할 경우 취약할 수 있음

 

안전하지 않은 패스워드

-       특정 패턴을 갖는 패스워드

-       동일한 문자의 반복(예 : 123123), 키보드 상 연속한 위치에 존재하는 문자열(예:qwerty),수자가 제일 앞이나 뒤에 오는 구성 (예: 1security)

-       제3자가 알 수 있는 개인정보를 바탕으로 구성

-       가족,이름,생일,주소,휴대전화 번호를 포함하는 패스워드

-       이용자 ID를 이용

-       이용자 ID가 kisa일 경우 패스워드를kisa1등으로 설정

-       한글,영어 등 사전적 단어로 구성 (예 바다나라 , love12 등)

-       특정 인물이나 널리 알려진 단어를 포함하는 패스워드

-       사이트,기업명,연예인 이름등의 특정 명칭을 의미

-       숫자와 염누자를 비숫하 문자로 치환한 형태로 구성

-       영문자 O를 숫자 0으로 영문자 I를 숫자 1로 치환등

-       시스템에서 초기 설정되거나 예제로 제시된 패스워드

-       한글의 발음을 영문으로 영문단어의 발음을 한글로 변경한 형태의 패스워드

 

b.     네트워트로 비밀번호를 전송하는 경우 반드시 비밀번호를 암호화하거나 암호화된 통신 채널을 이용해야 한다.

웹브라우저와 같은 클라이언트와 웹서버 간의 통신 서버와 서버간의 통신 등 인터넷과 같은 공중망 환경에서는

패스워드와 같은 중요정보를 송 수신하는 경우 보호대책이 필요하다 이러한 보호대책으로 TLS,VPN 등과 같은 다양한 통신 암호기술을 적용할 수 있다

시스템관리자 및 보안관리자는 TLS를 적용하거나 관련 솔루션을 도입할 때 제품이 표준에 부합하는지 상호호환성을 보장하는지

검증된 제품인지 오픈소스를 이용하는지 안전한 암호 알고리즘을 적용하는지 등을 확인해야 한다.

- TLS 최신 버전(예 : TLS 1.2 및 TLS 1.3)만 지원하고 한국인테넷진흥원 암호 알고리즘 및 키 길이 이용안내서를 참고하여 안전한 암호 알고리즘 조합 적용

 

c.     비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록해야 한다

비밀번호는 복호화 되지 않는 일방향 해시 함수를 사용해서 암호화하여 저장해야 한다.

 

           일방향 해시 함수

           일방향 해시함수는 수학적인 연산으로 원본메세지를 변환하여 암호화된 메시지인 다이제스트를 생성한다

           원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 일방향성 이라고 한다

 

        일방향 해시 함수의 문제점

           일부에서는 SHA-256과 같은 해시 함수를 사용해 비밀번호를 암호화하여 저장하고 인증 요청시 저장된 값과 비교하는 것만으로

           충분한 암호화 메커니즘을 적용했다고 행각하지만, 해시 함수는 동일한 메시지는 동일한 다이제스트로 생성되는 구조이므로 무차별 대입으로

           원본 문자열의 인식 가능성의 문제가 존재하며, 해시함수의 빠른 처리 속도 덕분에 공격자도 매우 빠른 속도로 임의의 문자열을 가질 수 있다

           이러한 문제점을 해결하기 위해 솔트(salt)값을 추가하여 해시함수를 실행한다. 솔트(salt)는 일방향 해시 함수에서 다이제스트를 생성할 때

           추가되는 바이트 단위의 임의의 문자열이다. 예를 들어 비밀번호가 "!t0Et67d3" 이라면 여기에 랜덤하게 생성된 솔트인 “rG7f32‐1dYjfgfd‐9F3fgd‐l4fGdg‐f4Tmlf”를

           추가해 다이제스트를 생성하면 공격자가 "!t0Et67d3" 의 다이제스트를 알아내더라도 솔트 값이 추가된 다이제스트를 대상으로 비밀번호 일치

여부를 확인하는 것이 어렵게 된다.

솔트와 비밀번호의 다이제스트를 데이터베이스에 저장하고 사용자가 로그인할 때 입력한 비밀번호를 해시하여 일치 여부를 확인하므로 즉 모든 패스워드가

고유의 솔트를 갖고 솔트의 길이가 32바이트 이상이면 솔트값이 노출되지 않은 이상 다이제스트를 추측하기 어렵다

 

d.     비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

비밀번호 변경은 주기적인 변경과 분실 시 재설정으로 나누어 볼 수 있다.

./ 비밀번호 변경

   사용자 및 관리자는 안전한 비밀번호 관리를 주기적으로 비밀번호를 변경하여 비밀번호의 노출위협을 최소화하여야 한다.

사용자는 자신의 비밀번호가 제3자에게 노출되었을 경우 즉시 새로운 비밀번호로 변경해야 하며 비밀번호 변경 시 이전의 비밀번호와 연관성이 없어야 한다

        ./ 비밀번호 재설정

          비밀번호를 잊어버렸거나 부실하는 경우 비밀번호 재설정이 필요한다. 이 경우에 비밀번호 찾기 기능을 사용해야 한다면 이메일과 질의 답변으로 반드시 해당

          사용자에게만 비밀번호 정보를 전달해야 하며 올바른 비밀번호가 입력되기 전에는 이메일 등 개인정보를 수정할 수 없도록 해야 한다. 질의-답변 검증 시 일정

          횟수 이상 정답을 맞히지 못하면 비밀번호 찾기 기능을 사용하지 못하도록 설정해야 한다. 검증 후 기존의 비밀번호가 아닌 임시비밀번호를 발급하도록 설계해야

          하며 사용자는 임시 비밀번호를 발급받은 즉시 새로운 비밀번호로 재설정해야 한다.

 

e.     비밀번호 관리 규칙을 정의해서 적용해야 한다.

안전한 비밀번호 관리를 위해 다음과 같은 항목을 고려할 수 있다.

./ 변경주기

   비밀번호는 3개월(또는 6개월)마다 주기적으로 변경하도록 해야 한다.

./ 만료기간 설정

   일정기간 시스템 사용자에 대해서는 비밀번호 만료기간을 설정해야 한다.

   사용자 테이블에 개인정보 변경주기를 추가한 뒤 일단위로 해당 필드가 업데이트되도록 한다.

   비밀번호 기간이 만료되면 로그인 시 사용자에게 비밀번호 변경을 요청하고 비밀번호 변경 시

   비밀번호 변경주기를 초기화 하도록 시큐어코딩 규칙을 정의한다.

./ 성공한 로그인 시간관리

   마지막으로 성공한 로그인 시간 정보를 관리해야 한다. 사용자 테이블에 마지막으로 로그인한 시간정보를 저장하고

   사용자에게 알림으로써 계정도용 여부를 점검할 수 있도록 개발가이드 구현단계를 작성한다.

 

비밀번호 관리 주기

비밀번호 생성

  개인 비밀번호는 사용자가 직접 생성하고 그룹 비밀번호는 그룹의 장이 생성하여 구성원들에게 안전한 방법으로 전달한다.

비밀번호 사용

  비밀번호는 제 3자에게 노출되지 않도록 해야 하며, 자신의 비밀번호와 관련된 정보 및 힌트를 제공하지 않아야 한다.

  비밀번호 변경주기는 3개월(또는 6개월)이다. 시스템 및 소프트웨어의 초기 비밀번호는 설치 시 즉시 변경해야 한다.

비밀번호 폐기

  비밀번호는 사용용도가 끝나거나 사용주기가 지난 경우 폐기한다. 인증 비밀번호는 시스템 담당자가 사용자 계정의

  삭제와 함께 폐기하고 암호화 비밀번호는 사용자가 직접 폐기한다.

 

 

연관된 구현 단계 보안 약점 항목

  보안기능 하드코딩된 중요정보, 취약한 비밀번호 허용-       중요기능이나 리소스에 대해서는 인증 후 사용 정책이 적용되어야 한다

-       안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

-       중요기능에 대해 2단계(2 factor)인증을 고려해야 한다

 

취약전 개요

중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는

경우 중요 정보나 리소스가 노충될 수 있다.

 

설계 시 고려사항

a.     중요기능이나 리소스에 대해서는 인증 후 사용정책이 적용되어야 한다

분석 단계에 분류된 중요기능에 대해 인증 후 사용 정책이 반드시 적용될 수 있도록 한다

각각의 중요기능에서 인증을 요청하도록 구현하는 것은 쉽지 않다 시스템 설계 시 중요기능을

분류하고 식별된 중요기능에 대해 일괄적으로 인증을 요구하도록 시스템이 구성되도록 설계한다

이 경우 직접적으로 기능과 인증을 매핑시켜 처리하는 컴포넌트를 개발하거나 인증기능을

제공하는 프레임워크 또는 라이브러리를 활용하여 중앙집중식 인증이 적용되도록 설계한다

 

b.     안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

인증정보는 서버 측에 저장하여 인증이 필요한 기능이나 리소스에 접근을 시도할 때 서버에서 인증 여부를

확인할 수 있도록 해야한다

. 일회용 패스워드 사용시

일회용 패스워드를 적용하는 경우 타서비스나 시스템과의 연동이 보장되도록 설계해야 한다.

일회용 패스워드를 도입하는 경우 다음과 같은 규칙을 적용하여 설계한다.

  ./ 일회용 패스워드는 시각정보, 이벤트정보, 질의 응답 방식으로 취득한 정보를 이용해 생성할 수 있다

  ./ 시각정보 기반의 연계정보는 특정시간 동안만 유효하여야 하며, 이벤트/질의 응답 방식을 사용할 경우에는

     연계 정보를 추측할 수 없도록 보호방안을 제공할 수 있어야 한다.

  ./ 일회용 패스워드에는 시간적 제한을 설정해야 한다(금융영역에서는 30-60초)

  ./ 일회용 패스워드는 중복 및 유추가 불가능하도록 6자리 이상의 숫자 및 문자로 구성한다.

  ./ OTP 발생기와 인증서버에서 동일한 정보를 생성해야 한다

 

c.     중요기능에 대해 2단계(2 factor)인증을 고려해야 한다.

중요기능에 대해 멀티 디바이스(SMS,ARS 등)를 이용한 추가인증이나, 공인인증서, 바이오정보(지문, 홍채 등)를

이용한 전자서명 인증기술을 이용한 2단계 인증을 고려해야 한다.

2단계인증은 Type1(패스워드/PIN등 지식기반인증), Type2(토큰/스마트카드 등 소유기반 인증), Type3(지문/홍채 등

생체기반 인증)중 2개 이상의 인증기번을 사용하도록 설계한다.

 

 

연관된 구현단계 보안약점 항목

입력 데이터 검증 및 표현 : 서버사이드 요청 위조

보안 기능 : 적절한 인증 없는 중요기능 허용

           부적절한 인증서 유효성 검증

API오용  : DNS lookup에 의존한 보안 결정

 

인증 수행 제한

보안 대책 : 로그인 기능 구현 시, 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

             실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야 한다.

 

취약점 개요

로그인 시도에 대한 횟수를 검사하지 않으면 로그인 시도 횟수와 상관없이 지속적으로 로그인 시도가 이루어지는

패스워드 무차별 대입 공격이 시도되어 계정정보가 노출될 수 있다.

 

 

설계시 고려사항

a.     로그인 기능 구현 시 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

로그인 시도횔수를 3-5번 이내로 제한하고 이를 초과하여 로그인에 실패하는 경우 추가 입력값을 요구하거나

계정 잠금을 수행하도록 다음과 같은 메커니즘으로 설계한다.

. 사용자ID별,세션ID별 로그인 횟수를 추적하기 위해 사용자 DB테이블에 로그인 실패 횟수,

계정 잠금 여부, 마지막으로 성공 실패한 로그인 시간정보, 로그아웃 시간정보등을 저장할 수 있도록 설계하고

일정 횟수 이상 연속적으로 로그인 실패 시 사용자 ID와 패스워드 이외 추가적인 정보를 확인하도록한다.

 

계정정보 입력시 자동입력 방지문자와 같은 장치를 마련하도록 설계한다.

 

b.     실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야한다.

반복된 로그인 실패에 대한 로깅 정책을 설정하고 로그 기록으로 허용되지 않은 로그인 시도를 분석 할 수 있도록 설계한다.

 

연관된 구현단계 보안약점 항목

  보안 기능 : 반복된 인증시도 제한기능 부재

 

 

 

비밀번호 관리

보안대책 : 비밀번호 설정 시 한국인터넷진흥원 패스워드 선택 및 이용 안내서 의 패스워드 보안 지침을 적용한다.

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

            비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록 해야한다.

            비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

            비밀번호 관리 규칙을 정의해서 적용해야 한다.

 

취약점 개요

 

    취약한 비밀번호 사용

     회원가입 시 안전한 비밀번호 생성 규칙이 적용되지 않아서 취약한 비밀번호호 회원가입이 가능할 경우 무차별 대입 공격으로 패스워드가 누출될 수 있다

     

 

취약한 비밀번호 복구

비밀번호 복구 메커니즘(아이디/패스워드 찾기 등)이 취약한 경우 공격자가 불법적으로 다른 사용자의 비밀번호를 획득 변경 복구할 수 있다.

 

하드코드된 비밀번호

  프로그램 코드 내부에 비밀번호를 하드 코딩하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우

  관리자용 계정 정보가 노출될 수 있어 위험하다, 또한 코드 내부에 하드코드된 비밀번호가 인증실패를 야기하는 경우

  시스템 관리자가 그 실패의 원인을 파악하기 쉽지 않다

 

 

설계시 고려 사항

a.     비밀번호 설정시 한국인터넷진흥원 패스워드 선택 및 이용안내서 의 안전한 패스워드 생성 규칙을 적용

안전한 패스워드

-       두 종류 이상의 문자구성과 8자리 이상의 길이로 구성된 문자열

-       문자 종류는 알파벳 대소문자 특수문자 숫자 등 4가지

-       10자리 이상의 길이로 구성된 문자열

-       숫자로만 구성할 경우 취약할 수 있음

 

안전하지 않은 패스워드

-       특정 패턴을 갖는 패스워드

-       동일한 문자의 반복(예 : 123123), 키보드 상 연속한 위치에 존재하는 문자열(예:qwerty),수자가 제일 앞이나 뒤에 오는 구성 (예: 1security)

-       제3자가 알 수 있는 개인정보를 바탕으로 구성

-       가족,이름,생일,주소,휴대전화 번호를 포함하는 패스워드

-       이용자 ID를 이용

-       이용자 ID가 kisa일 경우 패스워드를kisa1등으로 설정

-       한글,영어 등 사전적 단어로 구성 (예 바다나라 , love12 등)

-       특정 인물이나 널리 알려진 단어를 포함하는 패스워드

-       사이트,기업명,연예인 이름등의 특정 명칭을 의미

-       숫자와 염누자를 비숫하 문자로 치환한 형태로 구성

-       영문자 O를 숫자 0으로 영문자 I를 숫자 1로 치환등

-       시스템에서 초기 설정되거나 예제로 제시된 패스워드

-       한글의 발음을 영문으로 영문단어의 발음을 한글로 변경한 형태의 패스워드

 

b.     네트워트로 비밀번호를 전송하는 경우 반드시 비밀번호를 암호화하거나 암호화된 통신 채널을 이용해야 한다.

웹브라우저와 같은 클라이언트와 웹서버 간의 통신 서버와 서버간의 통신 등 인터넷과 같은 공중망 환경에서는

패스워드와 같은 중요정보를 송 수신하는 경우 보호대책이 필요하다 이러한 보호대책으로 TLS,VPN 등과 같은 다양한 통신 암호기술을 적용할 수 있다

시스템관리자 및 보안관리자는 TLS를 적용하거나 관련 솔루션을 도입할 때 제품이 표준에 부합하는지 상호호환성을 보장하는지

검증된 제품인지 오픈소스를 이용하는지 안전한 암호 알고리즘을 적용하는지 등을 확인해야 한다.

- TLS 최신 버전(예 : TLS 1.2 및 TLS 1.3)만 지원하고 한국인테넷진흥원 암호 알고리즘 및 키 길이 이용안내서를 참고하여 안전한 암호 알고리즘 조합 적용

 

c.     비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록해야 한다

비밀번호는 복호화 되지 않는 일방향 해시 함수를 사용해서 암호화하여 저장해야 한다.

 

           일방향 해시 함수

           일방향 해시함수는 수학적인 연산으로 원본메세지를 변환하여 암호화된 메시지인 다이제스트를 생성한다

           원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 일방향성 이라고 한다

 

        일방향 해시 함수의 문제점

           일부에서는 SHA-256과 같은 해시 함수를 사용해 비밀번호를 암호화하여 저장하고 인증 요청시 저장된 값과 비교하는 것만으로

           충분한 암호화 메커니즘을 적용했다고 행각하지만, 해시 함수는 동일한 메시지는 동일한 다이제스트로 생성되는 구조이므로 무차별 대입으로

           원본 문자열의 인식 가능성의 문제가 존재하며, 해시함수의 빠른 처리 속도 덕분에 공격자도 매우 빠른 속도로 임의의 문자열을 가질 수 있다

           이러한 문제점을 해결하기 위해 솔트(salt)값을 추가하여 해시함수를 실행한다. 솔트(salt)는 일방향 해시 함수에서 다이제스트를 생성할 때

           추가되는 바이트 단위의 임의의 문자열이다. 예를 들어 비밀번호가 "!t0Et67d3" 이라면 여기에 랜덤하게 생성된 솔트인 “rG7f32‐1dYjfgfd‐9F3fgd‐l4fGdg‐f4Tmlf”를

           추가해 다이제스트를 생성하면 공격자가 "!t0Et67d3" 의 다이제스트를 알아내더라도 솔트 값이 추가된 다이제스트를 대상으로 비밀번호 일치

여부를 확인하는 것이 어렵게 된다.

솔트와 비밀번호의 다이제스트를 데이터베이스에 저장하고 사용자가 로그인할 때 입력한 비밀번호를 해시하여 일치 여부를 확인하므로 즉 모든 패스워드가

고유의 솔트를 갖고 솔트의 길이가 32바이트 이상이면 솔트값이 노출되지 않은 이상 다이제스트를 추측하기 어렵다

 

d.     비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

비밀번호 변경은 주기적인 변경과 분실 시 재설정으로 나누어 볼 수 있다.

./ 비밀번호 변경

   사용자 및 관리자는 안전한 비밀번호 관리를 주기적으로 비밀번호를 변경하여 비밀번호의 노출위협을 최소화하여야 한다.

사용자는 자신의 비밀번호가 제3자에게 노출되었을 경우 즉시 새로운 비밀번호로 변경해야 하며 비밀번호 변경 시 이전의 비밀번호와 연관성이 없어야 한다

        ./ 비밀번호 재설정

          비밀번호를 잊어버렸거나 부실하는 경우 비밀번호 재설정이 필요한다. 이 경우에 비밀번호 찾기 기능을 사용해야 한다면 이메일과 질의 답변으로 반드시 해당

          사용자에게만 비밀번호 정보를 전달해야 하며 올바른 비밀번호가 입력되기 전에는 이메일 등 개인정보를 수정할 수 없도록 해야 한다. 질의-답변 검증 시 일정

          횟수 이상 정답을 맞히지 못하면 비밀번호 찾기 기능을 사용하지 못하도록 설정해야 한다. 검증 후 기존의 비밀번호가 아닌 임시비밀번호를 발급하도록 설계해야

          하며 사용자는 임시 비밀번호를 발급받은 즉시 새로운 비밀번호로 재설정해야 한다.

 

e.     비밀번호 관리 규칙을 정의해서 적용해야 한다.

안전한 비밀번호 관리를 위해 다음과 같은 항목을 고려할 수 있다.

./ 변경주기

   비밀번호는 3개월(또는 6개월)마다 주기적으로 변경하도록 해야 한다.

./ 만료기간 설정

   일정기간 시스템 사용자에 대해서는 비밀번호 만료기간을 설정해야 한다.

   사용자 테이블에 개인정보 변경주기를 추가한 뒤 일단위로 해당 필드가 업데이트되도록 한다.

   비밀번호 기간이 만료되면 로그인 시 사용자에게 비밀번호 변경을 요청하고 비밀번호 변경 시

   비밀번호 변경주기를 초기화 하도록 시큐어코딩 규칙을 정의한다.

./ 성공한 로그인 시간관리

   마지막으로 성공한 로그인 시간 정보를 관리해야 한다. 사용자 테이블에 마지막으로 로그인한 시간정보를 저장하고

   사용자에게 알림으로써 계정도용 여부를 점검할 수 있도록 개발가이드 구현단계를 작성한다.

 

비밀번호 관리 주기

비밀번호 생성

  개인 비밀번호는 사용자가 직접 생성하고 그룹 비밀번호는 그룹의 장이 생성하여 구성원들에게 안전한 방법으로 전달한다.

비밀번호 사용

  비밀번호는 제 3자에게 노출되지 않도록 해야 하며, 자신의 비밀번호와 관련된 정보 및 힌트를 제공하지 않아야 한다.

  비밀번호 변경주기는 3개월(또는 6개월)이다. 시스템 및 소프트웨어의 초기 비밀번호는 설치 시 즉시 변경해야 한다.

비밀번호 폐기

  비밀번호는 사용용도가 끝나거나 사용주기가 지난 경우 폐기한다. 인증 비밀번호는 시스템 담당자가 사용자 계정의

  삭제와 함께 폐기하고 암호화 비밀번호는 사용자가 직접 폐기한다.

 

 

연관된 구현 단계 보안 약점 항목

  보안기능 하드코딩된 중요정보, 취약한 비밀번호 허용-       안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

-       중요기능에 대해 2단계(2 factor)인증을 고려해야 한다

 

취약전 개요

중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는

경우 중요 정보나 리소스가 노충될 수 있다.

 

설계 시 고려사항

a.     중요기능이나 리소스에 대해서는 인증 후 사용정책이 적용되어야 한다

분석 단계에 분류된 중요기능에 대해 인증 후 사용 정책이 반드시 적용될 수 있도록 한다

각각의 중요기능에서 인증을 요청하도록 구현하는 것은 쉽지 않다 시스템 설계 시 중요기능을

분류하고 식별된 중요기능에 대해 일괄적으로 인증을 요구하도록 시스템이 구성되도록 설계한다

이 경우 직접적으로 기능과 인증을 매핑시켜 처리하는 컴포넌트를 개발하거나 인증기능을

제공하는 프레임워크 또는 라이브러리를 활용하여 중앙집중식 인증이 적용되도록 설계한다

 

b.     안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

인증정보는 서버 측에 저장하여 인증이 필요한 기능이나 리소스에 접근을 시도할 때 서버에서 인증 여부를

확인할 수 있도록 해야한다

. 일회용 패스워드 사용시

일회용 패스워드를 적용하는 경우 타서비스나 시스템과의 연동이 보장되도록 설계해야 한다.

일회용 패스워드를 도입하는 경우 다음과 같은 규칙을 적용하여 설계한다.

  ./ 일회용 패스워드는 시각정보, 이벤트정보, 질의 응답 방식으로 취득한 정보를 이용해 생성할 수 있다

  ./ 시각정보 기반의 연계정보는 특정시간 동안만 유효하여야 하며, 이벤트/질의 응답 방식을 사용할 경우에는

     연계 정보를 추측할 수 없도록 보호방안을 제공할 수 있어야 한다.

  ./ 일회용 패스워드에는 시간적 제한을 설정해야 한다(금융영역에서는 30-60초)

  ./ 일회용 패스워드는 중복 및 유추가 불가능하도록 6자리 이상의 숫자 및 문자로 구성한다.

  ./ OTP 발생기와 인증서버에서 동일한 정보를 생성해야 한다

 

c.     중요기능에 대해 2단계(2 factor)인증을 고려해야 한다.

중요기능에 대해 멀티 디바이스(SMS,ARS 등)를 이용한 추가인증이나, 공인인증서, 바이오정보(지문, 홍채 등)를

이용한 전자서명 인증기술을 이용한 2단계 인증을 고려해야 한다.

2단계인증은 Type1(패스워드/PIN등 지식기반인증), Type2(토큰/스마트카드 등 소유기반 인증), Type3(지문/홍채 등

생체기반 인증)중 2개 이상의 인증기번을 사용하도록 설계한다.

 

 

연관된 구현단계 보안약점 항목

입력 데이터 검증 및 표현 : 서버사이드 요청 위조

보안 기능 : 적절한 인증 없는 중요기능 허용

           부적절한 인증서 유효성 검증

API오용  : DNS lookup에 의존한 보안 결정

 

인증 수행 제한

보안 대책 : 로그인 기능 구현 시, 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

             실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야 한다.

 

취약점 개요

로그인 시도에 대한 횟수를 검사하지 않으면 로그인 시도 횟수와 상관없이 지속적으로 로그인 시도가 이루어지는

패스워드 무차별 대입 공격이 시도되어 계정정보가 노출될 수 있다.

 

 

설계시 고려사항

a.     로그인 기능 구현 시 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

로그인 시도횔수를 3-5번 이내로 제한하고 이를 초과하여 로그인에 실패하는 경우 추가 입력값을 요구하거나

계정 잠금을 수행하도록 다음과 같은 메커니즘으로 설계한다.

. 사용자ID별,세션ID별 로그인 횟수를 추적하기 위해 사용자 DB테이블에 로그인 실패 횟수,

계정 잠금 여부, 마지막으로 성공 실패한 로그인 시간정보, 로그아웃 시간정보등을 저장할 수 있도록 설계하고

일정 횟수 이상 연속적으로 로그인 실패 시 사용자 ID와 패스워드 이외 추가적인 정보를 확인하도록한다.

 

계정정보 입력시 자동입력 방지문자와 같은 장치를 마련하도록 설계한다.

 

b.     실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야한다.

반복된 로그인 실패에 대한 로깅 정책을 설정하고 로그 기록으로 허용되지 않은 로그인 시도를 분석 할 수 있도록 설계한다.

 

연관된 구현단계 보안약점 항목

  보안 기능 : 반복된 인증시도 제한기능 부재

 

 

 

비밀번호 관리

보안대책 : 비밀번호 설정 시 한국인터넷진흥원 패스워드 선택 및 이용 안내서 의 패스워드 보안 지침을 적용한다.

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

            비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록 해야한다.

            비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

            비밀번호 관리 규칙을 정의해서 적용해야 한다.

 

취약점 개요

 

    취약한 비밀번호 사용

     회원가입 시 안전한 비밀번호 생성 규칙이 적용되지 않아서 취약한 비밀번호호 회원가입이 가능할 경우 무차별 대입 공격으로 패스워드가 누출될 수 있다

     

 

취약한 비밀번호 복구

비밀번호 복구 메커니즘(아이디/패스워드 찾기 등)이 취약한 경우 공격자가 불법적으로 다른 사용자의 비밀번호를 획득 변경 복구할 수 있다.

 

하드코드된 비밀번호

  프로그램 코드 내부에 비밀번호를 하드 코딩하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우

  관리자용 계정 정보가 노출될 수 있어 위험하다, 또한 코드 내부에 하드코드된 비밀번호가 인증실패를 야기하는 경우

  시스템 관리자가 그 실패의 원인을 파악하기 쉽지 않다

 

 

설계시 고려 사항

a.     비밀번호 설정시 한국인터넷진흥원 패스워드 선택 및 이용안내서 의 안전한 패스워드 생성 규칙을 적용

안전한 패스워드

-       두 종류 이상의 문자구성과 8자리 이상의 길이로 구성된 문자열

-       문자 종류는 알파벳 대소문자 특수문자 숫자 등 4가지

-       10자리 이상의 길이로 구성된 문자열

-       숫자로만 구성할 경우 취약할 수 있음

 

안전하지 않은 패스워드

-       특정 패턴을 갖는 패스워드

-       동일한 문자의 반복(예 : 123123), 키보드 상 연속한 위치에 존재하는 문자열(예:qwerty),수자가 제일 앞이나 뒤에 오는 구성 (예: 1security)

-       제3자가 알 수 있는 개인정보를 바탕으로 구성

-       가족,이름,생일,주소,휴대전화 번호를 포함하는 패스워드

-       이용자 ID를 이용

-       이용자 ID가 kisa일 경우 패스워드를kisa1등으로 설정

-       한글,영어 등 사전적 단어로 구성 (예 바다나라 , love12 등)

-       특정 인물이나 널리 알려진 단어를 포함하는 패스워드

-       사이트,기업명,연예인 이름등의 특정 명칭을 의미

-       숫자와 염누자를 비숫하 문자로 치환한 형태로 구성

-       영문자 O를 숫자 0으로 영문자 I를 숫자 1로 치환등

-       시스템에서 초기 설정되거나 예제로 제시된 패스워드

-       한글의 발음을 영문으로 영문단어의 발음을 한글로 변경한 형태의 패스워드

 

b.     네트워트로 비밀번호를 전송하는 경우 반드시 비밀번호를 암호화하거나 암호화된 통신 채널을 이용해야 한다.

웹브라우저와 같은 클라이언트와 웹서버 간의 통신 서버와 서버간의 통신 등 인터넷과 같은 공중망 환경에서는

패스워드와 같은 중요정보를 송 수신하는 경우 보호대책이 필요하다 이러한 보호대책으로 TLS,VPN 등과 같은 다양한 통신 암호기술을 적용할 수 있다

시스템관리자 및 보안관리자는 TLS를 적용하거나 관련 솔루션을 도입할 때 제품이 표준에 부합하는지 상호호환성을 보장하는지

검증된 제품인지 오픈소스를 이용하는지 안전한 암호 알고리즘을 적용하는지 등을 확인해야 한다.

- TLS 최신 버전(예 : TLS 1.2 및 TLS 1.3)만 지원하고 한국인테넷진흥원 암호 알고리즘 및 키 길이 이용안내서를 참고하여 안전한 암호 알고리즘 조합 적용

 

c.     비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록해야 한다

비밀번호는 복호화 되지 않는 일방향 해시 함수를 사용해서 암호화하여 저장해야 한다.

 

           일방향 해시 함수

           일방향 해시함수는 수학적인 연산으로 원본메세지를 변환하여 암호화된 메시지인 다이제스트를 생성한다

           원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 일방향성 이라고 한다

 

        일방향 해시 함수의 문제점

           일부에서는 SHA-256과 같은 해시 함수를 사용해 비밀번호를 암호화하여 저장하고 인증 요청시 저장된 값과 비교하는 것만으로

           충분한 암호화 메커니즘을 적용했다고 행각하지만, 해시 함수는 동일한 메시지는 동일한 다이제스트로 생성되는 구조이므로 무차별 대입으로

           원본 문자열의 인식 가능성의 문제가 존재하며, 해시함수의 빠른 처리 속도 덕분에 공격자도 매우 빠른 속도로 임의의 문자열을 가질 수 있다

           이러한 문제점을 해결하기 위해 솔트(salt)값을 추가하여 해시함수를 실행한다. 솔트(salt)는 일방향 해시 함수에서 다이제스트를 생성할 때

           추가되는 바이트 단위의 임의의 문자열이다. 예를 들어 비밀번호가 "!t0Et67d3" 이라면 여기에 랜덤하게 생성된 솔트인 “rG7f32‐1dYjfgfd‐9F3fgd‐l4fGdg‐f4Tmlf”를

           추가해 다이제스트를 생성하면 공격자가 "!t0Et67d3" 의 다이제스트를 알아내더라도 솔트 값이 추가된 다이제스트를 대상으로 비밀번호 일치

여부를 확인하는 것이 어렵게 된다.

솔트와 비밀번호의 다이제스트를 데이터베이스에 저장하고 사용자가 로그인할 때 입력한 비밀번호를 해시하여 일치 여부를 확인하므로 즉 모든 패스워드가

고유의 솔트를 갖고 솔트의 길이가 32바이트 이상이면 솔트값이 노출되지 않은 이상 다이제스트를 추측하기 어렵다

 

d.     비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

비밀번호 변경은 주기적인 변경과 분실 시 재설정으로 나누어 볼 수 있다.

./ 비밀번호 변경

   사용자 및 관리자는 안전한 비밀번호 관리를 주기적으로 비밀번호를 변경하여 비밀번호의 노출위협을 최소화하여야 한다.

사용자는 자신의 비밀번호가 제3자에게 노출되었을 경우 즉시 새로운 비밀번호로 변경해야 하며 비밀번호 변경 시 이전의 비밀번호와 연관성이 없어야 한다

        ./ 비밀번호 재설정

          비밀번호를 잊어버렸거나 부실하는 경우 비밀번호 재설정이 필요한다. 이 경우에 비밀번호 찾기 기능을 사용해야 한다면 이메일과 질의 답변으로 반드시 해당

          사용자에게만 비밀번호 정보를 전달해야 하며 올바른 비밀번호가 입력되기 전에는 이메일 등 개인정보를 수정할 수 없도록 해야 한다. 질의-답변 검증 시 일정

          횟수 이상 정답을 맞히지 못하면 비밀번호 찾기 기능을 사용하지 못하도록 설정해야 한다. 검증 후 기존의 비밀번호가 아닌 임시비밀번호를 발급하도록 설계해야

          하며 사용자는 임시 비밀번호를 발급받은 즉시 새로운 비밀번호로 재설정해야 한다.

 

e.     비밀번호 관리 규칙을 정의해서 적용해야 한다.

안전한 비밀번호 관리를 위해 다음과 같은 항목을 고려할 수 있다.

./ 변경주기

   비밀번호는 3개월(또는 6개월)마다 주기적으로 변경하도록 해야 한다.

./ 만료기간 설정

   일정기간 시스템 사용자에 대해서는 비밀번호 만료기간을 설정해야 한다.

   사용자 테이블에 개인정보 변경주기를 추가한 뒤 일단위로 해당 필드가 업데이트되도록 한다.

   비밀번호 기간이 만료되면 로그인 시 사용자에게 비밀번호 변경을 요청하고 비밀번호 변경 시

   비밀번호 변경주기를 초기화 하도록 시큐어코딩 규칙을 정의한다.

./ 성공한 로그인 시간관리

   마지막으로 성공한 로그인 시간 정보를 관리해야 한다. 사용자 테이블에 마지막으로 로그인한 시간정보를 저장하고

   사용자에게 알림으로써 계정도용 여부를 점검할 수 있도록 개발가이드 구현단계를 작성한다.

 

비밀번호 관리 주기

비밀번호 생성

  개인 비밀번호는 사용자가 직접 생성하고 그룹 비밀번호는 그룹의 장이 생성하여 구성원들에게 안전한 방법으로 전달한다.

비밀번호 사용

  비밀번호는 제 3자에게 노출되지 않도록 해야 하며, 자신의 비밀번호와 관련된 정보 및 힌트를 제공하지 않아야 한다.

  비밀번호 변경주기는 3개월(또는 6개월)이다. 시스템 및 소프트웨어의 초기 비밀번호는 설치 시 즉시 변경해야 한다.

비밀번호 폐기

  비밀번호는 사용용도가 끝나거나 사용주기가 지난 경우 폐기한다. 인증 비밀번호는 시스템 담당자가 사용자 계정의

  삭제와 함께 폐기하고 암호화 비밀번호는 사용자가 직접 폐기한다.

 

 

연관된 구현 단계 보안 약점 항목

  보안기능 하드코딩된 중요정보, 취약한 비밀번호 허용-       중요기능에 대해 2단계(2 factor)인증을 고려해야 한다

 

취약전 개요

중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는

경우 중요 정보나 리소스가 노충될 수 있다.

 

설계 시 고려사항

a.     중요기능이나 리소스에 대해서는 인증 후 사용정책이 적용되어야 한다

분석 단계에 분류된 중요기능에 대해 인증 후 사용 정책이 반드시 적용될 수 있도록 한다

각각의 중요기능에서 인증을 요청하도록 구현하는 것은 쉽지 않다 시스템 설계 시 중요기능을

분류하고 식별된 중요기능에 대해 일괄적으로 인증을 요구하도록 시스템이 구성되도록 설계한다

이 경우 직접적으로 기능과 인증을 매핑시켜 처리하는 컴포넌트를 개발하거나 인증기능을

제공하는 프레임워크 또는 라이브러리를 활용하여 중앙집중식 인증이 적용되도록 설계한다

 

b.     안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다.

인증정보는 서버 측에 저장하여 인증이 필요한 기능이나 리소스에 접근을 시도할 때 서버에서 인증 여부를

확인할 수 있도록 해야한다

. 일회용 패스워드 사용시

일회용 패스워드를 적용하는 경우 타서비스나 시스템과의 연동이 보장되도록 설계해야 한다.

일회용 패스워드를 도입하는 경우 다음과 같은 규칙을 적용하여 설계한다.

  ./ 일회용 패스워드는 시각정보, 이벤트정보, 질의 응답 방식으로 취득한 정보를 이용해 생성할 수 있다

  ./ 시각정보 기반의 연계정보는 특정시간 동안만 유효하여야 하며, 이벤트/질의 응답 방식을 사용할 경우에는

     연계 정보를 추측할 수 없도록 보호방안을 제공할 수 있어야 한다.

  ./ 일회용 패스워드에는 시간적 제한을 설정해야 한다(금융영역에서는 30-60초)

  ./ 일회용 패스워드는 중복 및 유추가 불가능하도록 6자리 이상의 숫자 및 문자로 구성한다.

  ./ OTP 발생기와 인증서버에서 동일한 정보를 생성해야 한다

 

c.     중요기능에 대해 2단계(2 factor)인증을 고려해야 한다.

중요기능에 대해 멀티 디바이스(SMS,ARS 등)를 이용한 추가인증이나, 공인인증서, 바이오정보(지문, 홍채 등)를

이용한 전자서명 인증기술을 이용한 2단계 인증을 고려해야 한다.

2단계인증은 Type1(패스워드/PIN등 지식기반인증), Type2(토큰/스마트카드 등 소유기반 인증), Type3(지문/홍채 등

생체기반 인증)중 2개 이상의 인증기번을 사용하도록 설계한다.

 

 

연관된 구현단계 보안약점 항목

입력 데이터 검증 및 표현 : 서버사이드 요청 위조

보안 기능 : 적절한 인증 없는 중요기능 허용

           부적절한 인증서 유효성 검증

API오용  : DNS lookup에 의존한 보안 결정

 

인증 수행 제한

보안 대책 : 로그인 기능 구현 시, 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

             실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야 한다.

 

취약점 개요

로그인 시도에 대한 횟수를 검사하지 않으면 로그인 시도 횟수와 상관없이 지속적으로 로그인 시도가 이루어지는

패스워드 무차별 대입 공격이 시도되어 계정정보가 노출될 수 있다.

 

 

설계시 고려사항

a.     로그인 기능 구현 시 인증시도 횟수를 제한하고 초과된 인증시도에 대해 인증제한 정책을 적용해야 한다.

로그인 시도횔수를 3-5번 이내로 제한하고 이를 초과하여 로그인에 실패하는 경우 추가 입력값을 요구하거나

계정 잠금을 수행하도록 다음과 같은 메커니즘으로 설계한다.

. 사용자ID별,세션ID별 로그인 횟수를 추적하기 위해 사용자 DB테이블에 로그인 실패 횟수,

계정 잠금 여부, 마지막으로 성공 실패한 로그인 시간정보, 로그아웃 시간정보등을 저장할 수 있도록 설계하고

일정 횟수 이상 연속적으로 로그인 실패 시 사용자 ID와 패스워드 이외 추가적인 정보를 확인하도록한다.

 

계정정보 입력시 자동입력 방지문자와 같은 장치를 마련하도록 설계한다.

 

b.     실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야한다.

반복된 로그인 실패에 대한 로깅 정책을 설정하고 로그 기록으로 허용되지 않은 로그인 시도를 분석 할 수 있도록 설계한다.

 

연관된 구현단계 보안약점 항목

  보안 기능 : 반복된 인증시도 제한기능 부재

 

 

 

비밀번호 관리

보안대책 : 비밀번호 설정 시 한국인터넷진흥원 패스워드 선택 및 이용 안내서 의 패스워드 보안 지침을 적용한다.

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

            비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록 해야한다.

            비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

            비밀번호 관리 규칙을 정의해서 적용해야 한다.

 

취약점 개요

 

    취약한 비밀번호 사용

     회원가입 시 안전한 비밀번호 생성 규칙이 적용되지 않아서 취약한 비밀번호호 회원가입이 가능할 경우 무차별 대입 공격으로 패스워드가 누출될 수 있다

     

 

취약한 비밀번호 복구

비밀번호 복구 메커니즘(아이디/패스워드 찾기 등)이 취약한 경우 공격자가 불법적으로 다른 사용자의 비밀번호를 획득 변경 복구할 수 있다.

 

하드코드된 비밀번호

  프로그램 코드 내부에 비밀번호를 하드 코딩하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우

  관리자용 계정 정보가 노출될 수 있어 위험하다, 또한 코드 내부에 하드코드된 비밀번호가 인증실패를 야기하는 경우

  시스템 관리자가 그 실패의 원인을 파악하기 쉽지 않다

 

 

설계시 고려 사항

a.     비밀번호 설정시 한국인터넷진흥원 패스워드 선택 및 이용안내서 의 안전한 패스워드 생성 규칙을 적용

안전한 패스워드

-       두 종류 이상의 문자구성과 8자리 이상의 길이로 구성된 문자열

-       문자 종류는 알파벳 대소문자 특수문자 숫자 등 4가지

-       10자리 이상의 길이로 구성된 문자열

-       숫자로만 구성할 경우 취약할 수 있음

 

안전하지 않은 패스워드

-       특정 패턴을 갖는 패스워드

-       동일한 문자의 반복(예 : 123123), 키보드 상 연속한 위치에 존재하는 문자열(예:qwerty),수자가 제일 앞이나 뒤에 오는 구성 (예: 1security)

-       제3자가 알 수 있는 개인정보를 바탕으로 구성

-       가족,이름,생일,주소,휴대전화 번호를 포함하는 패스워드

-       이용자 ID를 이용

-       이용자 ID가 kisa일 경우 패스워드를kisa1등으로 설정

-       한글,영어 등 사전적 단어로 구성 (예 바다나라 , love12 등)

-       특정 인물이나 널리 알려진 단어를 포함하는 패스워드

-       사이트,기업명,연예인 이름등의 특정 명칭을 의미

-       숫자와 염누자를 비숫하 문자로 치환한 형태로 구성

-       영문자 O를 숫자 0으로 영문자 I를 숫자 1로 치환등

-       시스템에서 초기 설정되거나 예제로 제시된 패스워드

-       한글의 발음을 영문으로 영문단어의 발음을 한글로 변경한 형태의 패스워드

 

b.     네트워트로 비밀번호를 전송하는 경우 반드시 비밀번호를 암호화하거나 암호화된 통신 채널을 이용해야 한다.

웹브라우저와 같은 클라이언트와 웹서버 간의 통신 서버와 서버간의 통신 등 인터넷과 같은 공중망 환경에서는

패스워드와 같은 중요정보를 송 수신하는 경우 보호대책이 필요하다 이러한 보호대책으로 TLS,VPN 등과 같은 다양한 통신 암호기술을 적용할 수 있다

시스템관리자 및 보안관리자는 TLS를 적용하거나 관련 솔루션을 도입할 때 제품이 표준에 부합하는지 상호호환성을 보장하는지

검증된 제품인지 오픈소스를 이용하는지 안전한 암호 알고리즘을 적용하는지 등을 확인해야 한다.

- TLS 최신 버전(예 : TLS 1.2 및 TLS 1.3)만 지원하고 한국인테넷진흥원 암호 알고리즘 및 키 길이 이용안내서를 참고하여 안전한 암호 알고리즘 조합 적용

 

c.     비밀번호 저장 시 솔트가 적용된 안전한 해시함수를 사용해야 하며 비밀번호에 대한 해시는 서버에서 실행되도록해야 한다

비밀번호는 복호화 되지 않는 일방향 해시 함수를 사용해서 암호화하여 저장해야 한다.

 

           일방향 해시 함수

           일방향 해시함수는 수학적인 연산으로 원본메세지를 변환하여 암호화된 메시지인 다이제스트를 생성한다

           원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 일방향성 이라고 한다

 

        일방향 해시 함수의 문제점

           일부에서는 SHA-256과 같은 해시 함수를 사용해 비밀번호를 암호화하여 저장하고 인증 요청시 저장된 값과 비교하는 것만으로

           충분한 암호화 메커니즘을 적용했다고 행각하지만, 해시 함수는 동일한 메시지는 동일한 다이제스트로 생성되는 구조이므로 무차별 대입으로

           원본 문자열의 인식 가능성의 문제가 존재하며, 해시함수의 빠른 처리 속도 덕분에 공격자도 매우 빠른 속도로 임의의 문자열을 가질 수 있다

           이러한 문제점을 해결하기 위해 솔트(salt)값을 추가하여 해시함수를 실행한다. 솔트(salt)는 일방향 해시 함수에서 다이제스트를 생성할 때

           추가되는 바이트 단위의 임의의 문자열이다. 예를 들어 비밀번호가 "!t0Et67d3" 이라면 여기에 랜덤하게 생성된 솔트인 “rG7f32‐1dYjfgfd‐9F3fgd‐l4fGdg‐f4Tmlf”를

           추가해 다이제스트를 생성하면 공격자가 "!t0Et67d3" 의 다이제스트를 알아내더라도 솔트 값이 추가된 다이제스트를 대상으로 비밀번호 일치

여부를 확인하는 것이 어렵게 된다.

솔트와 비밀번호의 다이제스트를 데이터베이스에 저장하고 사용자가 로그인할 때 입력한 비밀번호를 해시하여 일치 여부를 확인하므로 즉 모든 패스워드가

고유의 솔트를 갖고 솔트의 길이가 32바이트 이상이면 솔트값이 노출되지 않은 이상 다이제스트를 추측하기 어렵다

 

d.     비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다.

비밀번호 변경은 주기적인 변경과 분실 시 재설정으로 나누어 볼 수 있다.

./ 비밀번호 변경

   사용자 및 관리자는 안전한 비밀번호 관리를 주기적으로 비밀번호를 변경하여 비밀번호의 노출위협을 최소화하여야 한다.

사용자는 자신의 비밀번호가 제3자에게 노출되었을 경우 즉시 새로운 비밀번호로 변경해야 하며 비밀번호 변경 시 이전의 비밀번호와 연관성이 없어야 한다

        ./ 비밀번호 재설정

          비밀번호를 잊어버렸거나 부실하는 경우 비밀번호 재설정이 필요한다. 이 경우에 비밀번호 찾기 기능을 사용해야 한다면 이메일과 질의 답변으로 반드시 해당

          사용자에게만 비밀번호 정보를 전달해야 하며 올바른 비밀번호가 입력되기 전에는 이메일 등 개인정보를 수정할 수 없도록 해야 한다. 질의-답변 검증 시 일정

          횟수 이상 정답을 맞히지 못하면 비밀번호 찾기 기능을 사용하지 못하도록 설정해야 한다. 검증 후 기존의 비밀번호가 아닌 임시비밀번호를 발급하도록 설계해야

          하며 사용자는 임시 비밀번호를 발급받은 즉시 새로운 비밀번호로 재설정해야 한다.

 

e.     비밀번호 관리 규칙을 정의해서 적용해야 한다.

안전한 비밀번호 관리를 위해 다음과 같은 항목을 고려할 수 있다.

./ 변경주기

   비밀번호는 3개월(또는 6개월)마다 주기적으로 변경하도록 해야 한다.

./ 만료기간 설정

   일정기간 시스템 사용자에 대해서는 비밀번호 만료기간을 설정해야 한다.

   사용자 테이블에 개인정보 변경주기를 추가한 뒤 일단위로 해당 필드가 업데이트되도록 한다.

   비밀번호 기간이 만료되면 로그인 시 사용자에게 비밀번호 변경을 요청하고 비밀번호 변경 시

   비밀번호 변경주기를 초기화 하도록 시큐어코딩 규칙을 정의한다.

./ 성공한 로그인 시간관리

   마지막으로 성공한 로그인 시간 정보를 관리해야 한다. 사용자 테이블에 마지막으로 로그인한 시간정보를 저장하고

   사용자에게 알림으로써 계정도용 여부를 점검할 수 있도록 개발가이드 구현단계를 작성한다.

 

비밀번호 관리 주기

비밀번호 생성

  개인 비밀번호는 사용자가 직접 생성하고 그룹 비밀번호는 그룹의 장이 생성하여 구성원들에게 안전한 방법으로 전달한다.

비밀번호 사용

  비밀번호는 제 3자에게 노출되지 않도록 해야 하며, 자신의 비밀번호와 관련된 정보 및 힌트를 제공하지 않아야 한다.

  비밀번호 변경주기는 3개월(또는 6개월)이다. 시스템 및 소프트웨어의 초기 비밀번호는 설치 시 즉시 변경해야 한다.

비밀번호 폐기

  비밀번호는 사용용도가 끝나거나 사용주기가 지난 경우 폐기한다. 인증 비밀번호는 시스템 담당자가 사용자 계정의

  삭제와 함께 폐기하고 암호화 비밀번호는 사용자가 직접 폐기한다.

 

 

연관된 구현 단계 보안 약점 항목

  보안기능 하드코딩된 중요정보, 취약한 비밀번호 허용