JS 보안 로그인 건의

[ajkj]

XE자체에 기본적으로 Javascript를 이용한 로그인/회원가입시 비밀번호 및 기타 중요한 정보를 암호화 하여 전송하는 기능 내장하는 것에 대해 어떻게 생각하시는가요?

ex) http://www.jcryption.org/

예전에 3rd party의 addon 형태로 처리하려고 했으나, core를 건드리지 않고서는 수정이 불가능 하더군요. 단순 http post나 get은 그래도 core에서 js 파일 하나만 건드리면 되나, 이 경우에도 act나 mid등은 암호화 자체가 불가능 하였습니다.
ajax의 형태는 xe-core를 더 많이 손봐야 하는것 같더군요...

이러한 기능이 내장되면, 클릭한번에 편리하게 보안을 증진시켜 준다는 점에서 유용할 것 같습니다.

[kijin]

XE 공홈의 포럼에서도 ajkj님의 제안과 관련된 논의에 몇 차례 참여한 적이 있는 기진곰입니다. ajkj님은 이미 짐작하셨겠지만, 저는 이 제안에 무척 회의적입니다.

클릭 한 번에 편리하게 보안을 증진시켜 준다기보다는, 보안이 증진된 것 같은 느낌이 들게 해주는 일종의 플라시보(placebo)에 불과하다고 생각하기 때문입니다.

수동적인 스니핑(감청)만 막으면 되던 시절은 벌써 지났습니다. 이제는 미국의 정보기관뿐 아니라 커피숍 맞은편에 앉아있는 손님조차 손쉽게 중간자 공격을 할 수 있는 세상입니다. 패킷을 몰래 볼 뿐만 아니라 자기가 원하는 패킷을 삽입하는 것도 가능하다는 뜻이죠.

SSL(TLS)을 제대로 사용할 경우에는 아래의 4가지를 보장해 줍니다.

1. 주고받는 정보를 아무도 볼 수 없도록 암호화합니다.
2. 주고받는 정보가 중간에 제3자에 의해 변조되지 않았음을 확인합니다.
3. 상대방이 정말 내가 생각하는 그 사람(서버)이 맞는지 확인합니다. 인증서가 수행하는 역할이 바로 이것입니다. 인증서 발급 기관에서 도메인 소유권을 확인해 주니까요.
4. 통신 내용은 영원히 비밀로 남습니다. Perfect forward security라고 하죠. 심지어 누군가가 서버를 해킹해서 개인키를 빼돌린다 해도 이전에 통신한 내용을 복호화할 수는 없다는 뜻입니다.

SSL(TLS)을 사용하지 않은 상태에서 자바스크립트로 구현한 암호화 기술은 1번밖에 보장할 수 없습니다. 상대방이 내가 생각하는 그 사람(서버)이 아니라 중간자일 수도 있고, 그 중간자가 내가 주고받는 정보를 변조했을 수도 있기 때문입니다. 그래서 jcryption은 서버에서 클라이언트에게 암호화 키를 전송하는 패킷을 가로채어 공격자의 키로 교체하면 모든 통신을 복호화할 수 있게 된다는 결정적인 취약점이 있습니다.

도저히 SSL(TLS)을 사용할 수 없는 경우에 차선책으로 자바스크립트 암호화 기술을 사용할 수는 있겠습니다. 그래서 이런 기능을 애드온으로 만들어 배포하는 것에는 반대하지 않겠습니다. 그런 애드온을 구현하기 위해 코어에 새로운 트리거를 몇 개 추가해야 한다면 그것도 괜찮습니다. 그러나 코어 자체에 자바스크립트 암호화 기술을 추가하는 것은 반대합니다. 명백한 한계가 있다는 점을 사용자들에게 이해시키기도 어렵고, 이에 따라 너무 쉽게 뚫을 수 있는 반쪽짜리 암호화 기술을 채택하는 사이트가 급증할 우려가 있기 때문입니다.

[ajkj]

SSL을 부분적으로 HSTS 없이 사용한다면, JS 암호화랑 취약점에 있어서 그렇게 큰 차이가 나지 않는다고 생각합니다. 안전만을 추구한다면, SSL 부분사용 옵션 또한 제거하고, 전체 사용 옵션만을 남겨 두어야 겠지요.

대부분의 웹사이트가 SSL + HSTS 는 커녕, 부분 사용조차 하지 않고 있는 상황에서 JS암호화는 SSL 부분사용과 유사한 수준의 암호화를 클릭 한번에 간편하게 제공 해주는 것에 의의가 있다고 생각합니다.

장기적으로는 SSL+HSTS를 적용하고 강제까지 하는것이 옳겠지만, 당장은 힘드니, 임시로 SSL 부분옵션(현재 제공됨) 또는 JS암호화를 추가로 집어 넣자는 것이지요.

그리고 예전에 간단히 만들어 본 결과, 이 부분은 3rd party를 위한 지원만으로는 힘든 부분 입니다.
core에서 모듈 생성 전 Context.class.php에서 get, post를 Context에 넣기전에 우선적으로 처리(복호화)해 주어야 하며. xe.min.js 또한 변경시켜 주어야 하기 때문입니다.(수정하지 않고서는 할 수 있는 방법이 없습니다)

그리고 애드온 형식으로 처리하면 Context, GET, POST를 이용하는 다른 애드온과 충돌할 우려가 있다고 생각합니다.

[kijin]

일반적인 SSL 부분사용 방식에 문제가 있다는 것은 저도 인정합니다. 그러나 세션쿠키와 별도로 secure 옵션을 추가한 쿠키를 하나 더 굽고, 개인정보 열람·변경 등 중요한 작업시에는 이 쿠키를 확인하도록 하는 등의 방법으로 어느 정도는 회피가 가능한 문제입니다. 로그인이나 중요한 작업시에 주소창을 보기만 하면 보안이 제대로 되고 있는지 확인할 수도 있고요. (지금은 #927 때문에 이상하게 꼬여 있긴 하지만...) 저 악명높은 sslstrip도 주소창을 확인하는 사람에게는 통하지 않습니다.

JS 암호화는 그나마 이만큼의 보안도 제공하지 못합니다. 당장 보안이 되고 있는지 확인하는 것조차 어렵지요. XE가 불완전한 보안 방식을 지원하게 된 것은 이미 엎질러진 물이니 어쩔 수 없지만, 그것보다 더 불완전한 보안 방식을 하나 더 추가하는 것은 말리고 싶습니다.

그러나 코어에서 수정해 주면 좋겠다고 말씀하신 부분은 저도 동의합니다. Context를 생성하기 전에 끼어들 방법이 없다는 점은 늘 아쉬웠어요. 심지어 auto_prepend_file을 사용한 꼼수까지 부려 봤죠 -_- 폼 전송 직전에 JS로 폼을 조작하기가 어렵다는 점도 공감합니다. 자바스크립트 쪽에서도 다양한 트리거를 쓸 수 있으면 좋겠네요. 코어 수정이 다소 필요하긴 하겠지만, 필요한 부분의 수정만 이루어진다면 님이 원하시는 기능도 충분히 애드온 또는 그와 유사한 형태로 구현이 가능하게 될 것이라고 생각합니다.

[ghost]

Github 이슈 정리 계획을 바탕으로 이슈를 종료합니다.

이 이슈의 내용이 최신 버전에서도 여전히 발생하는 문제이거나 개선되었으면 하는 내용이라면 새로 작성해주시거나 (멘션)'@bnu'를 포함하는 내용으로 댓글을 남겨주시기 바랍니다.

예시) @bnu 이 버그가 여전히 문제가 있습니다