[ 컴퓨터 보안 ] 19. User Authentication Mechanisms

Authentication

: 누군가/어느 것의 신원이 확실한지 확인하는 절차

 

Authentication = Verification + Identification 

 

- Vertification

지금 요청하는 사람 = 요청하면서 자신이라고 주장하는 대상
ex) 지금 빽빽대는 사람이 A인지

 

??? : 나 A임    ← 이 때 ???가 A인지 확인하는 게 verification

 

[ 1:1 ] 방식으로 비교한다.

 

- Identification

자기라고 주장하는 사람 = 등록된 사람인지

ex) A가 등록이 된 사람인지

 

A: 나 A임    ← A가 등록된 사람인지

 

[ 1:다 ] 방식으로 비교한다.

 

 

📌 Authentication 방법

 

1. Knowledge : 너가 알고있는 것

ex) Password , PIN 

 

 

2. Token : 너가 갖고있는 것

ex) Card, Passport, USB Token 

 

 

3. Biometrics : 너인 것

ex) 생체 인식같은 것

 

 

 

각각에 대해 알아보자

 

---

Password 기반 Authentication

 

 

 

 

 

이렇게 Clear-text로 보내면 안 되는 이유

 

1) DB에 Clear-text로 저장된 경우 : 모든 유저 정보가 다 털림

  ➡️ Encrypted form으로 저장한다.

 

2) Server로 전송될 때 Clear-text로 이동할 경우 : Packet 관찰이 가능하면 다 뺏김

   ➡️ Encrypted form으로 전송한다.

 

[ 해결법 ]

1. Original Clear Message(Password) 는 저장이든,전송이든 하면 안 된다. 

2. Password를 Digest한 값으로 저장하고, 이를 이용해 Authentication을 한다.

 

+ Password 는 Encrypted 형태로 전달 / 저장해야한다.

 

하지만! Replay Attack을 당할 수 있음.

- 이 방법일 떈 Replay가 가능하고, 웬만한 경우에는 Password-Guessing 으로 공격함

[ 안 당하는 법 ]

➡️ 각 메시지에 추가적인 정보를 붙여서, Replay Attack을 감지하고 반응할 수 있게 한다.

 

 

 

 

AI가 만들어준 예시

---

Password - Guessing Attacks

📌종류

 

1. On-line Attack

   > 시스템에 직접 비밀번호를 입력해보면서 맞는지 틀린지 확인

      ex) ATM기에서 카드와 비밀번호를 계속 쳐보면서 시도하는 것

           > 열쇠를 하나하나 집 문에 끼워보는 것

2. Off-line Attack

   > 미리 확보해둔 데이터를 기반으로 비밀번호를 분석

      ex) 누군가가 메모에 적어둔 비밀번호 힌트로 맞추는 

            > 열쇠 복사본을 만들어서 집에 가져간 뒤에 집에서 하나하나 만들어보는 것

 

 

[ 막는 방법 ]

1. 속도 제한

   > 비밀번호 한 번 틀릴 때마다 재시도 대기시간 증가

 

2. 시도 횟수 제한

   > x번 이상 틀리면 계정이 잠긴다.

 

---

Password File Protection

- Encryption 방식 : File에서 비밀번호을 One Way Encrytion 알고리즘을 사용하여 저장한다.

- OS 단계             : 에서 File Access Control로 막는다.

 

근데 Encryption 방식에선 같은 알고리즘을 사용한다고 하자.

 

만약 모든 유저의 비밀번호가 같다면

E(Password of user1) = E(Password of user2) = E(Password of user3) 으로 나올 것이고

자신의 비밀번호 암호화한 값과 다른이의 값이 같은 걸 알면 그냥 들어갈 것이다.

 

이를 해결하고자 예전에 배웠던 Salting 방식을 적용한다. 

 

 

[ Salting ]

- Password에 필요한 이유 : 모든 유저가 같은 비밀번호면 Hash값이 모두 같음

 

1) Encrypted Password를 저장할 때, 그 뒤에 무언가를 덧붙인다.

2) 같은 Password는 각기 다른 Encryption 알고리즘을 돌린다.

...

여러 방법이 있음

 

 

기존에 사용하던 Hashing the Password 방식은 아래와 같다.

1. Alice가 Password 를 전송

 

2. 'Alice' 라는 이름의 ID를 가진 Entity의 (Hashed) Password를 가져온다.

   그리고, 현재 Alice가 보낸 Password를 저장방식과 같은 알고리즘으로 Hash한다.

 

3. 그 두 개를 비교하여 같으면 Grant한다.

 

 

[ Hashing the Password 의 한계 ]

- 많은 유저들이 같은 Password를 사용하면, 모든 유저의 h(Password)가 같다.

 

 

해결책 ↓

📌 Salting the password

1. Alice가 Password 를 전송

 

