아하
생활

생활꿀팁

향기로운여치125
향기로운여치125

암호화, 어디서 하는 것이 효율적일까요?

여태 별 생각없이 회원가입폼은

HTTPS 로 보안통신을 하고
암호는 서버로 평문을 전송하고
서버에서 암호화 한 뒤에 DB에 저장했는데요...

오늘 문득 든 생각이
패스워드 암호화는 과연...
클라이언트에서 해서 보내는게 맞을까?
서버에서 암호화하고 저장하는게 맞을까?
라는 생각이 들더군요...

다들 패스워드 암호화... 어디서 하는 것이 효율적일까요?

물론 클라이언트에서 암호화하고, 또 한번 DB에서 암호화할 수도 있지만 클라이언트에서 하는 건

어차피 해킹에 상당히 취약하기에 다 뚫린다고 보면 굳이 암호화할 필요가 있나 싶기도 하구요.

둘다 하는게 효율적일까요?

아니면 그냥 DB에서만??

55글자 더 채워주세요.
5개의 답변이 있어요!
  • 참신한청설모65
    참신한청설모65

    일단 클라이언트에서 무언가를 한다는 것 자체가 안전하지 않다고 생각하시는 게 좋습니다.

    말 그대로 클라이언트에게 권한이 있기 때문이죠.

    클라이언트에서 평문으로 서버로 보내는 건 https 프로토콜을 사용한다면 굉장히 일반적인 경우이구요, 기존 하시던 방식대로 서버에서 암호화를 하는 것도 일반적입니다.

    서버랑 DB를 클라우드에 올려서 사용하신다면 클라우드 보안을 신경 써주시는 게 맞습니다.

    추가로 비밀번호 관리에 대한 사견인데, 저는 DB user 테이블에 password 칼럼을 두지 않고 그냥 OAuth로만 처리하고 있습니다.

    비밀번호를 서버에서 관리 한다는 것 자체로 취약성이 생기고, 유저가 까먹으면 비밀번호 찾기 기능이 요구됨 등 기술적, UX 측면에서 애로사항이 많기 때문입니다.

  • "물론 클라이언트에서 암호화하고, 또 한번 DB에서 암호화할 수도 있지만 클라이언트에서 하는 건

    어차피 해킹에 상당히 취약하기에 다 뚫린다고 보면 굳이 암호화할 필요가 있나 싶기도 하구요."

    >> 굉장히 많은 메이저 회사들이 여러가지 이유로 이중 암호화를 진행하고있습니다.

    클라이언트 암호화는 서버자원이 아니고 단순한 pw 등은 암호화 하는데 큰 자원소비가 필요하지도 않기때문에 별 부담없이 진행이 가능하여 많이들 쓰는편입니다.

    평문전송시 노출이나 기타 위험도를 감수하는것보다 암호화를 한번 더 하는게 오히려 편하기 때문인 경우도 많고...

    다만 말씀하신것처럼 효율적인건 백엔드에서 서버가 1회만 처리하는게 맞고.

    보안적으로는 무조건적으로 서버에서는 일단 1회 하는게 맞습니다.

    고로 효율적인건 서버 1회만.

    보안적으로는 서버 1회 + 클라이언트 1회 하셔도 무방합니다.

    다만 클라이언트 1회는 https 통신중에는 사실 큰 의미가 없어보입니다.

  • 금융권 개인정보에 대한 컴플라이언스 사례로 보면,

    DMZ 구간의 대국민 서비스(예를 들어, 대표메인홈페이지 등)같은 경우 각 구간별 암호화를 하도록 지침이 있는 것으로 알고 있습니다. (질문자께서 문의하신 패스워드도 아주 중요한 정보죠..)

    인프라적으로는 망분리(DB존 같은)를 해놓고, 웹구간에서는 SSL 또는 웹구간 암호화 솔루션을 통한 구간암호화를 처리, 서버 내 개인정보 경우 비정형암호화(로그 등), DB 데이터 경우 정형암호화 까지 할 수 있도록 지침이 내려옵니다.

    보통 암호화 대상은 전송전 암호화 하고 전송을 하는 구조로 구현을 하시는 게 맞을 듯 합니다.

    보안 영역이라는 것이 취약포인트가 있다면 모두 다 하는 것이... 효율적일 순 없겠으나, 보안사고는 발생하지 않는 것이 가장 좋겠죠.

  • HTTPS로 보안 통신을 할 때는 HTTPS로 전송할 데이터를 암호화하는 것은 무의미합니다.

    서버에서만 암호화해도 충분합니다.

    ※ 브라우저에서 암호화를 하는 게 의미가 있는 경우도 있습니다.
    이상한 브라우저를 사용하는 경우 (브라우저가 전송되는 데이터를 빼돌리는 경우)
    이상한 인증서를 신뢰하도록 설정된 경우 (중간자 공격이 가능)가 있는데요
    이 경우에는 보안에 이미 구멍이 뚫린 후(...)이기 때문에 의미 있다고 보기 어렵습니다.

  • 일단 제 기준으로 보면

    클라이언트 - 서버사이드 - 백엔드

    모두 다하는 게 좋을 것 같습니다.

    클라이언트에서 서버사이드로 넘어가는 단계에서 와이어샤크 등 얼마든지 파라미터를 추출할 수있는 수단이 있기 때문에 안심할 수없다고 보면 됩니다.

    저같은 경우에는클라이언트 에서 RSA로 암호화를 해서 서버사이드에서 복호화 한구 다시 패스워드 encrypt 해서 DB에 전송합니다.