MITM공격에 따른 password 노출 취약점

[taeguk]

회원가입하는 부분에서 password를 암호화하지 않아 네트워크 상에서 중간자공격을 당할 시, password가 그대로 노출되는 취약점이 있습니다. (로그인, 비밀번호 변경 부분에도 같은 취약점 존재) 해결방법은 sha512같은 단방향 해쉬 알고리즘을 사용하여 password를 암호화한 후 서버로 전송하면 됩니다. http://pajhome.org.uk/crypt/md5/sha512.html 등을 이용하여 javascript단에서 form 전송 시 password를 sha512로 hash해주면 좋을 것 같습니다.

[minhoryang]

@taeguk 헤헤! 우리는 letsencrypt로 https를 걸어버릴 예정이에요! 그래도 sha512가 필요할까요? https와 cert pin을 건다면?

[taeguk]

@minhoryang 제 생각에는 그래도 client단에서 비밀번호는 hash를 해야된다고 생각해요. Server는 무슨 일이 있더라도 유저의 비밀번호 원문을 알 수 있으면 안되요. https를 사용할 경우, server는 암호화된 유저의 password를 복호화하여 원문을 알아 낼 수 있고 만약 server가 해킹당한 상황이라면 이때 유저들의 password는 고스란히 해커의 손에 넘어가고 다른 사이트에 적용시켜 유저의 피해가 야기될 수 있기 때문이죠~ 따라서 애초에 password같은 정보는 그 누구도 원문을 알 수 없도록, client에서 빠져나올 때 hash하는 것이 옳다고 생각합니다...ㅎㅎㅎ

[minhoryang]

저희가 전달받은 password는 salt와 pepper가 칠해져 bcrypt로 해슁되어있어요!

• 회원가입 https://github.com/SGCSRelease/AwesomeTitle/blob/master/user.py#L75
• 로그인 https://github.com/SGCSRelease/AwesomeTitle/blob/master/user.py#L160-L163

[taeguk]

@minhoryang 하지만 server측에서 db에 저장하기 전에 hashing하는 거라서 client와 server가 통신할 때 사이에서 패킷을 감청하면 password 원문을 알아낼 수 있어요!

[minhoryang]

그걸 https로 막겠다는거지요! 그래도 안되나요?

[taeguk]

@minhoryang https를 해도 Server가 해킹됐을 경우에는 password 원문이 노출되는 것을 막을 수 없어요 ㅠㅠ https는 'hash'가 아니라 '암호화' 이기 때문에 결국 server에서 복호화가 되는데, 이때 서버가 해킹된 상태이면 해커가 틈새를 노려 password 원문을 빼내갈 수 있죠.. https만으로도 보안이 어느정도 강력해질테지만 제일 완벽한 건, client단에서 javascript로 hashing하는 것 같애요~

[JimJeon]

당신들.... 넘나 멋져요!!!

[minhoryang]

지금 taeguk.reluv.me도 보면 reversed proxy로 .105에서 .104를 바라보게되어있고, .104는 외부에서 접근이 안되니까 괜찮다고생각해요. SQLAlchemy는 SQL Injection을, Jinja2는 XSSInjection을 막아줘요. 한번 이쪽을 시도해봐주세요.

[minhoryang]

지금은 taeguk이랑 같은 linux를 공유하지만, 실서비스시 (나중에는) 당연히 별도의 vm으로 구분되어있을거에요. Https 트래픽도, .105에서 http로 까져서 .104에서 서비스하는게 아니라, .104까지 끝까지 https로 보낼거에요. 진짜 그때는 "서버가해킹됬을때"가 문제가되는거죠.

[minhoryang]

JS해싱은, 사실 더 위험한 방식이라고 생각하는데, 우선 표준이 아니구요. 암호화기법자체를 노출하는거라, 해킹 이후에 콜루젼찾기가 더 쉬워요

[minhoryang]

다른 클라이언트 이식도 힘들구요.

[minhoryang]

JS암호화스크립트를 믿을 수 있는지도 모르겠어요. 적어도 bcrypt는 openssl을 이용하거든요. ssh도 https두요

[minhoryang]

서버를 해킹해서 접근할 수 있다면, 제가 노릴건 해싱이아니라 클라코드수정일거에요.

[minhoryang]

우리사이트뿐만아니라 다른사이트의 정보까지 순순히 뺃어올 수 있는데요 ㅎㅎ

[minhoryang]

http://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side http://stackoverflow.com/questions/3715920/about-password-hashing-system-on-client-side

[taeguk]

