PREFACE: This post is part of the Zero to Hero series.
While most Admins struggle with the concepts of record access in Salesforce, many companies, and Admins grossly overlook Salesforce org security settings. Perhaps Admins don’t realize that there are some security features, and settings that can be enabled, or the business decides that some security measures are too cumbersome and impact usability.
Admins and organizations need to realize that Org level Security is at the whim of your users. The human element is something that we cannot fully control which is why it’s important to know the available security options built into Salesforce. No matter how much users may complain about the security hoops they need to jump through, the security of the companies data is the top priority.
Start With a Health Check
Available in the Winter ’16 release, Health Check provides an Administrator a dashboard where critical security issues are presented in an easy to read fashion, and an org security score to help Admins understand how the current security configuration measures against Salesforce’s recommended settings.
Here’s a quick video that explains this fantastic new feature.
Health Check makes it easy for Admins to find holes that need to be plugged and provides a starting point for System Security conversations in the organization.
Now, let’s look at some of the System Security settings that can be enabled in Salesforce.
Password Policies
SplashData, an identity management company, puts together a yearly list of the most used passwords and has found that people, no surprise, are horrible at protecting their accounts with difficult passwords. Just to show you how much people don’t care, here are the top five most used passwords in 2015:
- 123456
- password
- 12345678
- qwerty
- 12345
To see a full list of the top 25 most used passwords, check out this article. You’ll be shocked to see the lack of variety in the top 25!
It’s no wonder people are being hacked on a regular basis. But it’s not just humans who are to blame. Companies are as well. Many organizations don’t require complex passwords or encourage good password security settings. More than likely, your Salesforce org’s password policies need to be beefed up, and your users need to get more creative.
Let’s take a quick look at the password policies we can modify in Salesforce.
Expiration Dates
Every user password in Salesforce should be set to expire. There are a few exceptions I can think of which I’ll cover in a moment. Setting an expiration requires users to update their password on a regular basis. Unfortunately, users game the system and tend to rotate passwords or add an extra character or number to the end of their old passwords instead of creating something entirely new.
To determine the appropriate expiration length, talk with your IT or security team to determine if there is a company-wide policy related to passwords. If a policy doesn’t exist, you’ll need to review what data is in Salesforce and determine the appropriate expiration term. If for example, you’re housing Social Security Numbers in Salesforce or other important information, the expiration term may be shorter (and the passwords should be more complex, which we’ll touch on in a moment).
Never, never, never set this company-wide setting to “Never Expires.” If this is your default password expiration date, change it now. You’re putting your company information at risk.
There is only one use case I can think of where a user password should be set to “Never Expires” – if you’ve got a user account which is being used by an integration. This account should have its own Salesforce license (not tied to your specific Salesforce Admin account) and the password and security information should be well guarded and shared with only those that need access. If this use case exists, use a permission set to award the “Password Never Expires” system permission to the integration account.
Password History
Users hate this one. How many previous passwords will be remembered? Again depending on your business and the type of data in Salesforce, this setting may be set to the maximum of 24 passwords remembered – which means that a user would be unable to reuse the previous 24 passwords.
Most defaults allow for three remembered passwords, and this is probably sufficient for most organizations. But, just like Expiration Dates, the org should never have the “No passwords remembered” option selected. It’s just a bad security practice.
Minimum Password Length
The thought is that the longer the password string, the harder it will be to hack. Of course, there are other elements at play including the mixture of characters and the “randomness” of those characters, but password length is still an important part of the equation.
Salesforce default minimum length is eight characters. This is again sufficient for most companies but the minimum character set may need to be increased to ensure a more secure password. I can’t think of a reason why this setting would ever be reduced to less than eight.
Password Complexity
Okay, this setting is the one that users trip up on. Remember the top 5 most commonly used passwords? It’s because there isn’t a set complexity requirement on the password which allows the user to create super simple passwords which creates a huge security risk.
In my opinion, this setting should be set to the maximum complexity – and this should be true of all websites that require a password. I was recently creating an account on a website and tried to create a complex password using upper case letters, lower case letters, numbers, and special characters, and was told that the password cannot contain special characters! I found this very frustrating.
Let me just take a moment to plug LastPass here. My wife and I have been Premium members for a few years, and I literally can’t imagine living without it. Not only is it inexpensive at $12 per year, but it’s available on any device, and requires that I remember only one password! I use it to create complex, randomly generated passwords that are impossible to remember. If you aren’t using a password manager, click here to get started.
In addition to all of these password settings, Admins have the ability to expire all Salesforce passwords which would require all users to update and recreate their passwords.
Two-Factor Authentication
Coupled with robust password policies, two-factor authentication makes it extremely difficult for a hacker to access an account. By default, Salesforce’s security is risk-based. Salesforce uses cookies to determine if the computer is one that has been used to access the application before, and even known IP ranges to determine if the risk is high or low. Depending on that risk, users may be asked to provide additional information (generally a security code) upon logging in.
Wikipedia defines Two-Factor Authentication as “…a technology… that provides identification of users by means of the combination of two different components. These components may be something that the user knows, something that the user possesses or something that is inseparable from the user.”
By enabling two-factor authentication in Salesforce, users are required then to verify their identity by providing a 2nd verification key, which is above and beyond the risk-based verification.
Two-Factor authentication is becoming more common among consumer apps as well. May banks and websites (like Facebook and Google) offer two-factor authentication for their products which, when combined with a secure password, significantly reduces the risk of account hacking. I personally have two-factor activated on every account that supports it. You’ll be happy to know that not only do I not share your email addresses with anyone, but your emails are secured in MailChimp using a very complex password and two-factor authentication.
For a full list of companies and services that offer two-factor authentication from a consumer perspective, check out Two Factor Auth (2FA) website.
Enabling this feature for your Salesforce org is simple. It requires a permission set and the Salesforce Authentication mobile app. More information can be found here on Help & Training.
Session Settings
Session settings provide session-specific permissions for the Salesforce org. These settings determine things like how long a session can last (how long a user can be logged into Salesforce before being logged out and reconfirmed using a username and password); if IP restrictions will be used, and if SMS verification should be made available to users.
Typically, the default settings are sufficient, but it’s a good idea to review all of the session setting options and adjust according to your organization’s needs.
Login IP Ranges
There are two types of Login IP Ranges that can be applied to Salesforce, and each performs a separate function. Trusted IP Ranges are set for the
Trusted IP Ranges are set for the organization and are permissive. If Trusted IP Ranges are set for the office let’s say, and a user is in the office and attempts to login, the IP range is flagged as safe and the user is granted access, usually without additional verification.
Login IP Ranges are restrictive and prevents a user from logging in without verification (or at all). From a security perspective, users could be completed blocked from accessing Salesforce unless they are within a verified IP range. Great if you don’t want users accessing Salesforce on Starbuck’s free internet, for example.
User Deactivation Procedures
All of the security in the world isn’t sufficient if user accounts aren’t managed well. Access to Salesforce data is possible only with an active user account where the appropriate verification credentials are confirmed. Removing user access through account deactivation is a key part of the security process.
Salesforce Administrators should always be a part of a user termination checklist and be made aware of the appropriate termination date. Admins should always be prompt in deactivating user accounts in order to limit risk.
Sometimes, a user can’t be fully deactivated because they are tied to workflows or other business processes that require reattribution before deactivating the account. Admins can freeze a user’s account which removes login access but keeps the account active until a time when the appropriate updates can be made and the user’s account can be fully deactivated.
SalesforceA is a free mobile app that all Admins should have installed on their phones. It allows Admins the ability to manage user’s, permission sets and more all from your mobile device which means that you can freeze or deactivate users from anywhere!
Additional Resources
That was a lot of content! There’s still much more to system security that wasn’t covered here. If you’re interested in learning more about these topics or dive into additional topics that weren’t covered, here are some additional resources that will be helpful.
- Salesforce Security Part 1 – Record Access – Admin Hero
- Eliminating Salesforce Passwords with Lightning Login – Admin Hero
- User Authentication – Explore security features like two-factor authentication, custom domains, and single sign-on. – Trailhead
- Salesforce Security Guide – a PDF of this and other related content from Help & Training
- Introduction to the Salesforce Security Model – YouTube
- What’s Possible with Salesforce Data Access & Security – YouTube
- Security and the Salesforce Platform: Patchy Morning Fog Clearing to Midday – YouTube
Nice article.
LikeLike
A great refresher! Thanks Brent for taking the time to put this together.
LikeLike
Thanks Norm!
LikeLike
TYPO
Login IP Ranges are restrictive and prevents a user from logging in without verification (or at all). From a security perspective, users could be ****completed***** blocked from accessing Salesforce unless they are within a verified IP range.
It should be completely
LikeLike
Between Salesforce Security Part I and Part II, I found Part I more helpful and informative.
LikeLike
Nice article Brent. I believe in Spring ’16, some security feature was strengthened – my users seem to get asked to enter a security code more often than normal. Do you have any details on that?
LikeLike
Hi Andy! I don’t recall reading that, but looking at the release notes, there does appear to be some enhancements to security. Here are the details around security updates on the Release Notes. Check out the “Control Session Security Level for Device Activation” section – it may (or may not) apply. https://releasenotes.docs.salesforce.com/en-us/spring16/release-notes/rn_security_auth.htm?edition=&impact=
LikeLike
22. In a master-child relationship between a standard object and custom object
which of the following statements is NOT true? Please select two (2) items.
a. The standard object is always the master
b. The custom object is always the master
c. The custom object is always a child
d. The standard or custom object can be a master
e. The standard object is never a child
I think it is a and b
would appreciate some help on the same.
LikeLike