다 적어놨는데 날라갔다.. 다시 작성하다 보니 다 듣지도 않았고
중간중간 빼먹은 부분이 존재할 수 있다..

[2주차 과제]

• [라이트업 작성 과제]

1. 강의1: 암호학 및 전자서명
   해당 강의 암호학1 강의 재생목록 전채 수강해주시면 됩니다!
   https://www.youtube.com/watch?v=NBrcJSkgYmA&list=PLuHgQVnccGMD-9lk4xmb6EG1XK1OmwC3u&index=1
2. 강의2: 비밀번호 털렸다고? 암호화. 해시함수
   https://youtu.be/67UwxR3ts2E

• [추가 설명 작성 과제]
  세션, 토큰, 쿠키에 대한 설명과 함께 JWT 유저 인증방식 및 보안 문제점
  밑 강의들은 해당 추가 설명에 대해 도움을 줄 수 있는 강의로 필수적으로 수강하실 필요는 없습니다!
  세션 vs 토큰 vs 쿠키 : 노마드 코더
  https://www.youtube.com/watch?v=tosLBcAX1vk
  세션 vs. 토큰! JWT가 뭔가요?
  https://www.youtube.com/watch?v=1QiOXWEbqYQ&list=PLpO7kx5DnyIEXyPYwOk4YFFmtz5yz1v36&index=5

암호학1 - 1. 수업 소개

암호학 crytography : 비밀을 지키는 방법

• 기밀성: 정당한 사용자 만이 데이터의 내용을 파악할 수 있게 함
• 무결성: 수신된 메시지에 불법적인 삽입이나 변조가 있는지 확인할 수 있게 함
• 인증: 권한이 있는 사람만 정보에 접근할 수 있게 함

• 암호화: 암호 알고리즘과 암호 키를 이용하여 평문을 암호문으로 변환

• 복호화: 복호 알고리즘과 복호 키를 이용하여 암호문을 평문으로 변환
  -> 예전에는 암호화 알고리즘을 공개하지 않는 것을 통해 암호화를 달성했지만 현대는 알고리즘을 공개해 검증을 받는 대신, 암호를 만들고 풀 때 key 를 주입한다.

• 양방향 암호화 : 암호화와 복호화를 모두 할 수 있는 암호화 방식. 정보를 감추는 기밀성에 초점이 맞추어 있다.
  양방향은 다시 대칭키와 비대칭키 방식으로 나눠진다. 대칭키는 하나의 키로 암호화와 복호화를 진행하고, 비대칭키는 하나의 키는 암호화를, 다른 하나는 복호화에 사용해 두 개의 키를 사용한다.

• 단방향 암호화 : 암호화는 되는데 복호화는 되지 않는 암호법. 기밀성을 위한 것이 아닌, 무결성을 위한 것이다.

암호학1 - 2. 단방향 암호화 방법

단방향 암호화는 다른 말로는 해쉬라고도 부른다. 데이터를 해쉬하면 이를 원래 방식으로 되돌릴 수 없다. 이는 무결성을 위해 사용된다. 예를 들어, MySQL 등을 다운로드 받을 때, 다운로드 받은 파일을 MD5 암호화한 값과 사이트 상의 MD5 암호화된 값이 같으면 이는 어떤 파일이 조작되었는지 아닌지를 확인하기 위한 무결성을 보장한다고 할 수 있다.

사용 방법

• 무결성 체크
• 전자서명
• 파일의 식별자로써 파일의 해쉬값 사용
• 사용자의 비밀번호를 서버에 안전하게 저장
• 블록체인, 가상화폐, 비트코인 등 채굴을 할 때 작업증명 메커니즘의 해쉬가 사용이 된다.

암호학1 - 3. 양방향 암호화 방식 - 대칭키 방식

평문을 암호문으로 바꿀 때 키를 사용하는데, 이 키를 복호화할 때도 그대로 사용하면 대칭키 방식이 된다. 가장 유명한 대칭키 방식 중 하나는 AES이다. 키의 복잡성은 숫자가 높을 수록 좋지만 컴퓨터의 자원을 더 많이 차지하게 된다.