음 https를 이용하는 것과 client단에서 javascript hashing하는 것중 어떤게 보안이 뛰어날 지를 비교하려는 것은 아니에요. 단순히 보안 측면에서 지금 코드 < javascript로 password를 hashing하는 것 https < https + javascript로 password를 hashing하는 것 이라고 생각하기 때문에 javascript를 이용해서 password를 hashing하는 게 옳다고 생각해요

[taeguk]

어떻게 보면 99%냐 99.9%냐의 얘기같은데, 서버가 해킹당했을 때 해커가 무엇을 할 지 가연성을 따지는 것을 떠나서, 만약 그것이 user의 raw password를 알아내는 것이라고 가정했을 때, javascript로 hashing을 한 경우가 보안이 더 뛰어날 것이라는 점이에요~ 해커가 레인보우테이블을 이용하든 콜리젼을 찾든 해야할 작업이 더 늘어나기 때문에요..

[juice500ml]

오.. 오오오... 뭐야 여기..

[minhoryang]

음. 우리는 https를 꼭 도입할 거에요. 그래야만해요. 개인정보를 관리하기 때문이에요. 지금은 alpha/beta니까 괜찮은거구요. 나중에 주소록기능을 도입하게 되는 순간, 아니 그보다 전에 https로 넘어갈 거에요.

[minhoryang]

https가 필수이기 때문에, 문제는 'javascript로 password를 hashing하는 것'을 할 필요가 있는가? 로 바뀌어요.

[minhoryang]

"javascript로 hashing을 한 경우가 보안이 더 뛰어날 것이라는 점이에요"

보안이 뛰어나 지지 않아요. 해커가 더 귀찮아지는 것 뿐이지요. 이는 보안이 뛰어나다고 말할 수 없어요. 고로

"어떻게 보면 99%냐 99.9%냐의 얘기같은데,"

가 아니에요.

반대로 우리가 사용한 js라이브러리의 취약점이 밝혀진다고 가정해보면, 그 때는 보안이 무너진거죠. (wordpress나 phpmyadmin처럼 많이 쓰는 곳에 공격이 더 자주 일어나는 이유를 생각해보면되요. github에서 그 라이브러리를 사용하는 곳을 찾은다음, 공격을 시도하면 되죠.)

이렇게되면 99%(해커가 우리의 존재를 아느냐) vs 0%(모르느냐)로 바뀌어요.

https + javascript로 password를 hashing하는 것

이 상황에서는 js라이브러리의 취약점이 공개된다면 https의 노력에도 불구하고, 패스워드는 뚤리게 되는거죠.

[minhoryang]

그러면 다시 생각해봅시다.

[minhoryang]

1. mitm 문제는 https가 해결해 줄 것.
2. perhaps
   • 서버가 뚤리는 것을 걱정하는 것 보다, 신뢰할 수 없는 JS sha512라이브러리를 안쓰는게 더 쉬움.
     • 차라리 https://www.w3.org/TR/WebCryptoAPI/ 를 써요.
     • http://caniuse.com/#search=crypto

[taeguk]

음... 어차피 client <---https---> server 같은 식으로 client(browser)와 server가 통신할때 https를 사용하게 되는 건데, hashing을 하고 안하고의 차이는 client가 server로 넘기는게 raw password 냐 hashed password 냐의 문제기 때문에 만약 js라이브러리가 취약하고 뚫린다고 하더라도 보안성이 hashing을 사용하지 않을 때랑 똑같아 질 뿐이지 더 나빠지진 않아요. https와 hashing이 사용되는 구간이 서로 완전히 다르기 때문에 hashing이 뚫렸다고 하더라도 https가 뚤리지는 않아요.

[minhoryang]

js가 취약해서 뚫리면, http를 바라보지 않고, 클라만 후킹해도, password를 얻을 수 있지 않나요? https는 뚤리지 않죠. 하지만 password는 뚤렸습니다. ㅠㅠ

[minhoryang]

hash(hash(pw))도 의미가 없습니다 ;ㅅ;ㅠ

[minhoryang]

https://crackstation.net/hashing-security.htm

IMPORTANT WARNING:
If you are thinking of writing your own password hashing code, please don't!.
It's too easy to screw up.
No, that cryptography course you took in university doesn't make you exempt from this warning.
This applies to everyone:
DO NOT WRITE YOUR OWN CRYPTO!
The problem of storing passwords has already been solved.
Use either use either phpass, the PHP, C#, Java, and Ruby implementations in defuse/password-hashing, or libsodium.

[taeguk]

음 제가 말하고 싶은 건 https는 클라이언트부터 서버까지 데이터를 안전하게 전송해주는 역할을 하는 건데 결국에 서버에 전송되는게 raw password라는 거죠. 즉, 서버에서 처리되는 동안은 raw password 상태라는 것이고 서버가 안전하다고 해도 굳히 서버에서 유저의 raw password를 알아야 할 필요는 없죠. 그렇기 때문에 그냥 클라에서 서버로 raw password를 전송하지 않고, hash를 한 hashed password를 전송하게 되면 이러한 이슈를 해결할 수 있다는 거죠.

