TIL_20.06.17(수)~20.06.19(금)

20.06.17(수) - Cookie, Session, Hash, Token

하나의 서버에 여러 브라우저에서 접근할 땐?? 어떻게 판별해야 할까

hashing(hash string)
어떠한 문자열에 임의의 연산을 적용 시켜 다른 문자열을 변환하는 것
주로 hashing은 서버 로직 내에서 이루어지며 상대적으로 정보가 노출되기 쉬운 클라이언트 상에서의 보안을 신경쓰기 위해 사용된다.

1. 모든 값에 대해 해시 값을 계산해야 하는데 오래 걸리지 않아야 한다.
2. 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
3. 아주 작은 단위의 변경 이라도 완전히 다른 해시 값을 가져야 한다.

+)Salt
해시 하려는 값(원본)에 추가하는 값
1. 암호화를 진행 했다면 ‘해당 알고리즘을 알고 있는 순간’바로 원본을 얻어낼 수 있음
2. 원본 값에 임의로 약속된 추가 문자열을 추가하여 해시를 진행하여 기존 해시값과 전혀 다른 해시 값이 반환되어 알고이즘이 노출되더라도 원본 값을 보호할 수 있도록 하는 안전장치
3.
기존: (암호화하려는 값)=>(hash값)
Salt 사용: (암호화 하려는 값)+(Salit용 값) => (hash 값)
유저마다 솔트를 다르게 지정해 준다.

hashing과 salut를 할 때, node js안에 내장되어있는 암호화 모듈인 Crypto를 사용

const crypto = require('crypto');


const secret = 'abcdefg';
const hash = crypto.createHmac('sha256', secret) //알고리즘 방식, Salt
                   .update('I love cupcakes’) // hasing 할 값
                   .digest('hex’); //인코딩 방식
console.log(hash);
// Prints:
//   c0fa1bc00531bd78ef38c628449c5102aeabd49b5dc3a2a516ea6ea959d6658e

Session??, Cookie??

일정 시간 동안 동일한 사용자에 대해 상태정보를 유지시키는 것
방문자(브라우저)가 웹 서버에 접속하면 요구에 따른 정보를 저장하는 것

Cookie
Cookie 사용자의 정보를 사용자 메모리(브라우저)에서 관리한다.
서버가 사용자의 위치에 정보를 저장하고 불러올 수 있는 수단
1. 특정 호스트에서 생성된 쿠키는 이후 모든 요청마다 서버로 다시 전송
2. 이름, 값, 만료날짜, 경로 정보로 구성
서버가 cookie를 담아서 요청. Key와 Value의 형태로

Session
사용자의 정보를 사용자 쪽이 아닌 서버 상에서 관리(저장)한다.
서버와 클라이언트의 연결이 활성화 된 상태
1. 서버가 Client에 대해 유일한 ID를 부여하여 서버 측에서 관리
2. 일반적으로 이 유일한 Client ID가 서버에 존재하는 상황을 Session이라고 칭함
3. 각 Client 의 ID는 Session 객체마다 Data를 관리 할 수 있음
4. 사용자의 정보 중 보안 상 중요한 데이터는 Session에서 관리

Token
인증을 위해 사용되는 암호화 된 문자열

1. Http 통신의 Stateless 특징과 알맞다
2. 유저의 인증 정보를 서버나 세션에 담아두지 않음
3. 유저의 활성화 여부를 신경쓰지 않고 넘겨진 요청에 담겨진 Token의 정합성만을 확인
4. 서버에서 클라이언트의 상태정보를 저장하지 않고 클라이언트에서 넘겨지는 요청만으로 작업을 처리하게 되는데 이런 경우 클라이언트 상태 관리에 관한 비용이 없기 때문에 서버의 확장성이 높음

순서??: 클라이언트에서 리퀘스트 발생-> 서버에서는 쎄션토큰을 생성하고 리스폰스와 함께 쿠키를 보내는데 그 쿠키에 토큰이 설정되어있음-> 클라이언트가 또 리퀘스트를 보낼때 그 쿠키(세션토큰이 들어가 있는)와 함께 전달하면 -> 서버는 토큰 정보를 검증하고 일치 하면 리스폰스를 보내는 순서

20.06.17(목) - sprint 진행 1, 개념 정리

sprint 진행 1

Refenrece

• https://github.com/sequelize/cli
• https://sequelize.org/master/manual/migrations.html

레퍼런스를 참고하여 sequelize-cli(mirgation)로 table 생성하기

1. npx sequelize db:create
2. npx sequelize db:migrate

config/config.js파일로 데이터 베이스 생성

세개의 테이블이 생성

파일 구조 파악하기

개념 정리

• 세션 정보는 클라이언트/서버 양쪽에 유지가 된다. -> 클라/서버 연결이 활성화 된 상태 자체

• 클라이언트 자발적으로 발급되는 세션 id는 set-cookie 속성에 담긴다. 응답으로 담긴다.

• 세션은 쿠키의 단점을 보완하나 완전히 별개의 개념은 아니다. 차이점은 세션은 클라/서버 둘다 저장되어 있고 쿠키는 클라에만 저장되어 있음

• 토큰은 단순히 세션에 존재하는지 확인 할 때 사용된다.

20.06.18(목) - sprint 진행 2, AWS 계정 생성

models 폴더에 db를 설정할 때, hooks를 통해 user가 패스워드를 보냈을 때, 해싱한다.

 hooks: {
        //암호화하는 방법
        //afterValidate 유효성 검사 후 실행되는 후크 
        afterValidate: (data,option)=>{
          var shasum = crypto.createHash('sha1');
                  shasum.update(data.password);
                  data.password = shasum.digest('hex');
        }
      }

라우팅에 따라, 기능을 분리한 파일을 모두 작성하기

유저의 세션을 이용하기...
계정 등록하기... 등등

signup과 signin은 어떻게 구현 했지만, ㅜㅜ 아직 미완성이 부분이 많아서 주말 내에 최종적으로 완성시켜야 할 듯 하다.

주말에 진행

• 세션 쿠키에 대한 개념 - SOS 문서를 살펴서 공부하기
• 다음주에 있을 마지막 테스트 대비하기
• 전 페어 분이랑 스프린트 계속 진행하기