인증authentication 인가 authorization

룰루팍 Lolo Park ·2022년 11월 29일

룰루 인증/인가 정복기

목록 보기

1/6

[Key Word]

인증
인가
고유식별번호
암호화
HASHING
SALTING
KEY STRETCHING

사용자를 판단하고 (인증 authentication)
사용자에게 권한을 부여한다(인가 authorization)

SFA(Single Factor Authentication)
2FA(Two Factor Authentication)
MFA(Multi Factor Authentication)

▲인증요소의 분류와 관련된 개념

지식기반요소:based on 특정인이 알고 있는 정보(비밀번호같은)
소유기반요소:based on 특정인이 소유하고 있는 물건(OTP,휴대폰인증,공인인증서인증)
속성기반요소:based on 특정인의 고유 속성(지문,홍채인식)

SFA는 비밀번호 하나만 사용하는 경우
2FA는 비밀번호+휴대폰인증 사용하는 경우
MFA는 비밀번호+휴대폰인증+그림찾기 뭐 이런거 아닐까?

인증 : 식별 혹은 신원확인
server로 하여금 현재 request 를 보내는 사람이 누구인가!를 식별하는 것.
1.User가 입력한 자격증명정보(id, password)를 Server로 전송 및 인증 요청(request)
2. Server는 요청(request)와 자격증명정보를 토대로 Server와 연결된 user관련 DB를 참조하여 request를 보내는게 누군지 식별

인가 : 권한부여. 인증 프로세스가 없어도 권한부여가 가능한 것이 있음.
(cookie!!!-session storage에만저장(브라우저에만 저장))
1.User의 접근 권한 요청(request)
2.요청과 함께 전달받은 권한의 차등적 부여 관련 정보를 토대로 승인/거부
*권한의차등적부여관련정보: session에 정보를 저장, JWT, SAML(security assurance markup language), OAuth 같은 기술을 바탕으로

Authentication과 Authorization 인증 요청을 받았을 때, 식별하는 작업만(인증의 작업만)한다면, 추후 권한 요청이 있을 때마다 (페이지를 넘어간다던지, 포스트를 작성한다던지 등등과 같은) Database를 계속 돌려 권한 여부를 확인해야한다(페이지가 넘어갈 때마다 로그인을 하거나 본인 인증을 해야하는 상황이 생길수도)

사용자 인증(식별, authentication)이 완료되었을 때, 그 사용자(유저)에게 해당하는 권한을 준다면(마치 신분증을 건내주듯) 권한 요청이 있을 때 Server는 또 database에 연결하지 않고, 신분증만 확인하면 되기때문에 효율적임

사용자 요청(request)시, 권한의 차등적 부여 관련 정보를 server에 보내게 된다.
그 정보가 바로 JWT 이나 API key 이것을 신분증 같은 거라고 보면 되겠다.

찰떡같은 설명 감사합니다 ▶︎참고링크

암호화
인증 정보
http stateless : 정보를 저장하지 않는다, ◀︎▶︎ stateful
stateless : 점원에게 '아이스아메리카노, 카드로 결제'라고 전달했는데, 다른 점원이 왔을 때 나의 주문 정보를 모르고 다시 물어보는 것과 같은 상황
모든 http 서버가 stateful 하다고 하면 과부화가 걸릴 것. 모든 정보를 다 저장/기억하고 있어야하니까! 데이터를 서버가 관리하지 않고 TOKEN 을 이용한다(뒤에서 다시)
-> http 자료 찾아보기
stateful
session
cookie
Cookie : data들이 자동적으로 쌓인다, cookie 를 지우는 행위를 생각해보면 이해할 수 있다.
Session : session ID
예) 찜질방key 로 뭐든지 다 할 수 있고, 뭐했는지 알 수 있는 것과 같은 원리
예) netflix 계정 여러 기기 접속 계정에 따라 기기 몇개 연결할 수 있는지 다른 것도 왠지 비슷한 원리일 것 같다고 하심.
<장점>
session ID 자체에 유의미한 개인정보가 없음 -> 보안에 좋음
서버에서 정보를 관리하므로 데이터 손상 우려에 대해 안전
서버에서 상태를 유지하므로, 사용자 로그인 여부 확인 쉽고, 강제 로그아웃과 같은 제재를 가할 수도 있다(그 사람의 session ID 지워버리기)
<단점>
과부화! 사용자가 많을 수록 사용자 정보가 계속 쌓이니까.
scale out 해야할 때 session의 관리가 어려워 진다.
scale out : 여러 컴퓨터를 쓰는 것과 같은 개념. 갯수를 늘려서 돌린다.
scale up : 슈퍼컴퓨터 처럼 자체 기능을 높인다
→ 서버가 터질 것을 대비해서 방향을 정할 수 있음 (콘서트 예매 등과 같은)
Token 이 있으면 해당 서비스를 사용할 수 있다.
일정기간 동안 접근 권한 캡슐화
리소스의 범위와 기간 통제
JWT : JASON WEB TOKEN
저장하고 있다가 통신할 때마다 (request)할 때마다 전달(response body에 담아서)

<장점>

사용자 측에서 token을 저장하므로 서버에 부담이 없다(비밀번호 대신에 token)
서버 scale out에 용이함
모바일/브라우저 멀티환경에서 사용 용이
Token 만료 시간 설정 가능, 짧게 설정 → 보안 good