암호학1 - 4.1. 양방향 암호화 - 비대칭키(공개키 방식) - 기밀성을 위해서 사용하기

나의 암호화된 데이터를 복호화하기 위해서는 키가 필요하다. 인터넷망에서 친구에게 키를 안전하게 전달하려면 어떻게 해야할까?
비대칭키는 암호화하고 싶은 평문이 있을 때, 이를 공개키 방식으로 암호화하기 위해서는 두 개의 키가 필요하다. (key pair) 이 평문을 암호화할 때 공개키로 암호화해 암호문이 만들어지면, 이 공개키로는 암호문을 평문으로 만들 수 없고, 비공개키로만 평문으로 만들 수 있다. 공개키로만 암호화하고 비공개키로만 복호화할 수 있는 게 아닌, 비공개키로도 암호화할 수 있지만 그렇게 되면 공개키로만 복호화할 수 있다. 이렇게 복잡하게 하는 이유는 배달 사고 때문이다. 내가 가진 정보를 특정한 남이 보게 하기 위해서는 키를 전달해야하는데 이 과정에서 도난 당할 수 있다. 이러한 목적으로 비대칭키를 사용한다.

대칭키 방식의 한계
대칭키 방식은 B라는 사람이 A라는 사람에게 암호화된 정보와 키를 전달하려 할 때, 탈취자가 존재한다 가정하자. B라는 사람은 대칭키로 암호화해 암호문을 만들고, A에게 암호문과 키를 함께 전달해야한다. A는 인터넷을 통해 암호문과 키를 전달받지만 동시에 우리가 전달한 정보가 탈취자에게도 노출될 가능성이 매우 높다. A라는 사람도 암호문을 풀 수 있지만 탈취자도 암호문을 풀 수 있게 된다. 이렇게 보안이 뚫릴 수 있음이 대칭키의 치명적인 한계이다.

비대칭키의 이점
B는 자신의 메세지를 A에게 안전하게 보내고 싶다. 이를 감청하고 싶은 크래커가 있을 때, A는 비대칭키를 이용해 공개키와 비공개키 두 개를 만든 후 공개키를 인터넷에 올린다. 이 공개키를 B가 받고, 크래커도 공개키를 받을 것이다. 이 상황에서 B는 자신의 비밀 메세지를 A의 공개키로 암호화한다. 이렇게 생긴 암호문을 공개한다. A와 크래커 모두 암호화된 정보를 얻게 되지만, A는 자신이 가진 비공개키를 이용해 복호화할 수 있지만 크래커는 비공개키를 갖고 있지 않게 되기 때문에 복호화가 불가능하게 된다.

비대칭키에서 가장 유명한 알고리즘은 RSA이다.

암호법1 - 4.2. 양방향 암호화 - 비대칭키(공개키) - 전자 서명하는 방법

우리가 어떤 정보를 받았을 때, 그것이 친구가 작성한 원본인지 크래커가 작성한 조작된 데이터인지 어떻게 하면 알 수 있을까? 비대칭키 혹은 공개키 방식의 암호화하는 방식을 이용해 전자서명 하는 방식을 살펴볼 것이다. A가 작성한 내용이 A가 썼는지를 확신하기 위한 방법으로 전자서명을 작성하는 것이다. A가 key pair를 작성한 후 내용을 작성하기 전에 공개키를 인터넷에 올린다. B는 공개키를 갖게된 상태로 A는 내용을 작성한 후 내용과 내용 뒤에 비공개키를 이용해 암호화된 값을 뒤에 붙이는데, 이 값이 바로 전자서명이다. 그리고 A는 자신이 작성한 내용을 인터넷에 올린다. B는 이 내용을 받아 A가 공개한 공개키로 A의 암호문을 해독한다. 그럼 원래 평문과 공개된 내용을 비교했을 때 두 개의 내용이 같다면 이 내용을 A의 공개키를 갖고 있고 이에 대응하는 비공개키를 갖고 있는 A가 작성했다고 확신할 수 있다.

