무아 2018-04

만약 서버가 해킹되어 SSL연결 -> 값받음. 이 값을 해킹하면 어떻게 될까요?
서버가 해킹될리 만무하다면 굳이 암호화 해서 DB 저장할 필요도 없겠죠.

고재선 2018-04

원래는 그것 때문에 SSL 을 사용하는데요
요새 구글에 자바스크립트 암호화 라고 하면 서버에서 공개키를 받아 자바스크립트 암호화하여 전송하는 예제가 있습니다.

그걸 참고해 보세요

봄들판에서다 2018-04

Ssl 즉 https 는 전송구간을 위한것입니다.

DAP박인호 2018-04

별 문제 없어 보임니다.
단 비밀번호 암호화 방식은
단방향 이면 됩니다.

컴박 2018-04

넵 감사합니다.

무아 2018-04

문제가 있는 것 아닌가요?
SSL 로 연결되었다면 그 중간에 패킷을 훔쳐서 까보는 해킹에는 강하지만 연결된 서버단에서 그 내용을 복호화 하기에 서버단에서 해킹을 하면 도루묵이죠.
만약에 서버 관리자가 악의적으로 소스코드상에 db 암호화 이전에 데이터를 복사해버리면 어떻게 되나요?

즉 모든 사용자의 숨겨야할 입력 정보가 내 PC를 떠난 후에는 한 순간이라도 평문으로 존재해선 안되죠.

Dreaday 2018-04

보안연결할때 rsaa방식을 사용하구요
일반적인 로그인 회원가입땐 서서버 submit시엔 별도 암호화없습니다.

이무사이트나 회원가입할때 F12 개발자모드 네트워크에서 해당 url. 캡쳐해서 request정보보시면 아실것같습니다.

무아 2018-04

뭔가 잘 이해가 안가지만.. 문제는 없는 건가 보군요.
그렇다면 굳이  DB 에 넣기전에 서버에서 다시 암호화 할 필요가 있을까요?

송주환 2018-04

단방향 해시가 충분히 암호화의 역할을 수행할 수 있습니다. 비가역적이니까요.
서버의 권한을 탈취당할 정도라면 다른 어떤 방법으로든 정보를 탈취할 수 있으니 무의미하죠..

어차피 DB에 저장되는 데이터도 plain text + salt를 해시로 바꾼 것입니다.

무아 2018-04

>> 단방향 해시가 충분히 암호화의 역할을 수행할 수 있습니다.
이 말씀이 클라이언트 PC에서 해시를 한다는 말씀이죠?
이미 해시 암호화 된 데이터가 SSL 로 전송되는 것이니까 안전한 것이고 서버측에서 별도로 암호화할 필요없다는 거 아닌가 싶어서 입니다.
그게 아니라면 서버 권한이 탈취되지 않아도 비양심적인 서버 관리자가 사용자의 암호 원문을 고스란히 가져갈 수 있으니까요.
그 얘기 였습니다.
회원 가입페이지 -> 암호화 -> SSL -> 값받음 -> DB 구성이 되어있는 상태죠.

리플을 읽어보면.. 제가 뭔가 잘못알고 있는 것인지요?
같은 얘기를 하고 있는데 같은 얘기를 하면서 아니라고 하는 것 같아서 더 해깔리네요.

송주환 2018-04

그건 구현에 따라 다릅니다. 대형 포털(ex.네이버) 같은 경우는 MITM 공격에도 대응할 수 있도록 클라이언트단에서 RSA로 암호화합니다. 서버 측에서 salt를 클라이언트로 던져주고 암호화한 뒤 해시를 전송할 수도 있겠죠.

무아 2018-04

네 감사합니다.
대략적으로 어떤 점이 다른지 알겠습니다.
구현 방법에 따라 보안 레벨의 차이가 확연하게 나는 것이군요.

꼴통황진우 2018-04

텍스트 입력  -> 암호화 ->( 전송 ) -> db저장

Dreaday 2018-04

해쉬방식 sha. md5. 로. 서버에 저장하시면 문제없습니다.

ssl은 어디까지나 구간암호화입니다.(통신)

이지영 2018-04

현업 기준으로,
로그인창은 SSL 적용.
해쉬는 SHA2 권고. SHA1은 미사용 권고. MD5는 사용시에 취약 프로토콜로 결함에 걸립니다.
트래픽 떴을때 , 가입자가 submit 하는 시점에서 네트워크에서 평문으로 캡쳐되면 결함입니다.

Dreaday 2018-04

저도 현업인데요

SSLL은 어디까지나 권고입니다

리얼홀릭 2018-04

스니핑 당하는 pc 문제까지도 지켜줘야하려나요? ㅎㅎ
구간전송중 스니핑 당하는것도 불법 사항이 되나요? ㅎㅎ
서버만 잘 지키면 될텐데용
SSL 의무업체들은 기준이 있어요 모두 지키지 않아도됩니다.