<commit_before># Security model

This section attempts to document the Zulip security model.  It likely
does not cover every issue; if there are details you're curious about,
please feel free to ask questions in [#production
help](https://chat.zulip.org/#narrow/stream/31-production-help) on the
[Zulip community server](../contributing/chat-zulip-org.md) (or if you
think you've found a security bug, please report it to
<EMAIL> so we can do a responsible security
announcement).

## Secure your Zulip server like your email server

* It's reasonable to think about security for a Zulip server like you
  do security for a team email server -- only trusted individuals
  within an organization should have shell access to the server.

  In particular, anyone with root access to a Zulip application server
  or Zulip database server, or with access to the `zulip` user on a
  Zulip application server, has complete control over the Zulip
  installation and all of its data (so they can read messages, modify
  history, etc.).  It would be difficult or impossible to avoid this,
  because the server needs access to the data to support features
  expected of a group chat system like the ability to search the
  entire message history, and thus someone with control over the
  server has access to that data as well.

## Encryption and authentication

* Traffic between clients (web, desktop and mobile) and the Zulip
  server is encrypted using HTTPS.  By default, all Zulip services
  talk to each other either via a localhost connection or using an
  encrypted SSL connection.

* Zulip requires CSRF tokens in all interactions with the web API to
  prevent CSRF attacks.

* The preferred way to log in to Zulip is using an SSO solution like
  Google auth, LDAP, or similar, but Zulip also supports password
  authentication.  See
  [the authentication methods documentation](../production/authentication-methods.md)
  for details on Zulip's available authentication methods.

### Passwords

Zulip stores user passwords using the standard PBKDF2 algorithm.

When the user is choosing a password, Zulip checks the password's
strength using the popular [zxcvbn][zxcvbn] library.  Weak passwords
are rejected, and strong passwords encouraged.  The minimum password
strength allowed is controlled by two settings in<commit_msg>docs: Document password hashing change from PBKDF2 to Argon2.<commit_after># Security model

This section attempts to document the Zulip security model.  It likely
does not cover every issue; if there are details you're curious about,
please feel free to ask questions in [#production
help](https://chat.zulip.org/#narrow/stream/31-production-help) on the
[Zulip community server](../contributing/chat-zulip-org.md) (or if you
think you've found a security bug, please report it to
<EMAIL> so we can do a responsible security
announcement).

## Secure your Zulip server like your email server

* It's reasonable to think about security for a Zulip server like you
  do security for a team email server -- only trusted individuals
  within an organization should have shell access to the server.

  In particular, anyone with root access to a Zulip application server
  or Zulip database server, or with access to the `zulip` user on a
  Zulip application server, has complete control over the Zulip
  installation and all of its data (so they can read messages, modify
  history, etc.).  It would be difficult or impossible to avoid this,
  because the server needs access to the data to support features
  expected of a group chat system like the ability to search the
  entire message history, and thus someone with control over the
  server has access to that data as well.

## Encryption and authentication

* Traffic between clients (web, desktop and mobile) and the Zulip
  server is encrypted using HTTPS.  By default, all Zulip services
  talk to each other either via a localhost connection or using an
  encrypted SSL connection.

* Zulip requires CSRF tokens in all interactions with the web API to
  prevent CSRF attacks.

* The preferred way to log in to Zulip is using an SSO solution like
  Google auth, LDAP, or similar, but Zulip also supports password
  authentication.  See
  [the authentication methods documentation](../production/authentication-methods.md)
  for details on Zulip's available authentication methods.

### Passwords

Zulip stores user passwords using the standard Argon2 and PBKDF2
algorithms.  Argon2 is used for all new and changed passwords as of
Zulip Server 1.6.0, but legacy PBKDF2 passwords that were last changed
before the 1.6.0 upgrade are still supported.

When the user is choosing a password, Zulip checks the password's
strength using the popular [zxcvbn][zxcvbn] library.  Weak passwords
are rejected, and strong passwords encouraged.  The minimum password
strength allowed is controlled by two settings in
{'fraction_non_alphanumeric': 0.04423510137210731, 'fraction_numerical': 0.003481466311693631, 'mean_word_length': 4.326063249727372, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3931350', 'n_tokens_mistral': 1277, 'n_tokens_neox': 1236, 'n_words': 708}