내일배움캠프 25일차 기록

해싱(hashing)

원본 문자열을 알아볼 수 없도록 난해한 문자열로 정의하는 방법 회원가입 할때 사용한 비밀번호는 중요한 개인정보이기 때문에 원본 문자열을 알아볼 수 없도록 해싱한 후에 DB에 보관한다.

 

hashlib

해쉬 함수 라이브러리

 

SHA256

보안 해쉬 알고리즘 256 비트를 나타내는 것으로 2의 256 제곱의 수많큼 경우의 수가 만들어 지기 때문에 무차별 대입 공격에 매우 안전하다고 볼 수 있음.

    password_receive = request.form['password_give']
    password_hash = hashlib.sha256(password_receive.encode('utf-8')).hexdigest()

파이썬 hashlib 라이브러리를 사용해서 password_receive 라는 변수에 request.form['password_give'] 로 받은 값을 

password_hash 변수에 해싱해서 넣는 예시. 사용 전에 꼭 import hashlib 을 해줘야 작동한다.

 

bulma

Flexbox 기반의 무료 오픈소스 CSS 프레임워크. JS없이 오직 CSS만을 사용하기 때문에 엄청 가볍고 CSS3의 최신 기술들을 사용하기 때문에 상황에 따라 굉장히 편리하다. 다만 JS가 없기 때문에 역동적인 화면을 구성하는데는 제약이 있으며, 구형 브라우저에서는 호환이 완벽하게 되지 않는 단점이 있다.

 

인증방식 (github issue에 작성)

1. 계정 정보를 요청 헤더에 넣는 방식

HTTP 요청에 인증할 수단에 비밀번호를 넣는 방식. 데이터를 요청할 때마다 private 정보를 계속 보내기 때문에 보안에 취약
서버에서 신호가 올 때마다 ID,PW를 통하여 USER가 맞는지 인증해야 하기 때문에 굉장히 비효율적
보안에 굉장히 취약하고 비효율적이기 때문에 테스트 단계를 제외하고는 절대 사용하지 않는 방식

2. Session / Cookies 방식

사용자가 로그인을 하면 서버에서는 사용자 정보를 DB에서 확인하고, 고유한 ID를 부여하여 session 저장소에 저장한다
저장소에 저장된 값과 연결되는 session ID를 response에 넘겨주면 유저는 session ID 를 cookie에 저장을 하게 된다
인증이 필요할 때마다 사용자는 cookie를 헤더에 포함해서 정보를 보내주고, 서버에서는 쿠키를 받아 session 저장소에서 검증한 후, 대응되는 정보를 찾아서 맞는 데이터를 보내준다
혹여나 cookie가 담긴 HTTP 요청이 도중에 노출된다 하더라도 담겨있는 session ID는 유의미한 값이 아니기 때문에 보안에 유리한 부분이 있으며, 사용자마자 고유한 ID 값을 부여받기 때문에 바로 어떤 사용자인지 파악할 수 있다.
서버에서 session 저장소를 사용하기 때문에 추가적인 저장공간이 필요하며, 요청이 많을수록 부하가 심해진다
HTTP 요청을 중간에서 누군가 가로채서 가로챈 cookie를 이용해 HTTP 요청을 보내면 session 저장소에서는 가로챈 사람에게 정보를 잘못 전달할 수 있다 (session hijacking) / HTTPS를 사용해서 방지할 수 있다

3. JWT 방식 (json web token)

JWT는 인증에 필요한 정보들을 암호화 한 토큰을 의미하며, 토큰을 만들때 header, payload, verify signature 3가지가 필요하다
header : 암호화할 방식(alg) , 타입(JWT)
payload : 서버에서 보낼 데이터 ( 일반적으로 사용자 고유 ID, 토큰의 유효기간 등이 들어간다 )
verify signature : base64 방식으로 인코딩한 header,payload,SECRET KEY 를 더한 후 서명
header, payload 는 인코딩만 되고 암호화는 안되기 때문에 사용자의 중요한 정보(PW 등)가 삽입되면 쉽게 노출이 될 수 있다
verify signature는 SECRET KEY를 알지 못하면 복호화 할 수 없다

JWT는 session / cookies 방식과 달리 발급 후 검증만 하기 때문에 별도의 저장소가 필요하지 않다는 장점이 있으며, 토큰 인증 기반인 다른 인증 시스템에 접근을 할 수 있는 확장성이 좋지만 한번 발급된 토큰은 유효기간이 완료될 때 까지 계속 사용을 할 수 있기 때문에 악의적으로 발급받은 사람이 유효기간 끝날때까지 계속 사용할 수도 있으며 session / cookies 방식에 비해서 길이가 길기 때문에 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생한다는 단점을 가지고 있다.