Hashing, 암호화

◎ encryption (암호화)

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

• 암호화에는 여러가지 방법이 있으며, 기본적으로 암호화는 쉬우나 복호화는 어려워야 한다.

◎ Hashing

• Hashing : 어떠한 문자열에 임의의 연산을 적용하여 다른 문자열로 변환

• Hashing 3가지 철칙

  • decoding(복호화)은 오래 걸리고, encoding(암호화)은 짧게 걸려야 함

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

  • 아주 작은 단위의 변경이 있더라도 반환되는 해시값은 완전히 다른 값을 가져야 한다.

• Hashing 알고리즘 : 대표적으로 SHA1, 요즘에는 SHA256을 사용

  • SHA-256 알고리즘을 사용했을 경우 출력값의 길이는 입력값의 길이와 관계없이 언제나 256비트(64 글자)다.

◎ Salt

• Salt

  • 암호화해야 하는 값에 어떤 "별도의 값"을 추가하여 결과를 변형하는 것
  • (암호화 하려는 값) + (Salt 값) => hash 값

• Salt 목적

  • 암호화만 해놓는다면 해시된 결과가 늘 동일하므로, 해당 결과를 테이블로 만들어서(레인보우 테이블) decoding 해버리는 경우가 생김
  • 원본값에 별도의 약속된 "별도의 문자열"을 추가해서 해시를 진행한다면, 기존의 해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출되더라고 원본값을 보호할 수 있다.

• Salt 주의 사항

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

◎ Password Storage History

• 초기에는 일반 텍스트로 암호를 저장

  • DB에 접근하려면 credential이 필요했기 때문에 비밀번호가 안전하다고 생각했음
  • 악의적인 SQL Injection 등의 공격으로 “데이터 덤프”를 읽어갈 수 있는 방법이 존재

• SHA-256과 같은 단방향 해시를 실행한 후 암호를 저장

  • 사용자가 인증을 시도할 때 입력한 암호를 해시 처리하여 비밀번호와 입력한 비밀번호의 해시값과 비교
  • 이런 시스템에 대응하기 위해 악의적인 사용자들은 룩업 테이블(레인보우 테이블)을 만듦
    • 미리 계산한 테이블로 해시값을 통해 비밀번호를 알아냄

• 솔티드 패스워드(salted password)를 사용

  • 솔트와 사용자의 비밀번호로 해시 함수를 실행하면 유니크한 해시값을 생성
  • 인증을 시도하면 해시처리한 비밀번호를 저장된 솔트와 사용자가 입력한 비밀번호의 해시값과 비교
  • 최신 하드웨어를 사용하면 초당 수십억 건을 계산할 수 있게 되며 비밀번호를 쉽게 알아낼 수 있게됨

• 적응형 단방향 함수(adaptive one-way function)로 비밀번호를 저장하는 것을 추천

  • CPU, 메모리 등의 많은 리소스를 소모해서 비밀번호를 검증
  • 스프링 시큐리티는 워크 팩터의 시작점을 제공하지만 성능에 따라 각자의 시스템에 맞게 설정하는 게 좋다.
    • bcrypt , PBKDF2 , scrypt, argon2 등

• 사용하는 부분에서 장기 자격 증명(사용자 이름 및 암호), 단기 자격 증명(세션, OAuth 토큰 등)으로 바꾸는게 좋습니다.

  • 단기 자격 증명은 동일한 보안 수준을 유지하면서도 빨리 검증할 수 있습니다.