You all heard that passwords are the weakest link to attack. For end-users passwords are a nuisance to remember especially when password rules require a certain combination of letters, numbers and special signs to be used and password changes are mandated on a regular basis. You can get the “No longer fall on your end-uses part” right, by explaining mnemonics as a way to build and remember secure passwords. What that means is that you remember a sentence and build your passwords via the first letters of every word and all numbers and specials signs included. Take this example:
Next year I will be 3 weeks on Hawaii for a gr8 vacation! = NyIwb3woHfag8v!
No, this is not an actual password of mine. My password is SECRET! The password above is very hard to guess, but it’s easy to remember for an end-user.
Most attackers do not have to brute-force our passwords though. Either they just try the pre-installed and never changed passwords of known administrative users. Or a lot of users will use very simple passwords, like password or 1234abcd.
Although passwords should be hashed, it’s easy to compare hash values of common words extracted from a dictionary with the hash values stored in an unsecure password table! So passwords should be stored with a salted hash value. And access to the password table has to be secured via authorizations.
Needless to say the communication path between the client, where the user types in the password, and the server, where the hash values get compared has to be encrypted.
A lot of companies enquire about 2 factor (2FA) or multi factor authentication to enhance security of password based access. 2FA or multi-factor authentication requires 2 or more secrets from an end-user.
But that is all common knowledge. Take a look at this example, which was a requirement from one of my customers in an implementation project.
Requirement for passwords: Passwords should be 25 characters long and combine three out of the four characters: Upper case, lower case, special letter, number. Password changes should be enforced monthly. Passwords may not include entries or part of entries of an excluded password list. The list of excluded passwords should include the last 10 passwords for the end-users. No end-user must have the same password like another end-user. After 3 unsuccessful logon attempts, a user shall be locked.
Sounds pretty tough, right? What is the problem here? Is there any?
So let us walk through this example requirement by requirement. A password that has to be 25 characters long as a minimum is very hard to remember esp in combination with the rules that users have to change their passwords monthly and that they cannot pick a password from their last ten passwords. Either you expect Password Reset Purgatory or you explain the above mentioned concept of mnemonics to your end users. Preventing users to be able to include words or parts of words in their passwords is understandable. If such a configuration option for exclusion of passwords exists within your platform, you might want to download a dictionary into that table including all common first names and common last names, esp all last names from your user base.
So far we sum up, that these are pretty tough requirements, but with the right tools and accompanying change management process could be implemented.
What about the pen-ultimate part of the requirement? Unique passwords for end users? No end-user must have the same password like another end-user? Well, this prevents, that administrators implement masses of users with the exact same password, right? So this enhances security, right? Or does it not? Think this through. How could this rule be enforced? So let us assume that a user changes his or her password or sets his initial password. The user types in the old password and a new password, which unfortunately some other user, has already chosen. So there must be some innocuous dialogue popping up, requiring the user to pick another password. And the dialogue cannot be: “Your password is not rules’ compliant. Please do not pick the password of another user!” Because if the user knows that he has found a valid password for one of the users, all she or he has to do is trying to logon via each and every user (there are scripting tools that will spare attackers the burden of typing) and the just found password nicely bypassing all the problems related to dictionary attacks. This user trying to log on with a valid password, will not cause any user to be locked by too many false password attempts, as only one attempt per user is made. So the last requirement, lock users with too many false logon attempts, will never kick in. So this requirement is actually rendering security worse and should not be implemented.
I have had quite a few interesting security requirements in my career, which I had to talk customers out of implementing. In fact I am sure that none of the major applications from all software vendors support this requirement. Such requirements do not make it often into the security guidelines at companies, but once in a blue moon you get it.
Whether you are a Security Expert at a company, a Security Consultant helping with implementations or a Product Owner developing secure software, my recommendation is to think things through. And do not always follow what the market tells you. Sometimes you really have to talk people out of a requirement.