Snowflake Password and Session Policies

Strong sign-in rules protect an account from guessing and from unattended computers. Password policies set how long and complex a password must be. Session policies decide how long a signed-in session may sit idle before Snowflake asks the user to sign in again. Both policies close small gaps that attackers look for.

The House Key Comparison

A house key works best when copies stay few and the lock changes after a loss. Doors need to lock when everyone leaves the room. A password policy plays the role of the key rules: how complex, how old, how many wrong tries. A session policy plays the role of the auto-lock when nobody touches the door for a while.

TWO POLICY LAYERS
=================

 SIGN-IN                              AFTER SIGN-IN
 +----------------------+             +----------------------------+
 | PASSWORD POLICY      |             | SESSION POLICY             |
 | length, mix, age,    |  ------>    | idle timeout in worksheets |
 | retry limit, history |             | and in client tools        |
 +----------------------+             +----------------------------+

Creating a Password Policy

CREATE PASSWORD POLICY governance.policies.strong_password
  PASSWORD_MIN_LENGTH          = 14
  PASSWORD_MAX_LENGTH          = 64
  PASSWORD_MIN_UPPER_CASE_CHARS = 1
  PASSWORD_MIN_LOWER_CASE_CHARS = 1
  PASSWORD_MIN_NUMERIC_CHARS   = 1
  PASSWORD_MIN_SPECIAL_CHARS   = 1
  PASSWORD_MAX_AGE_DAYS        = 90
  PASSWORD_MAX_RETRIES         = 5
  PASSWORD_LOCKOUT_TIME_MINS   = 30
  PASSWORD_HISTORY             = 5
  COMMENT = 'Company standard for human users';
SETTING                          WHAT IT CONTROLS
-------------------------------  ----------------------------------------
PASSWORD_MIN_LENGTH              Shortest allowed password
PASSWORD_MIN_*_CHARS             Required mix of letter, digit, symbol types
PASSWORD_MAX_AGE_DAYS            Days before a change is required
PASSWORD_MAX_RETRIES             Wrong attempts before lockout
PASSWORD_LOCKOUT_TIME_MINS       Length of the lockout
PASSWORD_HISTORY                 Number of old passwords that cannot repeat

Applying a Password Policy

-- Whole account
ALTER ACCOUNT SET PASSWORD POLICY governance.policies.strong_password;

-- One user with a different rule
ALTER USER legacy_tool_user SET PASSWORD POLICY governance.policies.relaxed_password;

-- See where a policy applies
SELECT * FROM TABLE(INFORMATION_SCHEMA.POLICY_REFERENCES(
  POLICY_NAME => 'GOVERNANCE.POLICIES.STRONG_PASSWORD'));

A user-level policy overrides the account-level policy for that user. Existing passwords stay valid until the following change, so announce the new rules and set a deadline.

Creating a Session Policy

CREATE SESSION POLICY governance.policies.idle_timeout
  SESSION_IDLE_TIMEOUT_MINS    = 30
  SESSION_UI_IDLE_TIMEOUT_MINS = 15
  COMMENT = 'Sign out idle users';

ALTER ACCOUNT SET SESSION POLICY governance.policies.idle_timeout;

-- A stricter rule for administrators
ALTER USER admin_user SET SESSION POLICY governance.policies.admin_idle;

The first value covers programmatic clients, such as SnowSQL and drivers. The second value covers the Snowsight web interface. Short web timeouts protect against a forgotten browser tab on a shared computer.

Which Rules Suit Which Users

USER GROUP         PASSWORD RULE                SESSION RULE
-----------------  ---------------------------  ------------------
Administrators     Strongest, plus MFA          Short timeout
Analysts           Standard policy, plus SSO    Standard timeout
Service users      No password, use key pair    Not applicable
Contractors        Standard policy, short age   Short timeout

Single sign-on users follow the identity provider's password rules in place of Snowflake's. Password policies matter for the users who still sign in with Snowflake passwords.

Good Habits

  • Pair password policies with MFA for every administrator.
  • Choose long passwords over frequent forced changes; length protects more than complexity tricks.
  • Keep policies in a governance schema with a clear owner.
  • Test a policy on one user before applying it account wide.
  • Review LOGIN_HISTORY for repeated lockouts that signal attacks or confused users.

A Practical Scenario

A security audit finds that analysts keep Snowsight tabs open overnight on shared office computers. The security lead creates a session policy with a 15-minute web timeout and applies it to the account. A password policy with a minimum length of 14 follows. Support tickets rise for a week and settle, and the following audit passes without comment on either item.

Frequently Asked Questions

Do password policies affect single sign-on users?

Single sign-on users authenticate with the identity provider, so the provider's rules apply. Snowflake password policies govern users who sign in with a Snowflake password.

How do I unlock a user after too many wrong tries?

The lockout ends after the configured number of minutes. An administrator can reset the lock earlier through the user's properties, and should confirm the person's identity first.

Does a session policy end a running query?

The policy measures idle time between user actions. A query that runs for a long period continues, and the session timeout applies after activity stops.

Rollout Advice

Announce a new password policy two weeks before enforcement. Share the exact rules, explain how to change a password in Snowsight, and name a contact for lockout help. Smooth communication prevents a flood of support requests on the first day.

Key Points

  • Password policies control length, mix, age, retries, lockout, and history.
  • Session policies end idle sessions in tools and in Snowsight.
  • Account policies cover everyone, and user policies override them.
  • Keep these policies alongside MFA, SSO, and network policies.
  • Test with one user before account-wide rollout.
Previous lesson
Back to course
Next lesson