CODEOK.NET

Page history of 패스워드 보안의 기술



Title: 패스워드 보안의 기술 | edited by Youngrok Pak at 9 years, 2 months ago.

<p>회원가입을 받는 인터넷 서비스를 개발할 때 사용자의 패스워드를 어떻게 보관할 것인가? 제일 쉬운 방법은 물론 페이스북 로그인을 붙이고 <em>패스워드 보안 같은 건 페이스북님이 알아서 해주세요</em> 하는 것이다. 인증의 아웃소싱은 보안 관점에서 서비스 제공자, 사용자에게 모두 유익한 방법이다. 구글, 트위터, 링크드인 등을 다 연동시켜서 선택할 수 있게 하면 의존성 리스크도 조금은 덜어낼 수 있다. 이 글의 주제와 걸맞지 않지만, 정말로 회원 인증은 소셜 로그인이 더 낫다.</p>
<p>그럼에도 불구하고 직접 회원인증을 해야하는 상황이 없지 않은데, 그럴 때 중요한 문제로 떠오르는 것이 보안이고, 그 보안 문제 중에서 한국의 인터넷 서비스들이 오랫동안 잘못해왔으며 지금도 많은 서비스들이 잘못하고 있는 것이 패스워드의 보안이다. 아직도 외부 업체 컨설팅을 다니다보면 패스워드를 잘못 저장하는 경우를 심심찮게 보고, 패스워드 입력 인터페이스만으로도 패스워드를 잘못 저장하고 있는 것으로 추정되는 사이트들이 보인다.</p>
<p>그래도 몇년 전 <a href="http://www.kb.cert.org/vuls/id/836068">md5 파동</a> 이후 패스워드 보안에 대한 지식이 개발자 사이에 많이 퍼져서 지금은 올바른 패스워드 저장 방식을 사용하는 개발자들이 많다. <a href="https://docs.djangoproject.com/en/1.7/topics/auth/passwords/">Django 같은 프레임웍에서는 기본으로 강력한 패스워드 저장 방식을 채택</a>하고 있기 때문에 <span style="text-decoration: line-through;">본의 아니게</span> 안전하게 저장하고 있는 개발자도 많다. 그렇지만, 왜 그런 방식이 안전한지, 기존에 사용되던 방식은 왜 취약한지, 현재 사용하는 방식의 한계는 뭔지 등등에 대해 깊이 알고 있는 개발자는 드물다. 그래서, 이번 글을 기획했다. 이 글에서는 다음과 같은 내용을 다룬다.</p>
<ul>
<li>패스워드를 해싱해야 하는 이유</li>
<li>왜 양방향 암호화는 안되는가?</li>
<li>md5를 비롯한 단방향 해싱은 어떻게 뚫리는가</li>
<li>salt는 무엇이며 어떻게 사용하는가</li>
<li>권장할 만한 패스워드 저장 방식</li>
</ul>
<p>다루는 내용에서 보다시피 이 글은 정답을 알려주기 위한 실용적인 글이 아니라, 왜 그 정답이 도출되는지 궁금해하는 개발자의 호기심을 충족시켜주기 위한 글이다. 실용적인 목적으로 들어온 독자는 바로 다음 문단까지만 읽어도 된다.</p>
<h3>올바른 패스워드 저장 방법</h3>
<p> </p>
<h3>패스워드를 암호화해야 하는 이유</h3>
<p>패스워드를 저장하는 올바른 방법은 이제 알았다. 그런데 왜 저렇게 복잡하게 저장해야 할까? 패스워드를 평문으로 저장하면 왜 안되는가? <a href="http://ppss.kr/archives/16823">알기 쉽게 설명한 패스워드 암호화</a>에 잘 설명되어 있는데, 질문에 대한 답만 간단히 요약한다면 서버의 데이터베이스가 털렸을 때도 회원의 패스워드를 알 수 없게 만들기 위한 것이다. 패스워드가 잘 해싱되어 있으면 해커가 그 해시 값을 보더라도 사용자의 계정으로 로그인할 수 없기 때문에 해커에게 의미 없는 정보가 된다.</p>
<h4>데이터베이스를 잘 지키면 되지 않나?</h4>
<p>그럼 여기서 의문이 하나 생긴다. <strong>서버를 안 뚫리게 하면 되지 않나?</strong> 패스워드를 안전하게 저장하려는 노력을 기울이는 대신, 서버 보안을 신경 쓰는 게 더 좋지 않을까? 원천봉쇄가 더 좋은 것은 당연하다. 하지만, 문제는 그 원천봉쇄가 쉽지 않다는 것이다. 서버는 보안 위험 요소가 너무 많아서 완벽하게 지키는 것이 어렵다. 게다가, 실제로 서버가 해킹 당하지 않아도 데이터베이스는 털릴 수 있다. 개발자가 데이터베이스를 백업한 덤프 파일을 옮기는 과정에서 실수로 SSL이 아닌 통신을 사용한다거나, 메일 따위로 주고 받는다거나, 로컬로 내려받아놓고 자리를 비운 사이 PC에 다른 사람이 접근한다거나 등등. 물론, 이런 초보적인 수준의 실수는 충분히 통제할 수 있다고 생각할 수 있을지 모른다. 그런데, 만일 개발자가 악의적인 의도를 가지고 패스워드를 본다면? 자기가 개발하는 사이트에 옛날 여자친구가 가입했다는 사실을 알고 그 여자친구의 패스워드를 알아낸 다음 그걸로 페이스북에 로그인을 시도한다면? 개발자들의 도덕성이 충분하다고 한들, 그런 가능성이 열려 있는 웹사이트에 가입하고 싶겠는가. 그래서, 원천봉쇄보다는, 데이터가 털리더라도 패스워드가 유출되지 않게 저장할 필요가 있는 것이다.</p>
<h4>양방향 암호화</h4>
<p>md5, sha1 등의 해싱 알고리즘이나 AES 같은 양방향 암호화를 둘다 묶어서 암호화라고 부르기도 하고, 해싱은 암호화가 아니고 양방향 암호화만 암호화라고 하기도 하는데, 암호화의 목적이 반드시 복호화인 것은 아니므로 굳이 해싱을 암호화가 아니라고 할 필요는 없다. 영어권에서도 해싱과 관련해서 encryption, cryptocraphic hash function 등의 표현을 쓴다. 아무튼, 패스워드를 암호화해야 한다면 AES처럼 복호화가 가능한 방식으로 할 수도 있을 텐데, 왜 굳이 복화하가 불가능한 단방향 암호화를 하는 것일까?</p>
<p>그 이유는 패스워드를 평문으로 저장하지 않는 이유와 같다. 양방향 암호화는 알고리즘과 키값만 노출되면 바로 복호화가 가능하다. 서버가 해킹 당한 상황이면 소스코드도 다 노출된 상황이므로 알고리즘과 키값 모두 노출된 상황이나 마찬가지다. 그리고 역시 위에서 언급한 것과 마찬가지로 내부 개발자는 이미 알고리즘과 키, 데이터베이스에 모두 접근이 가능하므로 원하면 언제든 사용자의 패스워드를 볼 수 있다. 그래서, 패스워드 보안에서 양방향 암호화는 별 의미가 없다. 평문으로 저장한 것과 별반 다르지 않은 보안 수준이라고 할 수 있다.</p>
<p>원래 양방향 암호화는 데이터 보관의 보안보다는 통신 상황에서의 보안에 더 유용한 암호화다. 데이터 보관의 보안도 의미가 있으려면 키값을 보안을 유지하고 싶어하는 사람만 갖고 있어야 하므로 서버의 키값으로 양방향 암호화를 하는 것은 데이터 보관의 보안에서는 별 의미가 없다. 최근 이슈가 되었던 카톡의 보안 문제도 간단치 않은 게, 단순히 서버의 키값으로 암호화를 하면 검찰이 데이터를 요구할 때 복호화해줄 수 있으므로 의미가 없다. 그래서 클라이언트끼리 키값을 주고 받고 그 키값으로 암호화해서 통신해야 하기 때문에 생각처럼 단순한 문제는 아니다.</p>
<p> 
Wiki at WikiNamu