5.1.2. Password Storage
Spring Security’s PasswordEncoder interface is used to perform a one way transformation of a password to allow the password to be stored securely. Given PasswordEncoder is a one way transformation, it is not intended when the password transformation needs to be two way (i.e. storing credentials used to authenticate to a database). Typically PasswordEncoder is used for storing a password that needs to be compared to a user provided password at the time of authentication.
# Password Storage History
1. To protect information from malicious users, Developers were then encouraged to store passwords after running them through a one way hash such as SHA-256.
악성 사용자로부터 정보를 보호하기 위해 개발자는 SHA-256과 같은 단방향 해시를 통해 암호를 저장하도록 권장받았다.
2. To defeat this new system malicious users decided to create lookup tables known as Rainbow Tables.
악성 사용자는 [레인보우 테이블]로 알려진 룩업 테이블을 만들기로 결정했다.
3.To mitigate the effectiveness of Rainbow Tables, developers were encouraged to use salted passwords.
(salt : random bytes )
레인보우 테이블의 효과를 완화하기 위해 개발자들에게 salted passwords 를 사용하도록 권장했다.
4. Developers are now encouraged to leverage adaptive one-way functions to store a password.
Examples of adaptive one-way functions that should be used include bcrypt, PBKDF2, scrypt, and argon2.
이제 개발자들은 적응형 단방향 기능을 활용하여 암호를 저장하도록 권장된다.
# DelegatingPasswordEncoder
Prior to Spring Security 5.0 the default PasswordEncoder was NoOpPasswordEncoder which required plain text passwords. Based upon the Password History section you might expect that the default PasswordEncoder is now something like BCryptPasswordEncoder. However, this ignores three real world problems:
Default PasswordEncoder 는, 예를 들어 BCryptPasswordEncoder는, 세 가지 현실적인 문제점이 있다.
- here are many applications using old password encodings that cannot easily migrate
이미 많은 어플리케이션들이 쉽게 이동할 수 있는 낡은 패스워드를 사용하고 있다. - The best practice for password storage will change again.
현재 가장 나은 방법의 암호저장방법이 미래에는 아닐 수 있다. 자주 바뀐다. - As a framework Spring Security cannot make breaking changes frequently
프레임워크로서의 스프링시큐리티가 자주 혁신적인 업데이트가 되지 않는다.
Instead Spring Security introduces DelegatingPasswordEncoder which solves all of the problems by:
대신에 스프링 시큐리티는 아래와 같은 방법으로 문제를 해결하는 DelegatingPasswordEncoder를 소개한다.
- Ensuring that passwords are encoded using the current password storage recommendations
현재의 password storage recommendations 를 보장한다 - Allowing for validating passwords in modern and legacy formats
현재와 과거의 Format을 허용한다 - Allowing for upgrading the encoding in the future
미래의 인코딩 방법을 허용한다
Example 18. Create Default DelegatingPasswordEncoder : DelegatingPasswordEncoder 의 생성
PasswordEncoder passwordEncoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
Password Storage Format
일반적인 비밀번호 양식은 아래와 같다.
{id}encodedPassword
id는 어떤 PasswordEncoder가 사용될지 지정하는 것이고, encodedPassword는 original encoded password이다.
Example 22. DelegatingPasswordEncoder Encode Example
{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG
{bcrypt}를 prefix로 설정해서 DelegatingPasswordEncoder가 인코딩할 방식을 설정했다.
Password Matching
Matching is done based upon the {id} and the mapping of the id to the PasswordEncoder provided in the constructor. By default, the result of invoking matches(CharSequence, String) with a password and an id that is not mapped (including a null id) will result in an IllegalArgumentException.
id와 PasswordEncoder에 의한 비밀번호 매칭은 생성자에 의해 제공된다. 기본적으로 아이디와 비번이 맞지 않으면 IllegalArgumentException이 발생한다.
By using the id we can match on any password encoding, but encode passwords using the most modern password encoding. This is important, because unlike encryption, password hashes are designed so that there is no simple way to recover the plaintext. Since there is no way to recover the plaintext, it makes it difficult to migrate the passwords.
아이디를 이용해서 password encoding을 사용할 수 있고 이것은 중요하다. 암호화와 달리 id를 통한 password encoding 방식은 plaintext을 복원하기 어렵다.
너무 유익한 비밀번호 인증방식에 대한 공부였다... 하지만 당분간은 하지 않으려 한다.
바로 실무에 쓰일 법한 부분을 먼저 공부하겠다.
*모든 이미지와 자료 출처는 Spring.io입니다.
'Back-End > Spring Security' 카테고리의 다른 글
Spring Security Authentication (3) UserDetails (0) | 2021.03.16 |
---|---|
Spring Security Authentication (2) JDBC Authentication (0) | 2021.03.16 |
Spring Security Authentication (1) Form-Login (0) | 2021.03.16 |
Spring Security DI (0) | 2021.03.16 |
Servlet Security의 Big Picture (0) | 2021.03.16 |
댓글