[TIL] 인증/보안 - https, hashing, cookies, session

Today I Learned

HTTPS

• HTTPS + Secure

HTTP의 특징

• 기밀성 Privacy : 제3자가 중간에 메시지를 열어도 암호화되어있어 읽을 수 없음
• 무결성 Integrity : 메시지가 목적지로 가는 도중 제3자에 의해 조작되지 않고 원본 그대로 도착함

대칭키와 비대칭키

• 대칭키 : 암호화키와 복호화키가 동일하다
• 비대칭키 : 암호화키와 복호화키가 서로 다르다. 한쪽을 공개키로, 다른한쪽을 비공개키(개인키)로 한다. 어느쪽으로 암호화/복호화할지는 어디에 중점을 두느냐에 따라 달라지게 된다. 데이터보안에 중점을 둔다면 공개키로 암호화를, 인증과정에 중점을 둔다면 비공개키로 암호화를 할 수 있다.

인증서

• 인증서는 브라우저에서 접속한 서버가 의도한 서버임을 보장한다.
  - 브라우저는 주요 CA의 리스트와 공개키를 이미 보유하있는 상태에서 서버의 인증서 요청을 검증한다. 리스트에 없는 CA의 경우 외부 인터넷에서 CA 정보와 공개키를 확보한다.
• 인증서는 브라우저와 서버가 통신할 때 암호화할 수 있도록 서버의 공개키를 제공한다.
• 브라우저 주소창 왼쪽 자물쇠 모양을 클릭하면 인증서를 확인할 수 있다.
• 인증서는 CA(Certificate Authority)에서 발급받는다.
• CA로는 DigiCert 등이 유명하며 Let's Encrypt는 비영리기관으로 무료로 인증서를 발급받을 수 있다.

Hashing & Salt

Hashing

• 입력받은 문자열(길이는 가변적)을 알아볼 수 없도록 고정된 길이의 다른 문자열로 변환하는 것
• 해시함수는 인풋과 아웃풋이 항상 동일한 순수함수다.
  - 1234, 0000 같은 자주사용 되는 비밀번호를 사용하면 안되는 이유 : 이와 매칭되는 해싱된 값을 저장한 레인보우테이블이 존재하기 때문에 해킹이 쉽다
  • 그 외의 경우 해싱된 값으로 복호화하는 것은 사실상 불가능하다. (해싱함수는 단방향으로 역변환이 불가)
• 해시함수의 연산은 오래걸리지 않아야 한다.
• 해싱함수는 최대한 모든 값이 서로 다른 해시 값을 가지도록 해야 한다.
• 더 안전하게 하려면 해싱을 여러번 할 수도 있다.
• 널리 알려진 해시함수 : SHA-1, SHA-256, SHA-512 (최소 SHA-256 이상을 쓸 것을 권장)

Salt

• 결과를 변형하기 위해 암호화할 원본 문자열에 추가하는 별도의 문자열
  - input : 1234 (원본) -> hashing -> output : 7110eda...
  • input : 1234 (원본) + @salt (솔트) -> hashing -> 3f36929...
• 솔트를 사용하면 알고리즘이 노출되어도 원본값을 보호할 수 있음
• 사용자와 비밀번호 별로 유일한 값을 가져야 하며 재사용해서는 안된다
• DB 사용자 테이블에 해싱된 패스워드값과 솔트값을 함께 저장하여 검증시 사용한다
• 요즘은 보안상의 이유로 비밀번호 원본을 DB에 저장하는 것이 아니라 해싱된 비밀번호를 저장하기 때문에 비밀번호 찾기를 하면 새 비밀번호를 지정하게 된다. (DB도 내 원래 비밀번호를 모르기 때문)

Cookies

• 쿠키는 HTTPS의 stateless 특징을 보완한다.
  - Stateless : 각각의 요청은 서로 독립적. 이전 상태를 기억하지 않음.
• 쿠키에 저장된 정보를 통해 이전 상태를 알 수 있게 되어 독립된 요청들을 연결할 수 있다.
• 쿠키 정보는 클라이언트에서 열어볼 수 있기때문에 보안으로 활용할 수 없다.
  - 개발자 도구 -> Application -> Cookies
  • 토큰을 사용할 땐 쿠키에 저장하지만 암호화된 형태로 저장하기 때문에 보안에 사용할 수 있다.
• 서버는 응답 헤더 (set-cookie) 를 통해 브라우저에 일방적으로 쿠키를 저장할 수 있다. 하지만 요즘은 법적으로 쿠키 설정 허용 메시지를 띄우도록 강제하는 추세.

Cookie는 어디에 사용할까

• 로그인 안한 상태에서 장바구니에 아이템 저장
• 오늘 하루 동안 보지 않기 / 7일 동안 보지 않기 등
• 로그인 상태 유지
• 타겟형 광고를 위한 데이터 저장
• 인증 상태 저장
• cf. Theme은 쿠키보다는 Redux같은 상태관리를 사용

Cookie 옵션

• httpOnly : 웹 서버를 통해서만 쿠키 접근 가능 (스크립트로 접근 차단)
• secure : HTTPS 통신일 경우만 쿠키를 서버로 전송
• sameSite : 디폴트는 Lax('20.02.04 크롬 v80 기준)
  - strict : 사이트가 서로 다르면 쿠키 전송 불가
  • lax : 사이트가 서로 달라도 GET요청은 쿠키 전송 가능
  • none : 사이트가 달라도 모든 요청에 쿠키 전송 가능 (비추천, CSRF에 취약)
    - sameSite가 none일 때, secure는 항상 true여야 함 (HTTPS에서만 쓸 수 있음)
• expires : 만료 날짜 (GMT) / maxAge : 쿠키 수명 (ms)
• path : 해당 디렉토리 + 하위 디렉토리에서만 쿠키 활성화
• domain : 쿠키가 활성화될 도메인

Session

• 컴퓨터와 사용자 간의 대화 / 송수신 연결 상태
• 연결이 되면 (인증 성공 시) 브라우저와 서버가 서로 session id를 가지고 있고 이를 비교하여 사용한다.