[minhoryang]

"서버에서 유저의 raw password를 알아야 할 필요는 없죠." 이 문제는 의미 있는 문제이죠! 그런데 그렇다고 모르는 js를 들고오면 안됩니다. (작성자가 정말 뛰어난 사람이래도, openssl이나 libsolium, nacl 등이 존재하는 이유는 따로있지요. 털리면 저에게 고지라도 오거든요.)

[taeguk]

password가 필요한 건 단순히 인증 절차일 뿐인데, raw password를 사용할 필요는 없죠. raw password는 다른 사이트들에서도 사용하고 있을 수 있기 때문에 최대한 그 존재가 숨겨져야한다고 생각해요. 그렇기때문에 그냥 javascript로 hashing을 한채로 서버에 전송하는 게 옳다고 생각하는 이유에요.

[minhoryang]

hash(pw)가 콜루젼을 일으키지 않는다는 건 아직도 도전과제이죠. 하지만 hash(hash(pw))가 콜루젼을 일으키지 않는다는 건 위의 주장보다 훨씬 위험한 생각이에요. http://programmers.stackexchange.com/questions/115406/is-it-more-secure-to-hash-a-password-multiple-times

[minhoryang]

[taeguk]

아 제가 그 부분을 간과했네요....ㅠㅠ 음 그런 측면에서는 적용안하는게 날 것 같아요

[minhoryang]

+_+ 정말 순간적으로 공부 많이했습니다. 한수 배웠어요.

[minhoryang]

서버를 믿을 수 없다면, 클라우드 비즈니스는 망해야합니다 .... 그건 자신의 서버도 아니고, 남의 모르는 곳에 있는 서버이며, 심지어 또 쌩판 모르는 사람과 같이 써요.

[minhoryang]

릴리즈서버가 위험하다는 주장은 충분히 가능성 있습니다.

[minhoryang]

사실 나도 위험하게 쓰는데... (사실 위험하길 바람 조금)

[minhoryang]

서버가 해킹되는 것 (openssh/openssl취약점) vs 서버가 해킹되는 것 (일반 사용자의 비번노출)

[minhoryang]

요즘 안그래도 단순 인증절차라는 이야기가 많아서 passwordless라는 운동도 많이 펼쳐지고 있어요 https://passwordless.net/ https://auth0.com/passwordless

이는 sms나 메일기반으로 로그인하자는건데요 (클릭으로 로그인)

[minhoryang]

사실 한국식 (너네과실이야)랑 저는 비슷하다고 생각하는게 조금 있어서. 아직은 판단보류입니다.

[minhoryang]

https 스니핑보다,, 안드로이드 문자 뚫기가 더쉬워요.

[minhoryang]

메일 사이트는 단골 타겟이구요.

[juice500ml]

와우 :+1: for hash(hash())

[taeguk]

그건 그렇죠 ㅋㅋㅋㅋ 저는 단지 raw password는 최대한 보호되어야된다는 생각에 그런 주장을 펼친건데 double hashing collision에 대해서 간과했네요. 처음에 이슈올릴때는 https가 아닌 상황에서 password가 그대로 노출되서 중간자공격에 대한 위험성이 collison문제보다 크다 생각했는데 https를 통해 중간자공격에 대해 방어를 하고 난 상태에서는 server측의 신뢰여부에 대한 위험성이 collision문제 보다 더 크다고는 말할수없을거같아요

[minhoryang]

"서버의 관리자에게 password가 노출 될 것이다"는 실제로 말이 되는 말이라서요. 그래서 요즘은 배포용 서버와 개발용 서버를 따로둡니다. CI (Continuous integration) 이나 CD (Continuous Deploy) 에 대해서도 공부할만해요. 제 요즘 관심사입니다. -> DevOps

우리도 당연히! 이렇게 갈거에요. http://12factor.net/

[taeguk]

음 근데 double hashing 이 정식용어는 아닌거같고... hash(hash()) 이걸 뭐라고 불러야할지 모르겠네요 ㅋㅋㅋㅋ

[minhoryang]

multiple hashing이죠뭐ㅎㅎ

[taeguk]

음 근데 너무 순간적으로 판단을 제가 내린 거 같은데 다시 생각해보니 multiple hashing이 collision에 대해서 더 위험하다는 근거가 있을까요?? http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once

[minhoryang]

음 저도 생각중입니당.

[minhoryang]

단방향함수 두번이라고 생각하니 아니라고 생각이되네요. 잠깐만요.