Snap! Websites
An Open Source CMS System in C++
The password plugin is used to handle user passwords. Especially, it offers a way to define a password policy.
At this point the password policy offered is as found on most website, not the best as we already know, but certainly much better than not having a policy at all, especially if you have an e-Commerce website. The plugin also offers a function to generate a password that will validate against the current password policy of the website.
Note that various ways to log in your website can each include a different type of password policy. For example, the oauth2 plugin offers its own password policy.
The current policy supports the following features:
This option allows you to force the user to enter at least that many characters in their password.
Note that having a minimum number of X/Y/Z type of characters also enforces a minimum password length in itself. For example, a minimum of 3 lowercase letters, 3 uppercase letters, 3 digits and 1 special character forces people to have passwords of at least 10 characters. In other words, this feature is often not used when specific minimums are required.
This option forces the end users to enter lowercase letters in their password. The number represents the minimum number of lowercase letters to enter. Note that all Unicode lowercase letters are supported, so ų or į are viewed as valid lowercase letters for passwords.
This option forces the end users to enter uppercase letters in their password. The number represents the minimum number of uppercase letters to enter. Note that all Unicode uppercase letters are supported, so Ę and Ȯ are viewed as valid uppercase letter for passwords.
This option forces the end users to enter letters in their password. The number represents the minimum number of letters to enter. Note that all Uncode letters are supported, so Ÿ and ō are both considered letters.
Note that if you already have a minimum number of lowercase and uppercase letters, you may still use a minimum number of letters larger than the total of those two minimum to force the user to enter that minimum letters total. For example, if you want a minimum of 1 lowercase and 1 uppercase, you could also enforce at least 5 letters total.
This option forces the end users to enter digits (numbers) in their password. The number reprensents the minimum number of Unicode characters representing a number that have to be entered. All Unicode characters that represent a number are included so ½ or ¾ are viewed as numbers, albeit not whole, and ⑮, which is a number, not just a digit, is also viewed as a valid character for this minimum number (although it counts as 1 character, not two.)
This option forces the end user to enter spaces in their password. The number represents the minimum number of spaces to enter. Note that all Unicode spaces are supported, so codes such as 0x2002 EN SPACE, are counted as spaces.
Note that characters visibly representing a space such as the box character (␣), are not considered to be spaces. These are special characters.
This option forces the end user to enter special characters in their password. The number represents the minimum number of special characters to enter. Special characters are generally all the characters that do not fit another class. These are often referenced as punctuation, although it will include mathematical characters, special characters used to link letters together, etc.
Note that spaces are not considered special characters for the purpose of this counter. This is used that way to allow for two distinct classes of characters.
This option forces the end user to enter Unicode characters in their password. The number represents the minimum number of Unicode characters to enter.
The current algorithm considers a character to be a Unicode character when its code point is 256 or over. However, Unicode does encompass characters from 0 to 255 too. So it is probably a bad designation for this class and we may rename it at some point.
The previous Minimum Number of ... options force the user to enter specific types of characters. This can be quite annoying to users. Another way to enforce enough variation but not force the user to enter characters of a specific class is to ask the user to enter a minimum number of variations in their password.
This counts the number of classes and makes sure that it is equal or larger that the minimum number of variations entered here.
For example, a password such as "123abcABC" has a variation of 3 since it includes 3 digits, 3 lowercase letters, and 3 uppercase letters.
Note that for the purpose of this calculation, the "letters" class is ignored. Only the uppercase and lowercase letters classes are used.
When the Minimum Number of Variations option is used, you may also specify the minimum number of characters necessary in each category. For example, the password "1aA" has a variation of 3, but a length of 1 for each variation. Maybe you want to force people to have at least 3 characters per variation, then "1aA" is not acceptable, but "123abcABC" is.
If you would like to prevent a user from changing his password over and over again on the spot, you may include a time in minute that forces the user to wait between changes. For example, if you put 60, then the user cannot change his password more than once every hour.
This is often used by systems that want to forbid reuse of an old passwords. The delay is expected to prevent the user from going through many of his old passwords and end up with the same password within a minute or two. However, we are not affected by this problem because we keep old passwords for a certain amount of time and not just a count. So if you want to forbid an old password for 1 year, you can do so and we will prevent the reuse of that password for one whole year, whether the user changes his password once a month, or a thousand times a day.
Many users will probably see this as an annoyance, especially if they inadvertendly copied their password in the wrong place and really need to change it again immediately. This option is really not recommanded (i.e. leave the default of 0.)
This option gives you the option to keep the user old passwords in the database. It is not generally recommanded since that means copies of the old passwords will continue to survive in your database and that can be viewed as a security issue. Yet, some official recommandations, such as those from e-Commerce PCI Compliance systems requires you to enforce such.
The password plugin feature includes:
The number of old password is actually a minimum number. If the user changes many times in one day, all those passwords will be kept and forbidden for the minimum number of days. This allows us to make sure that a user cannot just cycle through your 3, 5, or even 10 password limit and end up with the same password again. However, as mentioned earlier, this means the user may end up with many old passwords in his account...
The number of days the password survives defines how long the passwords stay in the database. After that many days, it gets deleted and forgotten for good. Until then, the password stays in the database and it cannot be reused if this option is turned on (flag is checked.)
IMPORTANT NOTE: At this time there are not features to go in and delete old passwords after they were saved in the database.
This option is just a flag to know whether to check client passwords against the Snap! installation blacklist.
Note that the blacklist is not specific to one Snap! website. If you have hundred of websites in your installation, then all share the same password blacklist.
You may manager your blacklist by adding and remove passwords from it.
You may define a lifetime for a password, in days. By default this feature is turned off. Accoding to many security experts, it is not useful to force people to change their password.
This feature is often used along the old password reuse feature. If you force a user to change his password, you probably also want to force them to use a new password.
As mentioned before, the use of the old password feature is a security risk as old passwords stay in your database. That means the passwords can be stolen, even if properly encrypted with SHA512 or bcrypt and some noise.
When a hacker attempts to crack a password on your website using a robot to repeat the attempts in a completely automated way, they are likely to repeat login attempts to the same user account over and over again. These attempts are counted and as a result the server may prevent any further login.
The basic Invalid Passwords Counter number shows the number of times it takes before the account gets blocked for Invalid Passwords Block Duration in hours. By having such a block, it completely prevents the hacker's robot from trying any other passwords. It could also mean that the robot will skip some passwords without knowing that it was not actually being checked properly, making it even safer. Note that this block also prevents the normal user from logging in, although if the user is already logged in, it will not be kicked out so in that case the block is completely transparent to your regular users.
The Lifetime of Invalid Passwords Counter number represents the number of hours that the counter is kept in the database. Each time an invalid password is used, the lifetime duration is restarted from that moment on. For example, if you put 3 hours here, the counter will be kept for three hours. A robot that checks an invalid password every 4 hours (or even 3.5 hours) will not be detected. It is common practice to use a number around 24 hours for these counters. Just remember that some of your users may re-log in every day and having a counter that lasts days may not be a good idea.
The Invalid Password Slowdown represents a multiplier used by the server to know how long to wait before returning its reply. The server counts the number of times the account was accessed with an invalid password and multiply that number by this multiplier. The result represents the number of seconds the server will go to sleep before returning an answer to the browser (robot). Note that this cannot be too large because otherwise the browser is likely to timeout instead and your server will also be impacted (although frankly, it will be sleeping... but it has some memory allocated.) In general, a number around 3 is pretty good.
Why a password slowdown?
Somehow most Unix systems have such a slowdown capability and it is used to prevent people from attempting to discover someone else's password. This is a good idea because it forces the robots testing such logins to slowdown whether your Snap! servers have the capability to answer each attempt in 50 ms or not.
To give you an idea, if you can attempt to login with as many passwords as you want in as short an amount of time as you'd like, assuming it takes about 50ms per attempt, you can try 1,728,000 passwords per day.
Opposed to that, if the server slows down with a multiplier of 3, the robots will be given a chance to try a maximum of 240 times in a day. With a multiple of 5, it would be limited to 186 times. And even with a multiplier of 1, it would cut down the number of attempts per day to 415.
So in effect, it really renders brute force password attacks very unlikely to pierce your users passwords even more than just a counter and full block (which can also be annoying to your regular users.)
Note that all tests to determine the type of a character is using a fully Unicode aware implementation. The versions plugin tells you which Unicode version is being used. For example, a digit, as far as Unicode is concerned, is not limited to the 0-9 ASCII range. The ½ and ¾ characters is also viewed as a digit.
Snap! Websites
An Open Source CMS System in C++
