From a8c499d0125b2e96f7f3c539f6b46cff7547aa80 Mon Sep 17 00:00:00 2001 From: Andrey Andreev Date: Tue, 31 Mar 2015 15:01:36 +0300 Subject: [ci skip] Update security recommendations --- user_guide_src/source/general/security.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'user_guide_src/source/general') diff --git a/user_guide_src/source/general/security.rst b/user_guide_src/source/general/security.rst index efc821f2b..fcfe4c24b 100644 --- a/user_guide_src/source/general/security.rst +++ b/user_guide_src/source/general/security.rst @@ -143,11 +143,15 @@ with that. Please read below. feature, just randomly generate a new, one-time (this is also important) password and send that instead. -- DO NOT put artificial limits on your users' passwords. +- DO NOT put unnecessary limits on your users' passwords. - There's no point in forcing a rule that a password can only be up to - a number of characters, or that it can't contain a certain set of - special characters. + If you're using a hashing algorithm other than BCrypt (which has a limit + of 72 characters), you should set a relatively high limit on password + lengths in order to mitigate DoS attacks - say, 1024 characters. + + Other than that however, there's no point in forcing a rule that a + password can only be up to a number of characters, or that it can't + contain a certain set of special characters. Not only does this **reduce** security instead of improving it, but there's literally no reason to do it. No technical limitations and -- cgit v1.2.3-24-g4f1b