안녕하세요🙌! 개발자 갈레입니다!
여러분들은 비밀번호를 평문으로 저장하면 안된다는 것을 알고 계셨나요?
권장 사항이냐구요? 강제 사항입니다! 법으로 실제로 명시가 돼있거든요 ㅎㅎ
<인용1>은 가장 최근에 개정된 개인정보 법입니다:)
<인용1> 개인정보의 기술적·관리적 보호조치 기준[시행 2020. 1. 2.]
제6조(개인정보의 암호화) ① 정보통신서비스 제공자등은 비밀번호는 복호화 되지 아니하도록 일방향 암호화하여 저장한다.
Q. 그렇다면 '왜' 비밀번호는 평문으로 저장하면 안될까요?
개발자A: DB가 탈취되면 민감한 개인정보(비밀번호)등이 유출될 수 있기 때문에요! 해당 개인 정보는 개발자도 볼 수가 있어요!
실제로 페이스북🌐에선 비밀번호를 평문으로 저장했었습니다. 난리가 났었죠!
페이스북, 내부 서버에 사용자 비밀번호를 평문으로 저장해왔다
Q. 그렇다면 어떤 방식으로 저장해야 악의적인 사용자가 DB를 탈취하더라도 개인정보를 알기가 어렵게 만들까요? 또한 해당 웹 사이트의 개발자도 DB 정보만으로 개인 정보를 알기가 어렵게 만들 수 있을까요?
개발자A: 악의적인 사용자의 공격 방법을 알면 되지 않을까요? 적을 알고 나를 알면 백전 백승이라고 하잖아요! 웹사이트 개발자는..모르겠군요.. 알려주실 수 있나요?
저희는 지금부터 아래 순으로 문제(요구 사항)을 해결해 나갈 예정입니다!
1, 2번은 계속 반복할겁니다!
언제까지요? 예상할 수 있는 문제상황이 없을 때 까지입니다!
글을 읽으시면서 핵심 부분(노란)과 꼬리질문(초록) 부분에 집중하며 읽어주세요! 개인적으로 키워드에서 꼬리질문을 하는게 개념을 깊이있게 이해하는 과정이라고 생각합니다:)
목차
1. 문제 상황 분석(비밀번호 유출 가능, 개발자가 볼 수 있음, 노출 된 경우 피해 최소화)
2. 선택 가능한 기술 분석
3. 기술 선택 및 구현
1. 문제 상황 분석
문제 상황: 비밀번호가 평문으로 저장돼 있어, DB가 악의적인 사용자에게 탈취당하거나 해당 서비스 개발자가 DB 조회 시 민감한 개인 정보가 노출됨.
해당 문제 상황은 두가지 상황으로 다시 나눌 수 있습니다.
문제 상황 분류
1. DB가 악의적인 사용자에게 탈취당했을 시, 민감한 개인 정보가 노출됨.
2. 해당 서비스 개발자가 DB 조회 시, 민감한 개인 정보가 노출됨.
여기서 우리가 바꿀 수 있는 것과 바꿀 수 없는 것을 나눠보죠! 우리가 대비해야 하는 것은 바꿀 수 있는 것이니까요!
바꿀 수 없는 것
- 악의적인 사용자에게 탈취 당함.
- 해당 서비스 개발자가 DB를 조회
바꿀 수 있는 것
- 민감한 개인 정보가 노출
악의적인 사용자에게 탈취 당하는걸 막으면 되지 않나요? 라고 생각할 수 있습니다. 네. 막을 수 있습니다. 하지만 이는 DB에 데이터를 저장하는 업무를 하는 개발자의 영역이 아닙니다. 자신의 역할을 분명하게 정의하는게 때로는 문제 해결의 실마리가 되기도 합니다. 개발자가 DB를 조회하는 것도 당연히 할 수 있는 겁니다. 바꿀 수가 없어요! 그렇다면 바꿀 수 있는 것은 '민감한 개인 정보가 노출'되는겁니다.
그렇다면 어떻게 하면 민감한 개인 정보가 노출되는걸 막을까요? 노출되는건 막을 수 없습니다. 민감한게 문제인거죠!(방금 제가 살며시 바꿀 수 있는것과 없는 것을 분리했어요! 눈치 채셨나요?😀) 그렇다면 노출 되더라도 별로 쓸모가 없게 만들면 됩니다. 혹은 알아보지 못하게요!
비밀번호를 암호화 하면 될 것 같습니다! 선택 가능한 비밀번호를 찾아보죠!
2. 선택 가능한 기술 분석
암호화느 크게 양방향, 단방향 알고리즘으로 나뉩니다! 그 중에서 양방향 알고리즘의 대칭키와 비대칭 키부터 살펴보죠!
대칭키(양방향)
장점
- 암호화가 가능함
- 빠름
단점
- 비밀번호 평문 복구 가능(복호화 가능)
대칭키는 암호화가 가능하여 민감한 정보를 숨길 수 있습니다. 하지만 대칭키가 탈취된다면 비밀번호를 평문으로 복구가 가능하기 때문에 위험합니다. 개발자는 심지어 자유롭게 대칭키에 접근할 수 있으므로, 원한다면 언제나 비밀번호의 평문을 얻을 수 있겠군요!
비대칭키(양방향)
장점
- 암호화가 가능함(단방향 해시 성질 이용)
단점
- 비밀번호 평문 복구 가능(복호화 가능)
- 느림
비대칭키는 암호화가 가능하기 때문에 민감한 정보를 숨길 수 있습니다. 하지만 비대칭키 역시 양방향 암호화 알고리즘이기 때문에 공개키와 개인키를 알면 언제든 복호화가 가능합니다! 개발자는 두 키를 언제나 알 수 있죠! 아니 개발자는 정보 접근이 언제나 가능하니까 그럼 모든 알고리즘이 다 안돼야 하는 것 아닌가요?라고 질문할 수 있습니다. 여기서 문제는 복호화입니다! 복호화가 된다면 평문을 알 수 있기 때문에 문제가 되는겁니다. 복호화가 안되는 알고리즘은 뭐가 있냐구요? 아래로 내려가보시죠:)
Hash(단방향)
장점
- 암호화가 가능함
- 복호화가 불가능함
- 빠름
단점
- ?
해시 알고리즘을 사용하면 평문의 비밀번호를 해석하기 힘든 문자열로 바꿀 수 있습니다. 동시에 복호화가 불가능하죠. 왜 복호화가 불가능할까요? 단방향 알고리즘이기 때문입니다!
그렇다면 단방향 해시 알고리즘인 SHA-2를 사용하면 되겠군요!
실제를 이를 사용해도 문제가 없을지, 제가 생각한 과정과 결과가 맞을지 봅시다!
키워드만으로 검색한 결과 어렵지 않게 SHA 유관 알고리즘의 취약성에 대해 알아볼 수 있었습니다.
더 찾다 보면 네이버 D2에서 소개한 안전한 패스워드 저장에서 단방향 해시 알고리즘의 취약성에 대해 찾아볼 수 있습니다.
다음 글에선 d2.naver.com를 보고 정리한 단방향 해시 함수의 문제점과 해결 방안 및 실제 Spring 프로젝트에 적용하는 방법에 대해 알아보겠습니다!
다음 글 스포: sha-256 알고리즘은 메세지 인증 용도로 개발되어, 레인보우 테이블을 쉽게 만들 수 있기 때문에 브루트 포스에 취약하다는 것을 알았습니다. 그에 반해 Bcrypt 알고리즘은 비밀번호 해싱 용도로 개발 됐기 때문에 브루트 포스에 비교적 강하다고 판단
'알고리즘 > 칼럼' 카테고리의 다른 글
| 브루트포스 공격 특성을 고려한 비밀번호 해싱 알고리즘 선정 및 Spring 적용 (2) (0) | 2022.06.29 |
|---|
