Sitecore for Developers

Sitecore UserName & Password Hardening

by Brijesh Patel 5/7/2017

All organizations have processes & procedures in place to reduce the surface of vulnerability. One of the way to reduce attacks typically includes having a password policy and Sitecore Experience Platform is no exception to it. The way by which one installs Sitecore and configure has a significant effect on the security of a website. Sitecore has in place a fair amount of documentation related to Security Hardening and Sitecore Security Hardening Guide. Recently I was working on a Request For Proposal (RFP) which had lot of questionnaire related to password policy, I was aware that password policy can be enforced for Sitecore but was not satisfied that I have complete details and specifics to implement the password policy.

This blog post is about a voyage “Sitecore Username & Password Hardening” during which I drilled down the information for various settings and options available in Sitecore related to username and password policy implementations. If you are interested to harden a Sitecore implementation join me on this voyage and keeping reading the blog post further.

There are good number of documents & blogs, see “Nice Reads” section of this post for all such details.

Let’s start with some fundamentals to be aware about,

  1. Sitecore uses .NET security engine and is built on top of .Net Membership Provider
  2. All information related to roles, users, passwords and access is stored into “core” database. Hah! Why am I writing this should this not be known? Well trying to share information and making sure I cover all audiences for the post from including starters, mid-level and experienced Sitecore geeks.
  3. It is possible to replace or extend default configurations by writing a custom provider.

Let’s start with some specifics now,

UserName

Jason’s post USING EMAIL ADDRESSES AS YOUR SITECORE USERNAME is almost a clone of Brian’s post Sitecore allow email adress as user name

Rhys Godfrey’s post Sitecore–Changing the Username validation rule is all you have to understand for setting by UserName Validation.

I do not want to bombard duplicated information.

Password

Q. Have you been asked to setup and enforce password policy?

Q. How to configure it for Sitecore?

Q. Where to start?

A. Here’s the answer, as said earlier Sitecore is built on .Net Membership provider start by looking <configuration>/ <system.web>/<membership> section of a web.config file on your Sitecore installation.

Q. What I need to look for?

A. The “sql” provider and the attributes of the provider.

AttributesValue TypeminRequiredPasswordLengthintminRequiredNonalphanumericCharactersintrequiresQuestionAndAnswerboolrequiresUniqueEmailboolmaxInvalidPasswordAttemptsint passwordAttemptWindowintenablePasswordRetrievalboolpasswordFormatstringpasswordStrengthRegularExpressionstring

 

  • minRequiredPasswordLength : The attribute name itself is self-explanatory, it allows to specific the minimum number of character a password should have. The default value is 1 and of-course it cannot be 0 otherwise you will see below error,

What happens when some tries to setup password where length is less than minimum required?

Sitecore displays message and makes you aware of possible reasons,

  • minRequiredNonalphanumericCharacters: Specify minimum number of non-alphanumeric characters a password must contain.
  • requiresQuestionAndAnswer: Sitecore do not support this attribute and setting it to true will not allow for creation of a new user.

  • requiresUniqueEmail : Validates if there is already another user with same email address or not. If found New User will not be created and a message will be displayed.

  • maxInvalidPasswordAttempts: User will be locked out after sur-passing the number of times an incorrect password is specified for login to Sitecore.

Sitecore login page do not specifically mentions about the user being locked out.

The information for a “Locked Out” user is available in User Manager,

  • passwordAttemptWindow

The PasswordAttemptWindow property works in conjunction with the MaxInvalidPasswordAttempts property to help guard against an unwanted source guessing the password or password answer of a membership user through repeated attempts. When a user attempts to log in with, change, or reset his or her password, only a certain number of consecutive attempts are allowed within a specified time window. The length of this time window is specified in the PasswordAttemptWindow property, which identifies the number of minutes allowed between invalid attempts.If the number of consecutive failed attempts that a user makes to reset his or her password equals the value stored in the MaxInvalidPasswordAttempts property, and the time elapsed since the last invalid attempt is less than the number of minutes specified in the PasswordAttemptWindow property, then the membership user is locked out. The user is locked out by setting the IsLockedOut property to true until the user is unlocked by a call to the UnlockUser method.If the interval between the current failed attempt and the last failed attempt is greater than the PasswordAttemptWindow property setting, the current invalid attempt is counted as the first. If a valid password answer is supplied before the maximum number of allowed invalid attempts is reached, the count of invalid password-answer attempts is set to 0 (zero). If a valid password is supplied before the maximum number of allowed invalid attempts is reached, the count of invalid password attempts and the count of invalid password-answer attempts are set to 0 (zero).So for example if the values set for the attributes are maxInvalidPasswordAttempts="5" passwordAttemptWindow="1”. A user will be locked out after he makes 5 unsuccessful attempts. If the user has made less 4 unsuccessful attempts and then he/she tries after “passwordAttemptWindow” (in our example 1 minute) the user will not be locked out as the attempt would have been set to 0 counter.

  • enablePasswordRetrieval
  • This attribute holds a value indicating whether the current membership provider is configured to allow users to retrieve their password. Default value is false and if you turn it on you might see below error as this attribute works in conjunction with passwordFormat.
  • passwordFormat
  • This attribute describes the encryption format for storing passwords for users. The values can be,
    Attribute ValueDescriptionClearNot secure, do not use. Passwords are not encrypted.EncryptedNot secure, do not use. Passwords are encrypted using the encryption settings determined by the machineKey Element (ASP.NET Settings Schema) element configuration.HashedPasswords are encrypted one-way using the SHA1 hashing algorithm.

    Hashed is the default one!

    How does it looks in Membership database (MS SQL) when these formats are changed?

    Below image is for “Clear” format

  • Below image is for “Encrypted” format
  • passwordStrengthRegularExpression
  • The PasswordStrengthRegularExpression property gets the regular expression used to evaluate password complexity from the provider specified in the Provider property. This is one of the most important attribute that would allow to implement strict password policy and set various rules related to passwords like,
    • Is greater than seven characters.
    • Contains at least one digit.
    • Contains at least one special (non-alphanumeric) character.

    All the above attributes are considered while a user is being setup into Sitecore from User Manager. Sitecore Login page ignores these attributes and just validates if the username and password is correct which make sense as otherwise consider a case that users were already setup and later on password policy was enforced to have at least one non-aplhanumeric character. Such users will not be able to login even if their password matches to whatever it’s is stored in database.

    I collected information related to sql provider from Membership Class and if you are looking for more information here is the place where you should watch out for.

    Nice Reads

You might also like