gitlab-rails to create a token for a user, and as part of that we have
and the generated tokens seem to work. But now I’ve discovered that
Gitlab::CryptoHelper.sha256 returns different values on different servers (but the same on our two load-balanced production servers). I even see it between different test instances (using
kitchen) on my laptop, that each run the same version (we haven’t upgraded the production servers to 16.2.4 yet).
Can somebody explain that to me?
Luckily GitLab is open core, and we use CE (so all open source), so I could just check the source code. It wasn’t hard to find the code for
Gitlab::CryptoHelper.sha256, it looks like
salt = Settings.attr_encrypted_db_key_base_truncated
so the answer is simply that
Gitlab::CryptoHelper.sha256 is not a simple hash calculator, but includes a salt.
That salt seems to be a setting (i.e. something constant on a given instance) so it’s probably safe to rely on.
In principle I’m for adding a salt anywhere that you calculate the hash of a password, but it’s a bit hard to see what it actually gives in this case (so I probably wouldn’t have cared) - the standard explanation would point out that you now can’t recognise tokens across installations, but if an attacker has hashed tokens from multiple installations, I think there’s a bigger issue somewhere.
Now I would just like to know where/how
Settings.attr_encrypted_db_key_base_truncated can be found so I can add an automated test that the token is generated correctly.