[Spring Security] Hashing & Salt

[Hashing]

: Key 값을 해시 함수라는 수식에 대입시켜 계산한 후 나온 결과를 주소로 사용하여 Value에 접근하게 할 수 있는 방법

 

 

if) 이메일과 관련된 정보를 얻을 때 인증 과정을 거치지 않는다면?

: 서버는 클라이언트에서 보내온 요청에 따라 이메일과 관련된 정보를 DB에서 가져와 클라이언트에 전달

>> 이메일 정보만 있다면 모든 정보에 접근이 가능함

 

if) 비밀번호를 이용한 인증 흐름을 설계한다면?

: 서버는 이메일과 비밀번호 정보를 받아 DB에서 비교 후 정보가 일치할 경우 클라이언트가 요청하는 데이터를 DB에서 찾아 클라이언트에 전달

>> 해커가 DB에서 비밀번호를 탈취할 경우 피해가 커짐

 

* 따라서 비밀번호를 DB에 저장할 때 암호화 하여 저장하는 것이 필요함

 

 

[암호화]

암호화(Encryption)

: 일련의 정보를 임의의 방식을 이용하여 다른 형태로 변환하여 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 알고리즘을 이용해 정보를 관리하는 과정

 

shiftBy("apple", 2); // crrng
shiftBy("crrng", -2); //apple

shiftBy() 메서드
: 입력받은 문자열을 입력받은 숫자의 값만큼 알파벳 순서를 건너뛴 문자로 변환해 새로운 문자열로 반환

 

if) shiftBy()를 사용해 서버에 적용한다면?

: 이전 과정에서 요청과 함께 전달받은 비밀번호를 서버측에 암호화 시킨 후, DB 정보와 대조

:  DB는 원본 그대로가 아닌 알고리즘을 거친 결과를 저장함

과정) 비밀번호를 이용한 인증 요청이 올 때마다 그 알고리즘을 통해 암호화 시킴 > DB에 저장되어 있는 값을 확인 > 맞으면 요청한 데이터를 가져와서 클라이언트에게 변환하는 과정

>> DB에서 비밀번호를 탈취 당하더라도 알고리즘을 알 수 없음

 

 

[Hashing 서비스 적용 철칙]

1. 해시값을 해독(decoding)할 때는 많은 시간이 걸려야 하지만, 반대로 해시값을 만드는 데엔 오래 걸리지 않아야 함

2. 해시 값들은 최대한 다른 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가져야 함

3. 문자열에 아주 작은 단위의 변경이 있더라도 반환되는 해시값은 완전히 다른 값을 가져야 함

 

 

 

[Salt]

: 암호화해야 하는 값에 어떤 별도의 값을 추가하여 결과를 변형하는 것

: 암호화 하려는 값 + Salt용 값 = hash 값

 

1. 암호화만 해 놓을 경우 해시된 결과가 늘 동일

따라서, 해시된 값과 원래 값을 테이블로 만들어 decoding하는 경우가 존재

 

2. 원본 값에 임의로 약속된 별도의 문자열을 추가하여 해시를 차가할 경우 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출 되더라도 원본값을 보호하도록 하는 안전장치

 

주의사항)

1. 유저와 패스워드 별로 유일한 값을 가져야 함

2. 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 salt를 사용해 해싱해야 함

3. Salt는 절대 재사용하면 안됨

4. DB의 유저 테이블에 같이 저장되어야 함

 

 

if) 유저별로 다른 salt를 사용할 때 설계 흐름

: DB에서 각 다른 Salt를 가져야 함  >>  비밀번호에 salt를 더한 후 해싱 알고리즘 반환값을 DB에 저장  >>  인증 과정에서 비밀번호에 유저의 salt값을 더해 해싱 알고리즘의 결과값과 DB 값을 비교

 

즉, Hasing 과정에서 Salt를 추가할 경우 알고리즘이 노출되더라도 보안에 안전