내 문제 : 비밀번호를 hash처리 후 저장
졸업 프로젝트로 스마트 컨트랙트를 다룰 때, 스마트 컨트랙트 사용자 인증을 위해 비밀번호를 저장할 필요가 있었다.
빨리 만들다보니 비밀번호를 단순히 해시 처리해서 저장했었다..
자소서를 쓰면서 다시 확인하다보니 비밀번호에서 부족한 것이 보였다. 그래서, 다른 암호화 방법을 찾다 보니 Naver D2에 좋은 글이 있어 대략적으로 정리했다.
단방향 해시
비밀번호를 단순히 해시처리한 것을 단방향 해시라고 한다.
단방향 해시는 역으로 찾는 것은 어렵지만, 정방향으로는 빠른 속도로 계산된다.
(+ 해시처리된 값을 다이제트스트라고 한다. )
하지만, 다음과 같은 단점이 있다.
1. 해시처리가 빠르기 때문에, brute force로 매우 빠르게 답을 대조할 수 있다. 또한, 비밀번호가 짧을수록 더 위험하다.
2. 다른 웹 사이트와 동일한 비밀번호를 사용하는 경우도 있다.
3. "입력-다이제스트" 테이블을 최대한 많이 확보하여, 중간에서 탈취한 다이제스트를 비교해서 원본을 얻을 수 있다.
이 문제는 salting + key stretching 방법으로 보완할 수 있다.
salting : 소금 치는 것마냥 원래 값에 특수한 값을 추가하여, 입력-다이제스트 테이블로 원본을 알아도 비밀번호를 알아내기 어렵게 한다.
key stretching : hash 처리를 여러 번 돌려, brute force 시간을 더 오래 걸리게 할 수 있다.
사실 여기까지만 읽었을 때, "그럼 salt랑 key stretching을 내 맘대로 마구 섞으면 안전하겠다!"라고 생각했다.
하지만, 그럴 경우 잘못된 일이 발생했을때발생했을 때 어디가 취약한지를 알기 어렵다는 것을 알았다. 차라리 이미 검증된 기술을 사용하면 혹시라도 잘못된 일이 발생했을 때, 더 빠르게 취약점을 찾을 수 있다.
Adaptive Key Derivation Functions
다이제스트 생성 시, 소팅과 key stretching 외에도 다른 입력 값을 추가하여 다이제스트 유추를 어렵게 하는 함수
검증된 종류는 다음과 같이 여러가지 있다.
1 PBKDF2 : 미국 정부 시스템에서 사용자 비밀번호에 사용
2 bcrypt : 패스워드 저장을 목적으로 사용. 또한, 다양한 언어에서 라이브러리로 제공된다. 미래에는 PBKDF2보다 강력할 것이라고 한다.
3 scrypt : 다이제스트 생성 시 메모리 오버헤드를 갖게 하여 brute force시 매우 어렵다. bcrypt보다도 더 경쟁력 있을 것이라고 한다. 보안에 아주 민감한 경우에 사용된다.
후기
졸프에서 스마트컨트랙트에 hash한 경우를 생각해보면서 읽었다.
첫째로, hash의 빠른 처리가 위험하지만 블록체인의 자체 거래 속도가 느려서 그나마 안전하지 않을까도 생각했다. 하지만, 스마트 컨트랙트가 처음 생성될 때 다이제스트가 유출될 수 있었다.
둘째로, 스마트 컨트랙트에서 너무 많은 계산은 작동되지 않기 때문에 적용이 가능할까 라고도 생각했었다.
하지만 이것도 처음 스마트컨트랙트 생성 시 위에 함수들을 브라우저? 에서 실행해서 넘어오면 될 것이라는 생각이 든다.
+ Naver D2에서 "보안 시스템은 가장 약한 연결 고리만큼만 강하다." 라고 한 내용이 인상 깊었다.
출처 : Naver D2 https://d2.naver.com/helloworld/318732
'기술' 카테고리의 다른 글
Spring Boot의 Java 버전 변경하기 (maven, Intellij) (0) | 2024.05.08 |
---|---|
Maven을 이용한 웹 어플리케이션 생성 및 설정 (0) | 2022.07.23 |
Maven이란? (0) | 2021.01.08 |
RHEL7의 malloc (0) | 2021.01.03 |
Unicode와 encoding (0) | 2020.09.09 |