TIL 55- Authentication Checkpoint

1. 해시 함수

• SHA-256 알고리즘을 사용했을 경우 출력값의 길이는 언제나 동일하다

→ SHA-256 알고리즘을 사용했을 경우 출력값의 길이는 입력값의 길이와 관계없이 언제나 256비트(64 글자)다.

• 해시 알고리즘은 특정 입력값에 대해 항상 같은 해시값을 리턴한다.

→ 이 점을 이용해서 인증을 할 수 있는 것이다. 어떤 입력값인지는 모르지만 해시 함수를 이용해서 해시된 값이 일치하다면 입력값이 같다는 것을 입증할 수 있다.

• 해싱 알고리즘은 해독이 거의 불가능하지만 아예 불가능하진 않다

→ 현실적으로는 시간이 오래 걸려 불가능하지만, 수학적으로는 가능하다. MD5는 일반적인 컴퓨터를 이용하여 2013년도에 20시간을 들여 90% 이상을 해독하는 데 성공했다.

2. 쿠키

• 쿠키가 삭제되는 경우: MaxAge 또는 Expires 옵션이 설정되는 쿠키의 경우 설정된 시간이 지난 이후 자동으로 제거한다. 해당 옵션이 없는 경우, 대부분의 브라우저에서는 쿠키를 지우지 않으므로, 쿠키는 보존된다. (참고: mdn의 "세션 쿠키" 설명과는 다르게, 현대의 브라우저는 쿠키를 지우지 않는 것이 기본 옵션.)
• httpOnly 옵션을 사용하면 자바스크립트를 이용해서 쿠키에 접근할 수 없다.
• sameSite=none은 모든 요청에 대해 쿠키를 주고받을 수 있지만 Secure 옵션, 즉 HTTPS 프로토콜을 사용하는 것이 필수적

3. 쿠키 옵션

domain - 서버와 요청의 도메인이 일치하는 경우 쿠키 전송

path - 서버의 요청의 세부 경로가 일치하는 경우 쿠키 전송

maxage/expires - 쿠키 유효기간 설정

httpOnly - 스크립트의 쿠키 접근 가능 여부 설정

secure - HTTPS 에서만 쿠키 전송 여부 설정

sameSite - 같은 사이트에서만 쿠키를 사용할 수 있게 하는 설정

      Lax: 사이트가 서로 달라도, GET 요청이라면 쿠키 전송 가능
      Strict: 사이트가 서로 다르면, 쿠키 전송 불가능
      None: 사이트가 달라도, 모든(GET, POST, PUT 등) 요청에 대해 쿠키 전송 가능
   

4. session 기반 인증 방식

• 하나의 서버에서만 접속 상태를 저장
  여러 개의 서버에서 같은 세션 데이터에 접근하려고 한다면 session clustering 혹은 공통 session store를 사용해야 하는 번거로움이 있다. (불가능한 건 아니다)
• 여러 개의 서버를 가지고 있을 때 유리한 건 token 기반 인증 방식

5. CSRF

• cross site request forgery
• 사용자가 보내는 요청을 다른 사이트(origin이 아님)에서 위조하는 것
• 기존의 로그인한 기록을 바탕으로 서버가 클라이언트의 요청을 믿기 때문에 발생한다.
• 쿠키 방식의 인증을 사용하는 곳에서 사용 가능. sameSite: 'none'말고 다른걸로 사용하면, 서버는 클라이언트에 따라 신뢰할 수 있는 요청인지 아닌지를 판단할 수 있으므로, CSRF 공격을 방지할 수 있다.
• 해커는 GET에서 parameter를 바꾸어 변조된 요청을 보내게 할 수 있으며, POST의 경우도 쿼리 문자열 (x- www-form-urlencoded) 변조가 가능하므로 공격할 수 있다. Cross origin의 경우 CORS 설정은 CSRF를 막는 데 도움을 줄 수 있다.

6. session 기반 인증 대신 token 기반 인증 ?

• session은 유저가 많으면 성능이 떨어짐 (세션 기반 인증은 서버(혹은 DB 통합)에 유저에 대한 정보를 저장하고 있다. 즉 메모리 공간을 서버 쪽에서 차지하고 있고, 자원을 사용하고 있기 때문)
• token은 서버의 부담을 덜어줄 수 있음
• token은 여러 개의 서버를 사용하는 서비스를 운영할 때 유리
• 어느 한쪽이 더 안전한 인증 방식이라고는 얘기할 수 없지만, 앱의 확장을 고려한다면(여러 개의 서버를 사용하며 점점 커져가는 앱이라면), token 기반 인증 사용