비밀번호 털렸다고? 암호화. 해시함수. 5분 설명.

비밀번호 패스워드 시스템의 잘못된 예시 중 하나는 그냥 데이터베이스에 비밀번호를 그냥 저장하는 것이다. 이렇게 되면 데이터베이스에 access 권한을 가진 관리자들은 모두 비밀번호를 확인할 수 있게 된다. 어떤 회사들은 비밀번호를 암호화한 후, 유저가 회사에서 주는 Key로 로그인 하는데 암호 해제후 비밀번호가 맞으면 로그인 하고 다시 암호화시킨다. 첫번째보다는 괜찮지만 Key를 잃어버리거나 도난당하면 모든 비밀번호를 다 볼 수 있게 된다. 이 방법도 유저에게 좋은 방법이 아니다. 다른 방법으로는 해쉬 함수를 이용하는 방법이다. 해쉬 함수에서 중요하게 알아야 하는 것 3가지가 있다.

• 첫번째, 해시함수는 동일한 입력값(input)에 대한 동일한 출력값이 갖고 있다. 즉, 입력값이 바뀌지 않으면 출력값도 바뀌지 않는다.
• 두번째, 입력값이 약간만 변경되어도 출력값은 어마무시하게 바뀐다.
• 세번째, 해쉬함수는 항상 같은 방향, 단방향으로만 움직인다. 입력값으로 출력값 도출은 가능하지만, 출력갑으로 입력값 도출은 불가능하다.

레인보우 테이블 : 입력값이 바뀌지 않으면 출력값도 바뀌지 않으니, 해커가 해쉬함수로 암호화된 값을 레인보우 테이블에서 찾아보고 존재한다면 입력값을 찾을 수 있게 된다.
salt : 아주 작은 랜덤 텍스트인데, 유저가 나중에 계정을 만들게 되면 패스워드를 salt와 함께 해쉬한 후 랜덤한 출력값을 갖는다. 그렇게 되면 비밀번호가 심플하더라도 레인보우 테이블에는 존재하지 않게 된다.

추가과제

JWT 세션 VS 토큰!

로그인 상태의 유지되도록 하는 것 또한 만만치 않은 문제. 내가 로그인을 했는데 받은 편지함에 들어갈 때마다 메일을 열어볼 때마다 등에서 일일이 다시 로그인 하면 안된다. 따라서 계정과 관련되어 서버에 프로그래밍 할 때 인증과 인가를 어떻게 할지가 중요한 이슈이다.

• 인증 : authentication 로그인. 내가 사이트가 가입된 회원임을 아이디와 패스워드 등을 통해 인증을 받는 것.
• 인가 : authorization 이렇게 한 번 인증을 받은 사용자가 이후 서비스에 여러 기능들을 사용할 때 내가 로그인 되어 있음을 알아보고 허가 해주는 것. 로그인이 유지가 되어있을 때 일어나는 일들.

어떤 사이트나 서비스에 사용자가 로그인 되어있다는 사실을 서버가 인지하도록 하는 방법이 뭐가 있을까?
웹사이트 상에 이러한 클릭들 하나하나가 다 요청이고 다음 사이트에 서버는 동시다발적으로 들어오는 무수한 사용자의 요청에 응답해주는 것. 서버는 각 요청이 들어올 때마다 이를 보낸 사용자가 로그인 인증 과정을 거쳤는지 확인을 해서 로그인이 필요한 기능들에 허용을 해줄지 말지를 결정해서 응답해야 한다.

Q. 아이디나 비밀번호를 크롬 등에 저장해서 매 요청마다 보내서 로그인 하면?
로그인이라는 건 꽤나 무거운 작업이다. 일단 데이터베이스에 저장된 사용자 계정의 해쉬값 등을 꺼내온 다음, 이것들이 사용자의 암호를 복잡한 알고리즘으로 계산한 값과 일치하는지 확인하는 과정 등을 거쳐야 한다. 그리고 매 요청마다 아이디와 패스워드가 실려 날라다니면 보안상의 문제도 있다.

