Hardening an old SRP3 protocol setup

Question

This is the situation: client-server login is done via SRP3, hash used is single SHA1. Client cannot be modified but server can (open source). Because of this, all hashed passwords in the database are only SHA1. Server got hacked several times already and whole database leaked, passwords were broken.

To my understanding for SRP3 to work correctly both client and server need to use the same hashing alghoritm so I can't switch SHA1 with bcrypt or anything like that. What are my options to harden the hashes on server side?

score 1 · Accepted Answer · edited Oct 07 '21 at 06:47

With the server must store a "password verifier" with a special structure; in SRP 3 (the one described in RFC 2945), this is described this way:

The host stores user passwords as triplets of the form

    { <username>, <password verifier>, <salt> }

Password entries are generated as follows:

    <salt> = random()
    x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
    <password verifier> = v = g^x % N

The protocol cannot work if the server does not have v or the salt because the server must send the salt to the client (in the initial steps of the protocol) and must use v not long afterwards. Therefore, regardless of what the server actually stores, the server must know enough to retrieve or recompute the salt and v in a fraction of a second. An attacker who obtains a complete copy of the server will be able to do the same, and get to the salt and v, allowing for a fast brute force attack on the password (fast because the computation of v, given the salt, username and a putative password, implies only a couple SHA-1 and a modular exponentiation).

So the only hope is to find a way for attackers to not obtain a complete copy of the server. Namely, symmetrically encrypt the data which is stored, with a key which you will then store "elsewhere", and pray for the best. For instance, most breaches of the "SQL injection" persuasion allow for the attacker to grab a more or less full copy of the server data as stored in the database, but does not (immediately) allow for reading arbitrary files outside of the database. If the server stores the symmetric encryption key in a file, and use that key to encrypt the relevant fields in the database (namely, the v values), then attackers who only get a dump of the database will be defeated.

A variant is to setup an extra internal server who stores the salt and v values. Your main server would talk to that secondary server. It would then be up to that secondary server to detect attempts at exhaustive pumping of all values, should the main server be totally hijacked by attackers. At least, the physical separation would protect the sensitive values (salt and v) from SQL injections and similar breaches.

There is little more you can do without modifying the client.

Hardening an old SRP3 protocol setup

1 Answers1