<단점>

사용자 로그인 여부 확인 불가, 강제 탈퇴 불가(서버에 따로 저장해두지 않아서. - 따로 방법이 있지만 어려움)
http request 전송 데이터 크기가 크다 ; payload 부분에 사용자 식별을 위한 여러 정보들이 포함되어있음. -> XSS 공격에 취약, 민감한 정보 payload에 있으므로 위험.
google, kakao login 방식에 Token 이 쓰임!

해싱 Hashing(함수 혹은 알고리즘)
Salting
Key Stretching

< Hashing >

Hashing Algorithm은 어떠한 input 이라도 fixed size의 array of numbers and letters 로 input을 convert 한다
-내가 넣은 비밀번호가 요상한 문자들로 변환되는 것이지!

"If an attacker were to crack the hash function, then the hacker could read all the password in the database" 해커들은 마음만 먹으면 어떻게든 해킹해낼 것이다.

그래서 우리는 Salting 과 Key Stretching이 필요하다
참고자료 ▶︎ 링크

해싱 HASH 함수 참고자료 ▶︎ 링크
해싱 HASH algorighem 참고자료 ▶︎ 링크

암호를 해시 처리한 후 사용자 ID와 함께 짝을 지어 데이터베이스 테이블에 보관해줍니다. 
로그인 시, 입력한 암호는 해시 처리되어 데이터베이스 테이블의 해시 처리된 입력값과 비교됩니다. 
두 값이 일치한다면, 짜잔! 사용자는 작업을 계속할 수 있습니다.

There are many formulas that can be used to hash a message.▼

영상자료 링크 ▶︎ 링크

< salting >

A salt adds a string of characters to the user’s passwords to just before the password undergoes hashing.

< Key Streching >

The primary aim of stretching a password is to make deciphering the password more costly—whether with memory, time, or money—than an attacker can afford.

salting&key stretching 참고자료▶︎링크

단방향 : 한방향
암호화
복호화 : 암호화 된 것을 다시 되돌리는 것
해시
무결성 integrity
속도가 빠르다 = 빠르게 해킹할 수 있다.
레인보우 테이블

1234 -> abcd 이런 특징이 무수히 많이 정해져있어서 해킹이 가능

salting 솔팅
여기서 salting 소금친다, random한 문자(데이터)를 추가하여 원본과 다른 해시값을 가지게 한다.
1234 + abcd(random data) => 결과 값은 항상 다르게
but data 가 많이 쌓이면 나중에 찾을 수도 있다. 그래서
key stretching(키스트레칭) 사용 : 시간을 더 번다.
-> 비밀번호 변경 주기를 계속 띄우는 게 그런 이유다.

복호화 가능 조건 - 암호화 할 때와 복호화 할 때 사용하는 키가 동일해야하고, 암호화 할 때 사용한 키를 모르면 복호화 불가능.
대칭키
키가 유출 될 수도 있다.
그래서 public key / private key 를 사용하자 ▼
key pair
public key
private key : 를 갖고 있는 사람이 변경할 수 있는 권한이 있다
전자서명 : 작성한 내용을 private key로 암호화 한 값

비크립트
단방향
예를 들어 1234 값을 넣었다 ▼
해킹시스템 돌리면, 값을 매칭해서 레인보우 테이블을 또 만들어 해킹할 수가 있다.
그래서 salt 더 치고 hash 로 돌린다.
이것도 역시 시간을 벌어주는 방법이다.
구조만 알아둬라

HASING ALGORITHM 은 어떤 input 이라도 fixed size 의 arrays of numbers and letters으로 convert 한다.

해싱 HASH 함수 참고자료 ▶︎ 링크
해싱 HASH algorighem 참고자료 ▶︎ 링크

암호를 해시 처리한 후 사용자 ID와 함께 짝을 지어 데이터베이스 테이블에 보관해줍니다. 
로그인 시, 입력한 암호는 해시 처리되어 데이터베이스 테이블의 해시 처리된 입력값과 비교됩니다. 
두 값이 일치한다면, 짜잔! 사용자는 작업을 계속할 수 있습니다.

가장 많이 사용되고 있는 Token
bcrypt salt 한 부분을 같이 저장할 수 있는데 ( 이사람이 이사람이구나를 알 수 있다는 장점)
Header
Payload
Signature : 신뢰성
데이터의 신뢰성 보장
token 자체를 서버가 저장하고 있지 않다 http 통신을 보낼 때, 회원가입/로그인 시 서버는 token을 body에 담아서 보낼 거고, FE가 요청할 때는 headers에 담아서 요청.

userId와 같은 것은 서버에만 PrivateClaim에 들어가야 한다는 것?

로그인 시 발급,
알고리즘은 백엔드에서 -> 암호화하는 것
정보를 저장하는 것은 frontEnd에서? -> 받은 token을 어떻게 처리할지.

→ 그 결과로 회원가입/로그인 진행

JWT 는 암호화 되어있다. 가져오는 정보를 이용해서 Front에서 처리하는 경우도 있음

룰루팍 Lolo Park

Korean-Arabic Translator, Backend Developer

다음 포스트

인증authentication 인가 authorization

룰루 인증/인가 정복기

< Hashing >

< salting >

< Key Streching >

Bcrypt 하고 JWT

0개의 댓글