로그인 및 회원가입시에 SALT값 자체를 암호화, 복호화 할 수는 없을까요?

Question

회원가입시에 단방향 SHA512로 암호화를 하여 PW를 저장하는데, 이때 SALT값은 사용자마다 랜덤하게 16바이트를 할당받고, 이를 사용하여 레인보우 테이블 공격에 대한 저항성을 어느정도 갖도록 했습니다. 중요한 것은, 일단 PW자체는 SHA를 두 번 적용하여 단방향으로 암호화 했기에 보안상 문제는 없을 것으로생각하는데, SALT값 자체는 평문 그대로 DB에 저장이 되어있습니다.이 SALT값 자체를 대칭이든 비대칭이든 암호화하여 저장할 수 있는 방법이 있을까요? 우선, AES나 RSA를 사용하여 SALT를 암호화 저장한다면무식한 방법으로는 소스코드 자체에 비밀키를 하드코딩하는 방법이야 있겠지만보안상 당연히 문제가될 방법이니 제쳐두고 사용자의 ID, 전화번호, 이메일주소는 UNIQUE한 값인데, 이 값을 적절히 이용해서AES 대칭키, 또는 RSA 비밀키를 만들어내는 메소드를 만들어 SALT를 암호화 하는데에 사용해야할까요?이런 방식을 사용하면, 사용자 전화번호, 이메일이 변경되었을때 다시 SALT를 할당 받아야하고또 다시 PW를 암호화해야 하는데, PW자체가 이미 단방향으로 암호화되서 복호화가 불가능하니사용자로부터 새로운 PW를 설정하도록 번거로운 절차를 거쳐야 할 것 같네요. 보통 SALT값은 DB에 암호화하지 않고 그냥 저장하나요?아니면 다른 좋은 방법이 있을까요?

HJOW · Accepted Answer

궂이 SALT값을 암호화할 필요가 있을까요? 비밀번호 원문을 알 필요는 없지만, 비밀번호가 입력값하고 같은지 비교하려면 결국 SALT값을 알아야 하죠. 그러면 SALT값은 원래값으로 복호화할 필요가 있다는 뜻이 되죠. 그러면 AES 같은 걸 써야 하는데 그러면 AES에 쓰일 암호는 또 암호화해서 저장하고 그 암호 또 암호화해서 저장하고... 무한반복할 게 아닌 이상 적당히 안전한 수준으로 이용하면 되겠죠.이불 밖이 위험하다고 침대에서 평생 지낼 것은 아니잖아요. 그래서 SALT값 자체는 복호화 안하거나, 1번만 AES로 암호화해줘도 된다 생각합니다.AES로 1회 할 경우 암호는 그냥 소스코드에 박아놓구요.

Blanc.et.Noir · Answer

음... 사실 비밀번호 저장시에 단방향으로 암호화 하는 것과 관련하여 구글링을 30여분 좀 해봤는데그 중 유일하게 한 블로그에서 SALT자체에 대한 암호화의 중요성을 강조하더라구요. 대부분 포스팅이나 정보글을 보면 SALT에 대한 암호화는 따로 하지 않기도 했고네트워크 보안과 관련된 책을 뒤져봐도 SALT에 대한 암호 필요성은 언급되어있지 않은데 사람의 마음이 긍정 보다는 부정적인 것에 좀 더 관심이 가기 마련이랄까요?SALT에 대한 암호화 필요성을 강조하는 글을 읽고나니 정말 그런가? 하는 생각이 들어서노심초사하는 마음으로 이렇게 질문 드렸습니다. 답변 감사합니다.

HJOW · Answer

일단 한 가지 생각하고 넘어가야 하는 게서버OS에 해커가 액세스를 했다면 게임은 끝난 걸로 봐야 합니다.DB도 마찬가지로, 해커가 DB에 쿼리문을 조작해서 원하는 SQL문을 실행할 수 있으면 게임은 끝난 것입니다. SALT문을 따내려면 DB에 액세스해야 합니다.SALT문이 유출됐다는 건 이미 DB가 뚧렸다고 봐야 됩니다. 참고로 비번을 암호화해서 DB에 저장해야 된다고 하는 이유는사람들이 여러 사이트 회원가입할 때 동일한 비번으로 회원가입하기 때문입니다.그래서 유출되더라도 비번만큼은 원문을 모르게 하려는 것이죠.근데 SALT는 다른 사이트들은 다 다르게 쓰죠.

Blanc.et.Noir · Answer

인가되지 않은 사용자는 DB보안을 뚫지 않는이상 직접 SALT를 질의하여 얻어내는 것이 불가능하겠지만인가된 애플리케이션 서버에서 DB에 SALT를 요청했고, DB가 이를 응답하는 과정에서 전달되는 패킷을도청할 우려는 없을까요? 현재는 로컬호스트에 톰캣서버며, DB며 같은 위치에 존재하긴 하지만, 언젠가 물리적으로 분리를 시킨다면...

HJOW · Answer

DB를 물리적으로 분리시키면 분명 문제가 될 소지는 있죠.그런데 일단은 대부분 DB와 웹서버는 같은서버에 운영하거나, 분리시키더라도 같은 방에 두고 같은 라우터에 물리거나 적어도 동일한 건물에 둡니다. 그리고 네트워크에서 라우터들은 각자 IP테이블을 만듭니다.처음 패킷이 오면 해당 주소로 보내기 위해 어디로 보내야 될지 모르니까 무차별적으로 보냅니다.그리고 그 패킷에 대한 응답이 오는 곳이 있으면 아 이 주소는 이곳으로 보내면 되는구나 하고 IP테이블에 기록합니다.그다음부터 패킷이 오면 가장 접속이 빠른 IP주소를 IP테이블에서 찾아 패킷을 전달합니다. 무차별적으로 뿌리지 않는다는 것입니다.그래서 사실 우려의 상황 발생확률도 매우 낮습니다. 그조차도 우려가 된다면서버는 분리하되, 독립적인 포트로만 통신하게 만들면 됩니다.웹서버 깔린 서버와 DB깔린 서버 양쪽에 별도의 랜카드를 추가로 장착하고스위치도 별도로 구매해서 외부 인터넷과 연결하지 않고 두 서버만 연결하는 겁니다.

Blanc.et.Noir · Answer

좋은 답변 감사합니다.아무래도 실무 경험이 없다보니, DB를 웹서버와 분리시키는게 당연한 것인줄만 알았는데 꼭 그런건 아니었군요.우선은 말씀하신대로 웹과 DB를 동일한 곳에 구성을 해야겠습니다. 감사합니다.

로그인 및 회원가입시에 SALT값 자체를 암호화, 복호화 할 수는 없을까요?

6개의 답변

Q&A 목록