Rainbow Attack Risk?

[bedeho]

We're struggling to fully understand one of the implementation details provided in the Hedgehog library documentation which relates to the database schema and the risk of a rainbow table attack.

In this documentation, it is recommended that Authentications and Users data should be stored separately, with no relation between the two tables. This separation is suggested to mitigate the susceptibility to a rainbow table attack if the data in these tables is ever exposed. To provide the exact quote:

It's important that the username is not stored in the Authentications table because the lookupKey is a scrypt hash of a predefined iv with an username and password combination. If the data in these tables were ever exposed, susceptibility of a rainbow table attack could increase because the password is the only unknown property. 

The suggested database schema is therefore:

Authentications:
    lookupKey (PRIMARY KEY)
    cipherIv
    cipherText

Users:
    username (PRIMARY KEY)
    walletAddress
    # ... other user data

However, after carefully reading the documentation we've came to the following understanding:

1. If there were a data breach, and an attacker gained access to both Users and Authentications tables, they would have knowledge of all valid usernames and the public addresses of the wallets associated with these usernames (from the Users table).

2. The lookupKey is scrypt(username + password + lookupKeySalt), where lookupKeySalt is a predefined constant hardcoded in the Hedgehog library. The attacker can easily gain access this constant. Knowing it, they can try to guess the password for any username from the Users table and calculate a lookupKey accordingly. If they succeed in guessing a password correctly, they will find a matching lookupKey in the Authentications table.

3. Having guessed the lookupKey which has an associated entry in the Authentications table, the attacker would also get cipherIv, and cipherText. The attacker can therefore decrypt the cipherText using scrypt(password + cipherIv) (the cipherKey) and cipherIv, as they now know the password.

If our understanding is correct, this implies that if the data from both Authentications and Users tables leaks, password would be the only uknown property for the attacker trying to access the encrypted seeds, regardless of whether the Users and Authentications data is stored together or not.

We are therefore wondering how the susceptibility to a rainbow table attack is decreased by separating these tables and what's the exact attack scenario where this separation provides additional security benefits. Could you please elaborate on that?

[bedeho]

Credit goes to @leszek for writeup