Notice
Recent Posts
Recent Comments
Link
IgnatiusHeo
구현단계 보안약점 제거 기준-취약한 비밀번호 허용 본문
작성일: 230704
※ 본 게시글은 학습 목적으로 행정안전부·KISA의 소프트웨어 보안약점 진단 가이드, 소프트웨어 개발보안 가이드를 참고하여 작성하였습니다.
정리 내용: 소프트웨어 보안약점 진단 가이드(370~374p)
구분 | - 보안기능 |
설계단계 | - 비밀번호 관리 https://cryptocurrencyclub.tistory.com/102 |
개요 | 사용자에게 강한 비밀번호 조합규칙을 요구하지 않으면, 사용자 계정이 취약하게 된다. 안전한 비밀 번호를 생성하기 위해서는 한국인터넷진흥원 「암호이용안내서」의 비밀번호 설정규칙을 적용해야 한다. |
진단 세부사항 (설계단계) |
① 비밀번호 설정 시 KISA의 비밀번호 선택 및 이용 안내서의 비밀번호 생성규칙을 적용한다. 조합규칙, 길이 등 비밀번호가 안전하게 설정되도록 설계되어 있는지 확인한다. ㅇ 비밀번호 설정 규칙 정의 시 안전한 비밀번호 설정규칙이 설계에 적용되었는지 확인 - 길이: 조합규칙의 복잡도에 따라 최소 8자리 이상 - 조합규칙: 숫자, 영 대소문자, 특수문자 포함 - 제한문자열: 전화번호, 동일 문자열 반복 제한, 생년월일 등 ㅇ 비밀번호 설정규칙을 위배하는 입력값과 예상 결과를 포함하는 테스트 계획의 수립 여부 확인 ② 네트워크로 비밀번호를 전송하는 경우 반드시 비밀번호를 암호화하거나 암호화된 통신 채널을 이용해야 한다. 네트워크로 비밀번호 전송 시 암호화 또는 암호화 채널을 사용하도록 설계되어 있는지 확인한다. ㅇ 네트워크로 비밀번호가 전송되는 기능이 분류되어 있는지 확인 ㅇ 비밀번호를 암호화하여 전송하는 경우, 안전한 암호 알고리즘을 사용한 비밀번호 암호화 여부 확인 ㅇ 암호화된 통신채널을 사용하여 전송하는 경우 TLS/VPN 등 안전한 통신채널을 사용하도록 설계되었는지 확인 ㅇ 패킷스니핑 등으로 암호화 전송을 점검하는 테스트 계획의 수립 여부 확인 패킷까지 떠???? ③ 비밀번호 저장 시, 솔트가 적용된 안전한 해시함수를 사용해야 하며, 해시함수 실행은 서버에서 해야한다. 비밀번호 저장 시 해시함수를 사용하도록 설계하고, 사용할 해시함수와 솔트 값을 포함한 해시함수 사용 방법이 명시되어 있는지 확인한다. ㅇ 비밀번호를 암호화하기위해 SHA-2 계열(SHA224/256/384/512)의 해시함수 사용여부 확인 ㅇ 해시함수 사용 시 솔트값을 사용하도록 설계되어 있는지 확인 ㅇ 솔트값은 데이터 암·복호화에 사용되는 암호키가 저장되는 장소에 저장되도록 설계되어 있는지 확인 ㅇ 해시함수를 이용한 일방향 암호를 서버에서 수행하는 프로그램이 설계되어 있는지 확인 ㅇ 비밀번호 크랙도구를 이용하여 DB에 저장된 비밀번호의 안전을 점검하는 테스트 계획의 수립 여부 확인 ④ 비밀번호 재설정/변경 시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다. 비밀번호를 주기적으로 변경하고, 비밀번호 변경 및 비밀번호 분실로 인한 재설정 시 안전하게 변경절차가 이루어지도록 설계되어 있는지 확인한다. ㅇ 비밀번호 변경 시 기존 비밀번호를 확인하는 기능의 설계 여부 확인(예전 비번과 동일여부 확인 목적인듯?) ㅇ 안전한 비밀번호 설정규칙이 적용되도록 설계되어 있는지 확인 ㅇ 비밀번호 재설정 요청 시, 안전한 본인인증 절차를 거치도록 설계되어 있는지 확인(휴대전화인증, I-PIN, 공인인증서, 신용카드 등) ㅇ 본인인증 후 비밀번호 재설정 페이지 연결방식의 안전한 설계 여부 확인 ㅇ 권한이 있는 사용자만 비밀번호 변경이 가능한지 점검하는 테스트계획 수립 여부 확인 ㅇ 본인인증 절차를 우회하거나 비밀번호 재설정 경로로 직접 접근하여 비밀번호 재설정 가능 여부를 점검하는 테스트 계획 수립 여부 확인 ⑤ 비밀번호 관리 규칙을 정의해서 적용해야 한다. 비밀번호 변경주기, 만료기간 설정, 성공한 로그인 시간 관리를 포함하여 비밀번호 관리규칙이 설계되어 있는지 확인한다. ㅇ 비밀번호 만료기간이나 변경 주기에 대한 정책의 정의 여부 확인 ㅇ 비밀번호 만료기간이나 변경주기 정책을 관리할 수 있도록 DB 및 프로그램 기능의 설계 여부 확인(최종 변경일, 만료기간, 변경주기 등) |
보안대책 (구현단계) |
비밀번호 생성 시 강한 조건 검증을 수행한다. 비밀번호(비밀번호)는 숫자와 영문자, 특수문자 등을 혼합하여 사용하고, 주기적으로 변경하여 사용하도록 해야 한다. |
진단방법 (구현단계) |
비밀번호 생성 또는 변경 때 입력값을 다음과 같은 규칙으로 검사하는 모듈이 존재하는지 확인한다. 사용자 계정 등록 등 비밀번호를 요구하는 정보 입력에서 널(Null) 체크, 비밀 번호의 자릿수, 특수문자 포함 등 비밀번호 요구 조건이 없거나 약하면 취약하다고 진단한다. |
다. 코드예제
ㅇ 분석
1: String id = request.getParameter("id");
2: String pass = request.getParameter("pass");
3: UserVo userVO = new UserVo(id, pass);
4: ……
// 비밀번호의 자릿수, 특수문자 포함 여부 등 복잡도를 체크하지 않고 등록
5: String result = registerDAO.register(userVO);
ㅇ 내용
1. 비밀번호 규칙 검증 없이 등록
ㅇ 수정
1: String id = request.getParameter("id");
2: String pass = request.getParameter("pass");
//비밀번호에 자릿수, 특수문자 포함여부등의 복잡도를 체크하고 등록하게 한다.
3: Pattern pattern = Pattern.compile("((?=.*[a-zA-Z])(?=.*[0-9@#$%]). {9, })");
4: Matcher matcher = pattern.matcher(pass);
5: if (!matcher.matches()) {
6: return "비밀번호 조합규칙 오류";
7: }
8: UserVo userVO = new UserVo(id, pass);
9: ……
10:String result = registerDAO.register(userVO);
ㅇ 내용
1. 비밀번호 조합규칙 설정
ㅇ 분석
// 빈 비밀번호를 허용
1: NetworkCredential myCred = new NetworkCredential(UserName, "");
ㅇ 내용
1. 비밀번호가 왜 없어 ...?
ㅇ 수정
// 빈 비밀번호를 사용하지 않음
1: NetworkCredential secure_myCred = new NetworkCredential(UserName,
Password);
ㅇ 내용
1. 비밀번호 추가
ㅇ 분석
1: bool authentication(char* id, char* pwd)
2: {
3: MYSQL *connectInstance;
4: connectInstance = mysql_init(NULL);
//비밀번호 값에 대한 검증 없이 사용합니다.
5: mysql_real_connect(connectInstance, "192.168.100.211", id, pwd,
"database", 0, NULL, 0);
6: ...
ㅇ 내용
1. 비밀번호에 대한 검증 ㅇㄷ?
ㅇ 수정
1: bool authentication(char* id, char* pwd)
2: {
3: MYSQL *connectInstance;
4: connectInstance = mysql_init(NULL);
//비밀번호에 대한 적절한 검증을 수행해야 한다.
5: if(checkValidationId( id ) == true && checkValidationPwd( pwd ) ==
true )
6: {
7: mysql_real_connect(connectInstance, "192.168.100.211", id, pwd,
"database", 0, NULL, 0);
8: }
9: ...
10:}
ㅇ 내용
1. 비밀번호 검증 내용 추가
끝.
'자격 > SW보안약점진단원' 카테고리의 다른 글
구현단계 보안약점 제거 기준-부적절한 인증서 유효성 검증 (0) | 2023.07.04 |
---|---|
구현단계 보안약점 제거 기준-부적절한 전자서명 확인 (0) | 2023.07.04 |
구현단계 보안약점 제거 기준-적절하지 않은 난수 값 사용 (0) | 2023.07.04 |
구현단계 보안약점 제거 기준-충분하지 않은 키 길이 사용 (0) | 2023.07.04 |
구현단계 보안약점 제거 기준-하드코드된 중요정보 (0) | 2023.07.04 |