로그인 비밀번호를 지켜라

안녕하세요. SmilePay Engineering 팀 문한국입니다.

이번 글에서는  스마일페이의 보안성 강화를 위하여 로그인 비밀번호 암호화를 도입한 사례를 공유하려고 합니다.

 

선정 배경

스마일페이는 고객의 결제와 관련된 업무를 하다보니 보안을 상당히 중요시 합니다.

그래서 로그인 비밀번호의 경우도 HTTPS 통신을 통한 SSL 보안과 더불어 RSA 암호화를 통해 로그인 비밀번호를 암호화 후 통신하고 있습니다.

HTTPS 의 경우 네트워크 구간에서는 비밀번호의 암호화가 이루어지나, 네트워크 전송 전 구간에서의 보안은 취약하였습니다.

아래 그림은 로그인 비밀번호 암호화를 도입하기 전 브라우저 개발자 도구 네트워크 탭을 캡쳐한 것입니다.

 

 

암호화 전 캡쳐 화면

로그인 버튼을 눌렀을 때 개발자 도구 네트워크 탭에 찍힌 것과 같이 비밀번호(SmilePw) "testmoon!123" 이 평문으로 노출됩니다.

이러한 부분을 보완하기 위하여 스마일 페이의 로그인에서는 RSA를 통한 비밀번호 암호화를 진행한 후 API 전송을 하고 있습니다.

이러한 부분이 이미 적용된 사이트들도 있지만 아직 그렇지 못한 사이트들도 존재하고 한번 소개하면 좋을 것 같아서 선정하게 되었습니다.

 

RSA 적용기

RSA를 적용한 비밀번호 암호화 작업은 이처럼 개발자 도구 네트워크 탭에 조차 비밀번호가 노출되지 않도록 Client에서 암호화를 한 후

HTTPS 를 통하여 스마일 페이 서버로 암호를 안전하게 전송하여 보안을 강화한 작업입니다.

Client에서의 암호화를 위하여 RSA 암호화를 도입하였고 암복호화 진행 순서는 아래와 같이 작업하였습니다.

 

1. Client는 Server로 RSA Key를 요청한다.

2. Server는 Private Key , Public Key를 생성한다.

3. Server는 생성한 Key 중 Private Key를 Redis에 저장한다.

4. Server는 Public Key와 3.에서 저장한 Redis의 Key를 Client로 리턴한다.

5. Client는 전달받은 Public Key로 비밀번호를 암호화한다.

6. Client는 암호화된 비밀번호와 4에서 받은 Redis Key를 Server로 전달한다.

7. Server는 Redis Key로 Private Key를 조회한다.

8. Server는 Private Key로 암호화된 비밀번호를 복호화한다.

9. Redis의 Private Key를 삭제한다.

 

 

암호화 과정

9번 과정에서 혹시 모를 Private Key 노출을 방지하기 위하여 사용한 Private Key는 즉시 폐기하였습니다.

이렇게 구현 후 동일한 로그인 페이지에서 로그인시 개발자 도구 네트워크 탭을 캡쳐한 화면입니다.

 

암호화 후 캡쳐 화면

입력한 암호 "testmoon!123" 이 암호화되어 네트워크 탭에서는 입력한 암호 평문이 확인 되지 않도록 수정되었습니다.

암호는 RSA 암호화되어 EncrypyPw 값으로 서버에 전달되게 됩니다.

 

로그인이 안되면?

이렇게 RSA 암호화를 통하여 고객의 비밀번호를 안전하게 보호하는 작업을 성공적으로 마무리하였습니다.

하지만 저는 한가지 걱정이 되었습니다.

회원의 로그인은 이후 결제와 직결되는 중요한 과정이며 어떠한 상황에서든 고객의 로그인은 절대적으로 가능하여야한다고 생각합니다.

하지만 지금과 같은 구조에서는 Redis의 장애 발생 시 로그인이 불가해지는 크리티컬한 이슈가 생깁니다.

Redis는 캐시성 데이터를 저장하는 목적의 DB로써 충분히 장애가 발생할 가능성이 있는 DB 성격을 가지고 있다고 판단하였고,

Redis의 장애에서도 안전한 로그인 프로세스를 고민하였습니다.

 

서킷 브레이커 적용기

Redis 장애시 로그인 프로세스를 가능하게 하기 위하여 서킷 브레이커 패턴을 적용하였습니다.

평상시 Redis 접속이 잘 되고 조회가 잘 될 때는 기존대로 Redis를 사용하고 ,

Redis 조회가 원활하지 않거나 문제 발생하여 서킷 브레이커에 설정한 조건에 충족되었을 경우는 FallBack 함수를 호출하도록 하였습니다.

FallBack 함수에서는 Private Key와 생성시간을 묶어 암호화 후 Token 형태로 Client에 리턴하도록 하였습니다.

그러다가 다시 Redis가 정상화되었을 때는 기존처럼 Redis에 Private Key를 저장하는 형태로 구동되도록 구현하였습니다.

Redis 장애 시 암호화 과정

서킷 브레이커 참고 글 : https://dev.gmarket.com/40

마무리

이렇게 RSA 암호화를 통하여 로그인 비밀번호에 적용 후 안정적으로 서비스되는 것을 확인하고,

현재는 캐시 출금 , 캐시 전환 등 주요 정보를 암호화하는 부분에서 추가적으로 적용하여 사용하고 있습니다.

지금까지 스마일 페이의 보안을 강화하기위하여 RSA 암호화를 적용했던 사례를 공유드렸습니다.

보안상 소스코드를 함께 소개하며 공유드리지 못한 부분에 아쉬움이 있지만 많은 양해 부탁드리며 끝까지 읽어주셔서 감사합니다.