That said, shaping your password policy needs the right balance. Find a balance in password requirements to encourage security alongside registrations And, of course, we also need to remember that cumbersome requirements may discourage registrations.
However, this may lead to users having to save their passwords somewhere else, which introduces another security risk. When deciding on the policy, you may find it very tempting to enforce super complicated password requirements in the name of security. Your site can be your great security assistant that guides users through the process of creating passwords, imposes certain requirements, and automatically applies other login security features. The power of a website here cannot be underestimated. The password policy can be advisory or it can be implemented programmatically via the website. It is often a part of the organization’s overall security policies. The keystones of a secure website password policyĪ website password policy is a set of rules and measures for encouraging users to create strong passwords and for otherwise ensuring login security. We will discuss all this and more in today’s article, so let’s get started. Drupal is highly rated for password security and offers plenty of great features in this sphere. The great news is that it is much easier to implement with the Drupal CMS. To equip your little security guards with shiny armor and make them unbreakable, you will need a decent password policy. Their strength can be especially crucial if a website contains sensitive information or if a particular user has a lot of permissions. Considering their mission, they certainly need to be strong. See where this is being discussed.Passwords are little gatekeepers that take care of securing a website’s user accounts. I assume the expire date is also stored on server side, so I assume this won't help. A browser or other client could ignore or override the cookie lifetime, and keep the session alive longer than intended.Even when session.gc_maxlifetime has run out, there is a chance for the session to stay alive for a bit longer, because the garbage collection only happens every once in a while (depending on session.gc_probability and session.gc_divisor).session.gc_maxlifetime is a server-side limit, but okie_lifetime is a client-side limit.For one hour it would have to be 60 * 60 = 3600.įrom the information I found, and my understanding of it: (note: the article says 60 = 1h, which afaik is wrong.(2 * 7 * 24 * 60 * 60 seconds = 1209600 seconds) About the valuesįor more information on these values, see Fix.ĭecide on suitable values for session.gc_maxlifetime and okie_lifetime, and use one of the places mentioned above to set these values.įor the project I am working on, I decided to set both values to 1209600 = two weeks. grep is your friend.Īlso look for modules that modify login duration, such as or. in /etc/apache2/nf, or /etc/apache2/sites-enabled/. ini_set() statements in your Drupal's sites/*/settings.php.Otherwise, the number specifies seconds of login duration. This means that closing the browser causes a logout.
Look for okie_lifetime and session.gc_maxlifetime.Ī value of okie_lifetime = 0 causes the Expire = Session for the session cookie. Open admin/reports/status/php for current phpinfo. This can give you clues whether this is a problem with your global server config or with your specific site. your localhost), and with different browsers. It can also be interesting to compare with other Drupal sites installed on the same server (e.g. Most of the time this is not what you want! The cookie that is relevant for login has a key = "SESS.".Īn "Expire" of "Session" means that the cookie expires when the browser is closed. To debug this, one can use browser developer tools to inspect cookie expire date. Inspect your session cookies with browser developer tools Look for session.gc_maxlifetime and okie_lifetime.
0 kommentar(er)
