Let's review password requirements because it is SIer

TL;DR --Basically enable all character types (minimum ASCII) ――But don't put restrictions like using all types ――Apart from 1000 digits, don't limit it to 10 characters or less ――Do not implement the storage method. --Don't change it regularly --Throw away your secret question

At the beginning

Of course, if you have a job like SIer, you may often launch a new service related to a company, but in such a case, basically the first time under the name of "** precedent case **" In many cases, specifications that may not have been considered are taken over as they are. Among them, regarding functions that are clearly common and shared, such as passwords, ** tend to use the system that was in-house for both requirements and implementation **, and decent discussions are rarely held ... .. As a result, there are a lot of requirements that don't seem to be modern in the world, and when it's a necessary service, it turns around and frustrates us as consumers.

Anyway, SIer customers do not go into the part like password so much, so if you explain it, most of them will accept it, so the purpose of posting is to spread the password requirements that should be modern as a grassroots movement. I will.

honestly speaking

All the following articles are SP 800-63B (translation link published by NIST (National Institute of Standards and Technology). -63b.pdf). Thanks to organizations like the OpenId Foundation for making translated versions. ) Excerpt, it will be a miscellaneous feeling. The relevant document is packed with useful information such as organizing other authentication methods, so please take a look if you are interested.

Password Allowable String Requirements

1. ** Allow all character types ** Obviously, password combinations can be represented by `` `(usable character type) ^ (number of characters) ```, so it is also strong against brute force attacks, and the password that the user expected can not be used. It disappears and convenience is improved. Obviously, you can't expose your password in clear text, so you won't have problems with SQL injection. (If you keep it in plain text, that is more of a problem)
2. ** Let's stop forcing character types ** It seems that quite a few services have adopted this, but in most cases the forced character types, as quoted below, do not increase the strength of the password itself.

Researchers have shown that users respond in a fairly predictable way to the requirements imposed by the configuration rules. For example, a user who selects "password" as a password selects "Password1" with a relatively high probability when a requirement including uppercase letters and numbers is given, and selects "Password1!" When a symbol is added to the requirement.

3. ** No upper limit on password length ** As described in the management below, the password is naturally stored in hash and does not depend on the original length. For this reason, it is important not to set an upper limit on passwords, regardless of the level that clearly affects the processing. (Although it is often called a passphrase, it is important to be able to accept such a form, because even a simple list of words will be stronger if it is long enough.)
4. ** Let's make a blacklist ** To be honest, this is troublesome for SIers because it is difficult to reach an agreement with customers on how to decide (update) the contents of the blacklist, but for example, Splash Date's [Dangerous password] 100 selections](https://www.teamsid.com/100-worst-passwords-top-50/) I think it's quick to refer to this area. (I'm surprised if you really use 123456 etc ...)

Password storage requirements

Obviously, it is necessary to store the password in some way to determine whether the password entered by the user is correct, but in that case, the storage format is in the unlikely event that database information is leaked or an internal crime of system maintenance occurs. It is very important that it cannot be restored realistically. The required implementation is

--Appropriate hash function (not encrypted, of course) --Sufficient number of stretching (repeated hash) --Random salt

This is a necessary matter, but as a result of making it with oleore instead of basic, it is actually a hash once and it ends, or it is a salt that is just selected from the list even though it is random, and there are various problematic implementations Is overflowing in the world.

This is the case where you should leave it to the giant to do without reinventing the wheel, and you should choose a library that has a quick interface. I think BCrypt is safe. (Hereafter [Spring Security Crypto] when used in Java (https://github.com/spring-projects/spring-security/tree/master/crypto/src/main/java/org/springframework/security/crypto/bcrypt) It is described in maven.)

pom.xml

		<dependency>
			<groupId>org.springframework.security</groupId>
			<artifactId>spring-security-crypto</artifactId>
			<version>5.0.0.RELEASE</version>
		</dependency>

Other requirements

1. ** Regular change ** I think everyone is aware of it because it became a hot topic last year, but regular password changes are currently deprecated. The main reason is that they tend to be the same in rotation, and in fact they tend to choose passwords that are easy to guess, such as replacing fixed numbers at the end.
2. ** Secret question ** This is also becoming common sense in modern times, but a question that asks the memory of the event that individuals cannot forget Where is your junior high school?
   With the spread of SNS, etc., it has become something that can not be said to be a "** secret **" that anyone can tell, so never use it.

Summary

There are always experts on the features that everyone uses in modern times, and the latest information is constantly being updated. When designing such common functions, consider overseas cases as much as possible, check the primary source as much as possible, and design according to the trends of the world to improve convenience and safety.