• 세션 : 사용자가 로그인에 성공하면 세션 표딱지를 생성해 찢어서 반쪽은 사용자 브라우저에 보내고 반쪽은 자신의 책상, 메모리에 올려놓는다. 경우에 따라서는 서랍, 하드디스크에 넣거나 창고, 데이터베이스에 넣어놓기도 한다. 그럼 표 반쪽을 받은 사용자의 브라우저가 이 표를 session id라는 이름의 쿠키로 저장하고 이 브라우저는 다음 사이트에 요청을 보낼 때마다 이 표딱지를 실어서 보낸다. 이렇게 session id를 사용해서 어떤 사용자가 서버에 로그인 되어있음이 지속되는 상태를 session이라고 한다. -> 단점: 사용자가 동시에 많이 접속하면 메모리가 부족해지고, 메모리는 서버에 문제가 있어 꺼져버리면 휘발성이라 다 날라가버린다. 또한 규모가 커서 서버가 분산되어 로드바란싱 해있으면 로그인과 이메일 요청이 다른 서버에서 이루어지면 제대로 세션 유지가 안된다. 그렇다고 할당된 서버로만 분산하는 것도 까다롭다. 속도가 느려지지만 데이터베이스에 넣어두거나 레디스나 mencashed 같은 메모리형 데이터베이스 서버에 두기도 한다. 이것도 리스크가 있긴 하다.
• token : JWT를 사용하는 서비스에는 사용자가 로그인을 하면 토큰이라는 표를 출력해 건내준다. 서버가 무언가를 기억하지 않고 있다. 토큰은 인코딩, 암호화된 3가지 데이터를 이어붙인 것이다. 각각 header, payload, verify signature로 구분된다. 페이로드는 base64로 디코딩해보면 json 형식으로 여러 정보들이 들어있다. 이 토큰들을 누가 누구에게 발급했는지, 이 토큰이 언제까지 유효한지 그리고 서비스가 사용자에게 토큰으로 공개하기 원하는 내용을 담을 수 있다. 이렇게 토큰에 담긴 사용자 정보등의 데이터를 claim이라고 한다. 이게 그 이후 요청들마다 사용자로부터 서버에 보내진다. 사용자가 받아서 가지고 있는 토큰 자체에 이런 정보가 들어있으면 서버가 요청마다 일일이 데이터베이스에서 뒤져봐야 하는 것은 줄어든다. 특별한 암호화도 아니고 base64로 인코딩되어 있으면 디코딩해서 볼 수 있고 조작해 악용도 가능하다. 그래서 헤더와 서명이 존재한다. 헤더에는 토큰의 타입이 들어간다. type은 jwt이다. 다른 하나는 alg 알고리즘의 약자인데 서명을 만드는데 사용될 암호화 알고리즘이 사용된다. 헤더와 페이로드, 그리고 서버에 감쳐놓은 비밀값 이 셋을 암호화 알고리즘에 넣고 돌리면 서명값이 나오게 된다. -> 단점: 세션처럼 stateful해서 모든 사용자를 기억한다면 제어할 수 있지만 (ex. 핸드폰 로그인 시 pc 로그아웃), 이미 준 토큰을 뺏을 수도 없고 서버가 추적하지도 않아 제어가 불가능하고 탈취 당할 시 무효화할 방법도 없다. 따라서 만료시간을 가깝게 받아 토큰 수명을 짧게 하는 access token과 refresh token을 나누어 발급하기도 한다. access token과 refresh token을 발급하고 클라이언트에게 보내고 나서 refresh token은 상응값을 데이터베이스에도 저장한다. 손님은 access token의 수명이 다하면 refresh token을 보낸다. 서버는 데이터베이스의 값과 대조해보고 맞다면 새로운 access token을 발급해준다.