Given a scenario, identify the risks and mitigation strategies that session security and Two-Factor Authentication enable (E.g. High Assurance Sessions, 2FA, etc.).

Session Security

  • Session security is used to limit exposure to network when a user leaves the computer unattended while still logged in. It limits the risk of internal attacks, such as one employee tries to use another employee’s session.
  • Session timeout
    • Control inactive user session expiry from Session settings page. Default value is 2 hours. When the enabled timeout reaches users are prompted with a dialog to logout or continue working. If they do not respond they are logged out.
    • When user closes a browser or tab, they are not automatically logged out of their Salesforce session.
  • TLS
    • By default, Salesforce uses Transport Layer Security and require secure connections (HTTPS) for all communication.
    • The Require secure connections (HTTPS) setting determines TLS is required for access to Salesforce and it is suggested to keep this enabled. This setting does not apply to API requests. All API requests require HTTPS. To enable HTTPS on communities and Salesforce Sites, see HSTS for Sites and Communities. The Reset Passwords for Your Users page can only be accessed using HTTPS.
  • Session Security Level
    • Restrict certain types of resources based on the level of security associated with the authentication method for the user’s current session. Each login has one of two such security levels: Standard and High Assurance. We can define policies so that specified resources are available only to users assigned with a High Assurance level.
    • For sensitive operations, require a high-assurance level of security, or block users altogether. If users already have a high-assurance session after logging in, they aren’t prompted to reverify their identity in the same session, even if you require high assurance for these operations.
    • By Default all the authentication methods (Username and Password, Delegated Authentication, Activation, Lightning Login, Passwordless Login, Authentication Provider, SAML) have a default value of Standard except Two-Factor Authentication.
    • Be cautious about changing the security level of Two-Factor Authentication to Standard. If Two-Factor Authentication has a Standard level, but the user profile setting Session security level required at login requires a High Assurance session security level, the user can’t log in. User access is blocked when the high assurance requirement isn’t met.
    • The security level for a SAML session can also be specified using the SessionLevel attribute of the SAML assertion sent by the identity provider. The attribute can take one of two values, STANDARD or HIGH_ASSURANCE.
    • This can be changed using Session Security Levels in Session Settings page.
    • Reports and dashboards(from Access Policies Page) in Salesforce and connected apps (from Connected App) use session-level security. You can set policies requiring High Assurance on these types of resources. You can also specify an action to take when the session used to access the resource is not High Assurance. The supported actions are:
      • Block—Blocks access to the resource by showing an insufficient privileges error.
      • Raise session level—Prompts users to complete two-factor authentication. When users authenticate successfully, they can access the resource. For reports and dashboards, you can apply this action when users access reports or dashboards, or just when they export and print them.
    • Raising the session level to high assurance by redirecting the user to complete two-factor authentication is not a supported action in Lightning Experience. If your org enabled Lightning Experience, and you set a policy that requires a high-assurance session to access reports and dashboards, Lightning Experience users with a standard session are blocked from reports and dashboards. Also, they don’t see the icons for these resources in the navigation menu. As a workaround, users with a standard assurance session can log out and log in again using an authentication method that is defined as high assurance for their org. Then they have access to reports and dashboards. Or, they can switch to Salesforce Classic, where they’re prompted to raise the session level when they attempt to access reports and dashboards.
    • Session levels have no impact on resources in the app other than connected apps, reports, and dashboards for which explicit security policies have been defined
  • Enable caching and autocomplete on login page, Enable user switching and Remember me until logout can control whether org stores user logins and whether they can appear from the Switcher.
  • Require HttpOnly attribute restricts session ID cookie access. A cookie with the HttpOnly attribute is not accessible via non-HTTP methods such as calls from JavaScript. This setting may impact custom or packaged application that uses JavaScript to access Session ID cookies.
  • Disabling secure and persistent browser caching has a significant negative performance impact on Lightning Experience. Only disable in the following scenarios:
    • Your company’s policy doesn’t allow browser caching, even if the data is encrypted.
    • During development in a sandbox or Developer Edition org to see the effect of any code changes without needing to empty the secure cache.
  • Referrer URL Protection
    • When loading assets outside of Salesforce or navigating outside of Salesforce, the referrer header shows only Salesforce.com or Force.com rather than the entire URL. This feature eliminates the potential for a referrer header to reveal sensitive information that could be present in a full URL, such as an org ID. This feature is supported only for Chrome and Firefox.
  • Public Key Pinning
    • To detect man-in-the-middle attacks, Salesforce now monitors which SSL certificates users can see. Custom certificates aren’t affected. Public key pinning is supported only for Chrome and Firefox.
  • Trusted IP Ranges from Set up → Network Access
    • define a list of IP addresses from which users can log in without receiving a login challenge for verification of their identity, such as a code sent to their mobile phone.
    • this does not restrict access, entirely, for users outside of the Trusted IP Range
  • Identity Verification from Set up → Identity
    • can control how and when users are prompted to verify their identity.
    • Some of these settings can also be configured from Session Settings
    • Under Session Security Level Policies, raise the session security level to high assurance, or block users.
      • Reports and Dashboards—Controls access to reports and dashboards. This setting is also available on the Reports and Dashboards Access Policies page. You can change this setting in either location.
      • Manage Encryption Keys—Controls access to the Platform Encryption page, the Certificate and Key Management Setup page, and the TenantSecret object.
      • Manage Auth. Providers—Controls access to the Auth. Providers page, the User Details Setup page, and the AuthProvider object.
      • Manage Certificates—Controls access to the Certificate and Key Management Setup page, Single Sign-On Settings Setup page, and the Certificate object.
      • Manage Connected Apps—Controls access to the Connected Apps Setup pages and to creating Connected Apps through the App Manager Setup page.
      • Manage Data Export—Controls access to the Data Export Setup page.
      • Manage IP Addresses—Controls access to the Network Access Setup page.
      • Manage Login Access Policies—Controls access to the Login Access Policies Setup page.
      • Manage Password Policies—Controls access to the Password Policies Setup page and profile details.
      • Manage Permission Sets and Profiles—Controls access to the Permission Sets and Profile Setup pages and related objects.
      • Manage Roles—Controls access to the Roles Setup page, the UserRole object, and the Role object in Metadata API.
      • Manage Sharing—Controls access to the Sharing Settings Setup page, the SharingRules object, and the CustomObject’s sharingModel field in Metadata API.
      • Manage Two-Factor Authentication in API—Controls access to the VerificationHistory, TwoFactorInfo, and TwoFactorTempCode objects.
      • Manage Two-Factor Authentication in User Interface—Controls access to the Identity Verification History Setup page and the VerificationHistory, TwoFactorInfo, and TwoFactorTempCode objects.
      • Unlock Users and Reset Passwords—Controls permission to reset passwords and unlock users on the Users Setup page.
      • View Event Log Files—Controls access to the EventLogFile object.
      • View Health Check—Controls access to the Health Check Setup page.
    • User Session Types
      • Session types indicate the type of session a user is using to access your org. Session types can be persistent or temporary. You can access them by using the user interface, API, or other methods, such as an OAuth authentication process.

References

Leave a Reply

Your email address will not be published. Required fields are marked *