mirror of https://github.com/zulip/zulip.git
0c2cc41d2e
A bug in Zulip's new user signup process meant that users who registered their account using social authentication (e.g. GitHub or Google SSO) in an organization that also allows password authentication could have their personal API key stolen by an unprivileged attacker, allowing nearly full access to the user's account. Zulip versions between 1.7.0 and 2.0.6 were affected. This commit fixes the original bug and also contains a database migration to fix any users with corrupt `password` fields in the database as a result of the bug. Out of an abundance of caution (and to protect the users of any installations that delay applying this commit), the migration also resets the API keys of any users where Zulip's logs cannot prove the user's API key was not previously stolen via this bug. Resetting those API keys will be inconvenient for users: * Users of the Zulip mobile and terminal apps whose API keys are reset will be logged out and need to login again. * Users using their personal API keys for any other reason will need to re-fetch their personal API key. We discovered this bug internally and don't believe it was disclosed prior to our publishing it through this commit. Because the algorithm for determining which users might have been affected is very conservative, many users who were never at risk will have their API keys reset by this migration. To avoid this on self-hosted installations that have always used e.g. LDAP authentication, we skip resetting API keys on installations that don't have password authentication enabled. System administrators on installations that used to have email authentication enabled, but no longer do, should temporarily enable EmailAuthBackend before applying this migration. The migration also records which users had their passwords or API keys reset in the usual RealmAuditLog table. |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| custom_check.py | ||
| exclude.py | ||
| pep8.py | ||
| pyflakes.py | ||