2. 'Alice' 라는 이름의 ID를 가진 Entity에 있는 Salt를 가지고 오고, (Hashed with Salt) Password를 가져온다.

   그리고, 현재 Alice가 보낸 Password를 아까 가져온 Alice의 Salt와 함께

   저장방식과 같은 알고리즘으로 Hash한다.

 

3. 그 두 개를 비교하여 같으면 Grant한다.

 

 

 

 

---

Token 기반 Authentication

: 물리적으로 갖고 있는 걸 기반으로 유저를 Authentication 하는 것

ex) OTP 같은 거

 

📌 특징

1. Server와 Token이 서로 같은 정보를 공유하고=Synchronized 되어 있어야한다.
2. Token은 주기적으로 Refresh되어야 한다.
3. 해당 Token으로 만들어진 Password는 server에서도 같이 만들어져야한다.

 

📌 토큰의 생성과 사용

 

[ 생성 ]

Token이 만들어질 때마다 그에 맞는 seed가 생성된다.

 

 

[ 사용 ]

1. Authentcation token은 자동으로 OTP라고 불리는 pseudorandom number를 만들고,

   ID/Password 세트를 보낸다. 토큰 생성할 때 seed가 함께 만들어져서 유저 정보와 같이 저장됨.

 

2. Server는 DB로부터 해당 유저에 맞는 Seed를 항상 보유하고,

    password validation program을 통해 비밀번호를 계산한다.

 

3. Token은 비밀번호나 PIN으로 보호된다.

   = 알고 있는 것 + 갖고 있는 것으로 보호

 

 

- 1. One Time Password (OTP)

- 두 가지 인증 방식이 결합되어있다.

  > 가지고 있는 것 : ATM카드 (물리적으로 소유하고 있는 것)

  > 알고 있는 것 : PIN 번호    (비밀번호)

 

두 개 모두 Pass해야 사용 가능

 

근데 OTP 방식도 3가지가 있다.

 

- 사용자+System이 하나의 List를 공유하면서 사용하는 방식

 

- 사용자+System이 하나의 Password를 계속 업데이트 시키면서 사용하는 방식

                               (앞에서 만들어진 Password를 그 다음 단계 Key로)

 

- 사용자+System이 Hash function을 이용하여 Password를 업데이트하여 사용하는 방식

 

 

3번째 방식을 보자

 

 

- n 과 P0은 서로 공유가 되어있는 상태

 

Verifier가 Alice Password에 관해 저장하고 있는 정보는 다음과 같다.

[ Alice    |   n번 hash 했을 때   |    h^n(P0) 값이 나와야 함 ]  

 

이 때 Alice가 로그인 하려고 요청할 땐 verifier는 n값을 줄 것이고

Alice는 이 n값을 받고는, P0에 대해 n-1번 hash하여 보낸다.

 

그걸 받은 Verifier는

1. 그 값을 저장하여 Entity를 업데이트 시킨다.

[ Alice    |   n-1 번 hash 했을 때   |    h^(n-1) (P0) 값이 나와야 함 ]  

 

2. Alice가 보낸 h^(n-1)(P0)를 한 번 더 hash하여 h^n(P0) 을 만들고, 그 값이 Entity에 저장된 값과 같은지 확인한다.

 

[ 추가로 알아두어야 할 점 ]

n이 그럼 결국엔 h(P) 이후엔 h^0(P0) = P0로 되지 않냐?

그럼 어떻게 할거임?

= n은 일단 엄청나게 큰 수 + 0이 되었을 때 다시 엄청나게 큰 수로 할당하는 flow로 보낸다.

 

 

 

 

---

- 2. Challenge / Response Tokens

1) Client가 ID만 전송하고, 이게 Valid한지 판단

2) Server가 Random Challenge r을 보낸다. ( 그냥 난수 보내는 거임 )

3) Client의 Token이 해당 난수를 받고, 그 안에 있는 Action을 하여 Response.

4) Server는 그 Action을 보고 판단.

 

이건 Zero - knowledge proof 안 됨

 

해당 Random Challenge를 주고 받을 때는

3가지 방법이 있다.

 

- Unidirectional Asymmetric-Key Auth

- Bidirectional Asymmetric-Key Auth

- Digital signature  Bidirectional Auth

 

 

 

- Unidirectional Asymmetric-Key Auth

 

 

- Bidirectinoal Asymmetric-Key Auth 

 

 

- Digital signature  Bidirectional Auth

이거 Man In middile Attack 가능함?

 

---

Zero Knowledge Proof

: 내가 알고있는 걸 공개하지 않아도, 알고있다는 걸 증명하는 방법

 

아래와 같은 사진이 있다.

C와 D사이에는 " 열려라 참깨 "라고 말해야 열리는 빨간문이 있음.

 

근데 나랑 같이 들어간 verifier 가 나보고 비밀번호 아는지 물어봄

> 알긴하는데 말해주기엔 약간 꼬롬함

 

알긴하는데 말해주긴 그러니까 증거로 보여줄게 하고 Verifier를 B에서 기다리라고 함

