SEB Section 3 Hash

클라이언트에서 서버측에 정보를 요청을 할 때, 보안상의 이슈가 발생할 수 있다. 단순히 이메일과 패스워드를 입력해 정보를 요청하는 방식이 이루어 진다면 서버측에선 데이터베이스에서 그 데이터를 가져와 비교를 한 후 맞으면 정보를 보내주는 방식을 사용할 것이다.

하지만 이 패스워드를 그대로 저장을 하게 된다면 해커가 해킹을 할 때 유저의 정보를 쉽게 얻을 수 있을 것이다. 이때 우리는 비밀번호를 암호화 하여 저장을 하게 되는 hashing 과정을 하게 된다. hashing에 대해 알아보자.

Hashing

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

Hashing 과정에는 3가지 원칙이 있다.

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

Salt

암호화해야 하는 값에 어떤 ‘별도의 값’을 추가하여 결과를 변형하는 것이다. 그렇다면 Salt는 왜 쓰는 것일까?

• 암호화만 해놓는다면 해시된 결과가 늘 동일하다. 해시된 값과 원래 값을 테이블(레인보우 테이블)로 만들어서 decoding 해버리는 경우도 생긴다.
• 원본값에 임의로 약속된 ‘별도의 문자열’을 추가하여 해시를 진행한다면 기존 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출되더라도 원본값을 보호할 수 있도록 하는 안전 장치이다.
• 기존 : (암호화 하려는 값) => (hash 값) salt 사용 : (암호화 하려는 값) + (salt용 값) => (hash 값)

salt 사용시에는 주의점이 있다.

• salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
• 사용자 계정을 생성할 때 비밀번호를 변경할 때 마다 새로운 임의의 salt를 사용해서 해싱해야 한다.
• salt는 절대 재사용하지 말아야 한다.
• salt는 DB의 유저 테이블에 같이 저장되어야 한다.