Employ SRP as an authentication mechanism

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

  • Close this issue

Employ SRP as an authentication mechanism

Problem to solve

By employing SRP vs. hashed passwords we completely eliminate the possibility of exposing a user password, because the GitLab instance never sees the actual password.

Intended users

Everyone using GitLab as a user.

Further details

An overview of SRP (Secure remote password) can be found here and here

The main benefit as mentioned above is that through the use of SRP GitLab never actually gets the user's password, so there is no possibility to accidentally disclose it in logs etc. On another note 1Password also uses this

Proposal

Implement SRP, replacing the password login in the long run. Any newly created account or changed passwords should yield a password login to be invalidated and enrolling the SRP for that account.

The login requires a javascript on the login page that performs the SRP handshake with the server. In addition to that we need an API endpoint to fetch the status of an account (whether it is password based, or SRP based) That info is then used to either send the password to the server or perform the handshake. If we don’t care about round-trips we could also just always to the SRP handshake and return a specific code/error to then transparently send the password for authentication.

Once this feature is implemented there would be the need of a migration from hashed passwords to the SRP. That would work by forcing a one-time force password change which enrolls SRP.

Permissions and Security

This will greatly increase the overall security of the platform, because the best secret is one you don’t have.

Documentation

Testing

What does success look like, and how can we measure that?

Links / references

  • 1Password
  • Wikipedia on SRP
  • RFC 2945
  • Facebook incident
Edited Jun 29, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading