항해99 12주차 WIL[validator, jwt 알고리즘 rs256과 hs256]

자유로운 회원가입과 로그인을 지향했으나

구글폼 회원들의 의견에는

회원가입 username, password에 있어서 제한이 있어야 한다는 의견이 지배적이었다.

 

우선 validator를 짜봤다.

 

public static void validateInputUsername(SignupRequestDto requestDto) {

    String username = requestDto.getUsername();

    //이메일 형식
    String patternUsername = "^[a-zA-Z0-9+-_.]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$";

    // 이메일 설정 유효성 검사
    if (username == null || !Pattern.matches(patternUsername, username)) {
        throw new CustomException(ErrorCode.SIGNUP_MEMBERID_WRONG_INPUT);
    }
}

public static void validateInputPassword(SignupRequestDto requestDto) {

    String password = requestDto.getPassword();
    String passwordConfirm = requestDto.getPasswordConfirm();


    // 8자에서 16자 이내, 대소문자, 숫자.
    String patternPw = "^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9]).{8,16}$";

    // 비밀번호 설정 유효성 검사
    if (password == null || !Pattern.matches(patternPw, password)) {
        throw new CustomException(ErrorCode.SIGNUP_PASSWORD_WRONG_INPUT);
    }

    // 비밀번호 확인 유효성 검사
    if (!password.equals(passwordConfirm)) {
        throw new CustomException(ErrorCode.SIGNUP_PWCHECK_WRONG_INPUT);
    }
}

 

정규표현식과 관련하여 좋은 블로그를 찾았다,
https://zzokma.tistory.com/1644

자주 사용하는 정규표현식

https://enzycut.tistory.com/28

[JAVA] 패스워드 정규식 (Regex)

 

토요일 멘토링이 있었는데

jwt 알고리즘을 설명해주시면서 rsa 알고리즘에 대해 설명해주셨다.
팸키와 펍키를 사용한 알고리즘이고 더 해석이 안되는 키라는 약간의 팁을 주셨는데 

해당 내용에 대해서 구글링을 해봤다.

 

RS256

RS256는 RSA + SHA256을 줄임말로 대칭키방식인 HS256과 달리 공개키를 이용하는 대표적인 암호화방식인 RSA을 사용한것이다.

 

메세지를 SHA256 알고리즘으로 해싱 한뒤 private key로 암호화(서명)한다. public key를 발급받은 어떠한 주체는 앞서 암호화(서명)된 해싱값을 복호화 또는 서명을 검증하는 할수 있는 방식이다.

 

public key는 이름 그대로 보안을 유지할 필요가 없기 때문에 ID 공급자는 이 public key를 메타 데이터 URL을 통해 쉽게 구할 수 있도록 제공한다.

 

HS256

HS256 는 HMAC SHA256 의 줄임말이다.

HAMC은 Hash-based Message Authentication Code 라는 뜻을 가진다.

 

해싱에 대해서 다시 얘기해볼 때 입력값이 같다면 해싱된 해시값은 항상 동일하기 때문에 수정에 대한 검출은 가능하지만 거짓 행세하는 것을 검출하기는 어렵다.

 

거짓행세에 대해 검출하고 차단하기위해 SHA256으로 해싱된 메세지를 메세지 인증 코드(private key <- 추측임..)로 암호화(서명) 하여 송신하고 수신측에서는 동일하게 소유한 private key로 복호화 및 서명을 검증하는 방식이다. 동일하게 소유했다는것은 즉, HMAC SHA256 알고리즘이 대칭키 방식임을 알 수 있다.

 

그럼 언제, 어느 알고리즘을 적용해야 할까?

 

HS256 알고리즘은 하나의 키(secret key)가 서명과 서명 검증에 사용되므로 서버측(ID 제공자), 클라이언트측 모두 secret key를 소유해야 한다. 이로인해 secret key 교환을 위한 별도의 안전한 메커니즘이 요구된다. (참고로 JWT 서명, 발급할 때 마다 secret key가 생성되는것이 아닌 오직 하나의 키만 존재한다.)

 

HS256 방식을 사용하는 JWT가 적용된 앱이 있다고 가정하자. HS256 방식은 이 앱을 다운로드 후 로그인에 성공한 모든 사용자에게 별도의 보안 메커니즘을 통해 secret key를 전달해 줘야 한다. 관리자는 지속적으로 앱을 다운로드, 로그인을 성공한 사용자를 제어할 수 없으며, secret key가 해커에게 유출된다면 해커가 임의로 변조한 JWT를 서버측에서 서명 검증에 성공해버리는 이슈도 발생할 것이다.

 

참고로 내가 진행중인 프로젝트는 단순하게 클라이언트 측에서 JWT 서명을 검증할 필요는 없어 서버측에서만 secret key를 소유, 서명 검증을 진행하면 됐기 때문에 HS256 방식 그대로 적용하는것이 나아 보인다.

 

결론적으로 이 secret key를 사용하는 사람을 제어할 수 있으면 HS256 알고리즘, 없다면 RS256 알고리즘을 적용하면 된다.

 

 

현재 우리 조의 로직을 살펴보면 hs256으로 되어 있는데. 
서버배포후 오류 잡는데 집중하고 있는 현재 상황에서 이를 rs256으로 바꾸기 위한 작업을 곧바로 하긴 어려울듯하다.
2주 정도 뒤에 이를 적용해보고 뭔가 더 알아가는 시간이 오지 않을까... 싶다. 
항해 얼마 안남았다 끝까지 화이팅!