내가 D로 나와볼게 하면서 C로 들어감.

1_ 비밀번호를 알면 빨간문을 열고 D로 나올거임

2_ 비밀번호를 모르면 그대로 C로 나올 것이다.

여러 번 반복해서 C로 가서 D로 나오든, D로 가서 D로 나오든 항상 D로 나오면

 

비밀번호 알고있는 걸 증명할 수 있다.

 

 

1. Secret값을 Hash해서 Server로 보낸다.

2. Server에서는 Random 값을 생성하여 Client 보낸다.

( Random값에는 특정한 Action을 하라고 되어있기도 함 )

 

3. Random 값에 맞는 Answer와 Secret을 보낸다,

 

 

예시)

 

 

 

secret num는 절대 이동하지 않는다.

 

이건 Man in middle 가능??

될 것 같은데..

 

---

Kerberos

 

https://hyeo-noo.tistory.com/415

[Network Security] 커버로스(Kerberos) 동작 원리 이해하기

 

 

1. [ ID , Password / 어떤 서버를 쓰고싶은지(=server ID) ] 를 AS로 보낸다!

 

2. 그럼 AS는 해당 메시지를 Encryption하여 티켓을 만들어준다.

   이 과정에서 Client가 준 정보에서 Password ➡️ Client의 address로 바뀐다.

  따라서 AS는 [ Client의 ID + Client의 Address + 어느 Server로 요청을 보내고 싶은지 ] 를 담아 티켓을 만든다.

                        그리고 이 티켓은 AS서버와 요청받는 서버만 Decrypt할 수 있다.

3. client는 해당 티켓과 자신의 ID를 Server로 보내서 인증을 받는다.

하지만 Client는 해당 Ticket을 decrypt할 수 없다. 

해당 ticket는 AS와 V 사이에 있는 Key로 Encrypt했기 때문에!

 

 

📌 한계점

- Password가 PlainText로 전달됨

- Ticket이 Reuseable하지 않다. 다시 쓰기엔 취약점이 생김.

 

> 이걸 해결하기 위해 Ticket-Grating Server (TGS) 가 필요하다

 

 

Client는 자신의 ID를 보내면서 tgs의 주소를 요청한다.
> tgs로의 티켓을 E(Kc)로 Encrypted되어 받는다. ( Client와 AS가 Decrypt 가능하기에 꺼내서 가져옴 )


Client는 자신의 ID와 server v의 티켓을 만들기 위해 같이 보낸다.
> tgs가 이를 받아서 v를 위한 Ticket를 만들어 보낸다. ( TGS와 V사이에서만 Decrypt 가능하다 )

 

 

- Ticket tgs는  Client가 보관하며 계속 가지고 있을 수 있다.

 

 

📌 한계점

한계점 1. Ticket의 Life time. 어떻게 할 것인지

   1) 너무 짧음 → 계속 Ticket을 만들어야함

   2) 너무 길다  → 누군가 다른 사람의 Ticket tgs를 빼내서, 그 사람인 척 속일 수 있다. 

 

➡️  Server는 [ 지금 티켓 가져온 사람 ] == [ 티켓 이슈 받은 사람 ]이 같은지 확인한다.  

쓰고싶은 주소의 ID + Ticket tgs + Auth v 를 담아서

Ticket을 만들어준다.

 

 

한계점 2. Client가 Authenticate Server가 필요하다.

만약 나쁜놈이 client의 메시지를 다른 서버에 보내면 어떡함?

 

 

> 해결책
Kerberos

 

 

최종적으로 얻고자 하는 건 SGT임.

하지만 그걸 얻으려면 TGT가 필요하고, 또 그를 위해서는 TGS에 요청을 해야함.

 

그 방법을 알아보자.

 

[ 작동 방식 ]

1. Client와 AS 사이의 인증

 

1. Client가 Timestamp(Random number) 를 함께 보내며 TGS를 위한 Ticket을 AS에게 요구한다.

2. AS가 Client로부터 받은 정보를 기반으로 TGS를 위한 Ticket을 만들어서 본인과 Client만 볼 수 있게 보낸다.

  (안전한 전달을 위해 Encrypt, clnt가 까서  Ticket을 꺼내야 하니까 Clnt와 AS가 볼 수 있는 Key로 Encrypt 한다.)

 

 

2. TGS와  Client간의 소통

 

3. Client가 TGS로의 Ticket과 인증서를 보낸다.

4. Tgs가 티켓을 까보고, 그 안에 있는 정보를 토대로 v로의 Ticket을 만들어 Encrypt한다.

 

 

 

3. Server / Client 인증 소통

 

5. v로의 Ticket과 C의 Auth를 보낸다. 

6. v가 받고 정해진 행동으로  Response한다.   ex) 이거 읽을 수 있으면 점프 크게 해  --> 점프 띠용

 

 

 

https://hyeo-noo.tistory.com/415

 

 

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

(출처) 📌➡️

한동대학교 고윤민교수님 - 컴퓨터 보안