암호화에 대한거라고는 단순히 '해쉬 알고리즘 최강~~, 근데 MD5, SHA 등등 골라 쓰세요' 로 알고있던
저 였지만
이번에 Spring Security 구성하다가 PasswordEncoder가 MD5, SHA 등등 Deprecated 되었길래
왜 Deprecated 되었나 찾아보다가 암호화를 잘 모른다고 생각이 들어서 공부해보았습니다.
좀 더 정확히는 단방향 암호화, 해쉬 함수를 사용한 암호화 방식들에 대해 공부하는거겠네요.
SHA-1
160비트 사이즈로 해시 값을 생성합니다.
SHA-256
256비트 사이즈로 해시 값을 생성합니다.
SHA-512
512비트 사이즈로 해시 값을 생성합니다.
SHA 특 : GPU 연산에 너무 빠르게 연산됨
당연히 비트 사이즈가 크면 클수록 보안적으로 안전합니다만 그만큼 연산 속도가 더 늘어납니다.
이렇게 많이 사용하던 암호화들은 왜 현재 권장하지 않는 암호화 방식이 되버린 걸까요?
시간에 지남에 따라 레인보우 테이블이 널리고 널렸기 떄문에.....(salt가 없는 레인보우 테이블) 보안적으로 취약하다고 합니다....
실제로 레인보우 테이블 검색해서 다운받아 본적이 있었는데 ㄹㅇ로 매칭되더라고요..........
또한 브루트 포스 공격방법은 막을 방법이 없기 때문에
최대한 연산이 오래걸리도록 비트 사이즈로 계속 늘리는 방향으로 암호화가 이루어졌던 것 같습니다.
시간만 있다면 뚫리긴 한다는 소리죠
그러면 요즘 트렌드가 되고있는 암호화는 어떤건지 알아보시죠
무작위 Salt Generator의 존재
동일한 데이터로 암호화를 하여도 무작위 Salt가 결합하여 암호화되기 때문에 항상 다른 결과값이 나옵니다.
몇번이든 해싱을 할 수 있다 (Key Stretching)
원본 데이터를 한번만이 아닌 여러번 해싱을 할 수 있다는 장점이 있습니다만 그만큼 연산속도가 엄청 늘어납니다. 물론 반복횟수를 설정해줄 수 있어요.
(Spring PasswordEncoder 가중치 기준 2^4 ~ 2^31 만큼 반복)
Salt를 알아서 생성해줘서 편한 것 같아요
SHA-256 같은거 할 때는 Salt 직접 정의해주고 붙이는 방식으로 해서 귀찮았는데 ㅋㅋㅋ
해당 특성때문에 Bcrypt 암호화 방식은 높은 보안성을 자랑해서 현재 권장되고 있는 암호화 방식인데요.
여기서 무조건 압도적으로 보안성이 높은것이 좋을까? 라는 질문에 고민을 해야할 것 같습니다.
보안성이 높다라는 의미는 어느정도 암호화 비용이 높다고 봐도 되기 때문에
성능적인 측면도 생각해봐야 하는데요.
서비스 특성, 성능과 보안을 둘 다 생각하여 합리적인 암호화 방식과 설정을 하면 될 것 같습니다.
장난삼아 Hash 결과값에 대한 원본 데이터 뽑아내는 사이트를 공유해드립니다.
여기서 나오면 보안이 취약하다고 보면 될 것 같네요

스프링에서는 위와 같은 암호화 방식을 지원하고 있는데
몇 버전에서는 못보던 암호화방식이 있는걸 보아서는 버전마다 추가되는 암호화 방식들이 있나보네요.
스프링에서 Bean으로 StandardPasswordEncoder 라던가
특정 PasswordEncoder로 적용하면 무조건 그 암호화방식으로만 작동하는데
DelegatingPasswordEncoder라는 걸로 등록해두면
앞에 prefix로 암호화 ID 에 따른 암호화 방식으로 작동합니다.
물론 DelegatingPasswordEncoder 내부에 해당 방식의 PasswordEncoder들이 등록되어있어야합니다.
암호화에 대해서 무지성으로 MD5, SHA-256이 쓰던날들이 진짜 많았었는데 ㅋㅋㅋㅋㅋㅋㅋ
반성하게 되면서
보안에 대한 중요성을 다시 한번 깨닫게 되네요.
보안이란건 항상 털리기 전까지는 인식을 못하는 것 같아서 더더욱 주의해야할 것 같아요.
털리는 순간 끝이니까.....
주변에 보안하는 친구가 있었으면 관련 내용 재밌게 들었을 것 같은데
없어서 아쉽네요