mirror of
https://github.com/zulip/zulip.git
synced 2025-11-11 09:27:43 +00:00
edfa3eabfd
This is what the Sphinx docs recommend when you actually don't want the page to be included in navigation: http://www.sphinx-doc.org/en/stable/markup/toctree.html And now that we have `eval_rst`, we're able to take advantage of it! One difference between doing this and the old way of making "hidden" toctree entries is that with the latter, the "previous" and "next" links at the bottom of each page would thread through the hidden entries; which gets kind of confusing when they don't appear in the nav.
60 lines
2.8 KiB
Markdown
60 lines
2.8 KiB
Markdown
```eval_rst
|
|
:orphan:
|
|
```
|
|
|
|
# Password strength
|
|
|
|
When a user tries to set a password, we use [zxcvbn][zxcvbn] to check
|
|
that it isn't a weak one.
|
|
|
|
See discussion in [our main docs for server
|
|
admins](../production/security-model.html#passwords). This doc explains in more
|
|
detail how we set the default threshold (`PASSWORD_MIN_GUESSES`) we use.
|
|
|
|
First, read the doc section there. (It's short.)
|
|
|
|
Then, the CACM article ["Passwords and the Evolution of Imperfect
|
|
Authentication"][BHOS15] is comprehensive, educational, and readable,
|
|
and is especially recommended.
|
|
|
|
The CACM article is convincing that password requirements should be
|
|
set to make passwords withstand an online attack, but not an offline
|
|
one. Offline attacks are much less common, and there is a wide gap in
|
|
the level of password strength required to beat them vs that for
|
|
online attacks -- and therefore in the level of user frustration that
|
|
such a requirement would cause.
|
|
|
|
On top of that, estimating strength rapidly becomes more expensive
|
|
at high levels, in both space (for lists of tokens to try) and time.
|
|
As a result, in order to fit in a few MB of download and a few ms of
|
|
check time, zxcvbn focuses on the range of online attacks, for the
|
|
upper limit of which it uses 10^6 (apparently based on the offhand
|
|
estimate of "perhaps one million guesses" in the CACM article.)
|
|
|
|
Figure 3 of [the zxcvbn paper][zxcvbn-paper] shows that in fact
|
|
overestimation (allowing a weak password) sharply degrades at 100k
|
|
guesses, while underestimation (rejecting a strong password) jumps up
|
|
just after 10k guesses, and grows steadily thereafter.
|
|
|
|
Moreover, the [Yahoo study][Bon12] shows that resistance to even 1M
|
|
guesses is more than nearly half of users accomplish with a freely
|
|
chosen password, and 100k is too much for about 20%. (See Figure 6.)
|
|
It doesn't make sense for a Zulip server to try to educate or push so
|
|
many users far beyond the security practices they're accustomed to; in
|
|
the few environments where users can be expected to work much harder
|
|
for security, local server admins can raise the threshold accordingly.
|
|
Or, more likely, they already have a single-sign-on system in use for
|
|
most everything else in their organization, and will disable password
|
|
auth in Zulip entirely in favor of using that.
|
|
|
|
Our threshold of 10k guesses provides significant protection against
|
|
online attacks, and quite strong protection with appropriate
|
|
rate-limiting. On the other hand it stays within the range where
|
|
zxcvbn rarely underestimates the strength of a password too severely,
|
|
and only about 10% of users do worse than this without prompting.
|
|
|
|
[zxcvbn]: https://github.com/dropbox/zxcvbn
|
|
[BHOS15]: http://www.cl.cam.ac.uk/~fms27/papers/2015-BonneauHerOorSta-passwords.pdf
|
|
[zxcvbn-paper]: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_wheeler.pdf
|
|
[Bon12]: http://ieeexplore.ieee.org/document/6234435/
|