Change Details

To make the WMF more resilient to compromise, move all password hashes for CentralAuth accounts out of the main centralauth database and into a database only accessible from a single authentication service. The service will need to handle, * Password authentication ** by implication, it will need to handle new account creation and password resets too * Creating and authenticating temporary / forgotten-password tokens * (possibly) tokens * (possibly) alerting on anomalous request behavior The service should store password hashes in a format that is no weaker than they are currently stored in CentralAuth. The service needs high availability (since it will be used for password logins, and possibly token logins) * Anticipated load: https://grafana.wikimedia.org/dashboard/db/authentications (<50 minute)

### Background MediaWiki has a modular authentication component (AuthManager), for which the default implementation stores account credentials in the local database of that site. The password component is also configurable and flexible, allowing for smooth migration to ever better encryption algos as the industry standard evolves over time (e.g. {T216682}). Today, the CentralAuth extension registers an AuthManager implementation that stores account credentials in a separate and centralised database instead. This database (MySQL/MariaDB) is responsible for storing and retreiving password hashes. Validation of password hashes happens inside the MediaWiki password component, which means MediaWiki requires read access to this database. ### Problem statement If malicious code were to execute on the MediaWiki web servers, any of its databases could be read and leaked, including the separated centralauth database. To make Wikimedia Foundation sites more resilient to compromise, we CentralAuth should validate submitted login credentials against the database, without the ability to batch-read the hashes themselves from the underlying database. ### 2015 Proposal >>! **Original task description** by @csteipp: > > Move all password hashes for CentralAuth accounts out of the main centralauth database and into a database only accessible from a single authentication service. > > The service will need to handle, > * Password authentication > ** by implication, it will need to handle new account creation and password resets too > * Creating and authenticating temporary / forgotten-password tokens > * (possibly) tokens > * (possibly) alerting on anomalous request behavior > > The service should store password hashes in a format that is no weaker than they are currently stored in CentralAuth. > > The service needs high availability (since it will be used for password logins, and possibly token logins) > * Anticipated load: https://grafana.wikimedia.org/dashboard/db/authentications (<50 minute)

To make the WMF more resilient to compromise, move all password hashes for CentralAuth accounts out of the main centralauth database and into a database only accessible from a single authentication service.### Background The service will need to handle,MediaWiki has a modular authentication component (AuthManager), for which the default implementation stores account credentials in the local database of that site. The password component is also configurable and flexible, allowing for smooth migration to ever better encryption algos as the industry standard evolves over time (e.g. {T216682}). Today, the CentralAuth extension registers an AuthManager implementation that stores account credentials in a separate and centralised database instead. This database (MySQL/MariaDB) is responsible for storing and retreiving password hashes. Validation of password hashes happens inside the MediaWiki password component, which means MediaWiki requires read access to this database. ### Problem statement If malicious code were to execute on the MediaWiki web servers, any of its databases could be read and leaked, including the separated centralauth database. To make Wikimedia Foundation sites more resilient to compromise, we CentralAuth should validate submitted login credentials against the database, without the ability to batch-read the hashes themselves from the underlying database. ### 2015 Proposal >>! **Original task description** by @csteipp: * Password authentication> ** by implication, it will need to handle new account creation and password resets too> Move all password hashes for CentralAuth accounts out of the main centralauth database and into a database only accessible from a single authentication service. * Creating and authenticating temporary / forgotten-password tokens> > The service will need to handle, * (possibly) tokens> * Password authentication * (possibly) alerting on anomalous request behavior The service should store password hashes in a format that is no weaker than they are currently stored in CentralAuth. The service needs high availability (since it will be used for password logins, and possibly token logins)> ** by implication, it will need to handle new account creation and password resets too > * Creating and authenticating temporary / forgotten-password tokens > * (possibly) tokens > * (possibly) alerting on anomalous request behavior > > The service should store password hashes in a format that is no weaker than they are currently stored in CentralAuth. > > The service needs high availability (since it will be used for password logins, and possibly token logins) > * Anticipated load: https://grafana.wikimedia.org/dashboard/db/authentications (<50 minute)