You want Salt with your Fries?

Last week, there were a few new "Q drops", and for a while there was a kerfuffle having to do with "salt rotation." Here's what that was about--and it's a red herring.

Here's the story about passwords, salts, hashes, and tripcodes, to the best of my understanding. Feel free to reply in the comments if you have more or different details.

The 8kun servers (the place where “Q” goes to post) have a user database for authentication that contains three things that are compared at the time of login: a username U (suppose for this example, U ="Q") a unique random string of letters and numbers S called a "salt" (which is different for each user) and a cryptographic hash value H which is some cryptographic function H = f ( password, salt ) .

Here, "f" just means "some function of" and f ( password, salt) means “some function involving the password and the salt.”

Would you like some salt on your hash?

Let’s assume for the sake of argument that the Hash function uses the cryptographic algorithm SHA-256 (it’s not terribly important for this discussion, but this is a common one these days.)

What this SHA-256 hashing function does is a 'one-way' computation so that SHA-256( input string ) creates as a result of the computation some long output string of cryptographic gobbledygook that we call a “Hash value”; and it's virtually impossible, if you are given this string of gobbledygook, to reverse the calculation process to figure out what original string generated it (you can’t hack and recover the original password.)

It’s also the case that no two strings (if they are different from each other) will ever give you the same hash output. Well, OK, not never, but it’s at least extremely unlikely in once in trillion-trillion odds kind of way. So effectively “never”.

This means, if you have the hash output value, you cannot "work backwards" to figure out the original password and salt combination--even if you happen to know the salt value somehow.

We'll use H= f(P,S) for this from now on: it just means "Hash function of the password and salt combined". The whole idea of using salts in combination with passwords is that it makes rainbow table attacks (a method of cracking password tables that are stolen from servers) next to impossible because even if two users happen to choose the same password as each other (which would render them vulnerable to rainbow table attacks, because their hash values would be the same), the salt that gets added to each password before hashing is randomized, so that the Hash that each account gets assigned after calculating the SHA-256 function is still unique and different.

A key point here is that your actual password is *never* stored in this database on the server; only you know and supply it at the time of login, and it's only stored momentarily in memory at the time of login (if even then; there are new login methods that never even send it across the network even once.)

If it is stored, it is kept just long enough to recompute the Hash--and then immediately discarded. It is the Hash that is later compared.

On the 8kun servers then, only the username (U), salt (S), and hash (H) are kept in a database (U, S, H). They can be kept in this database either encrypted, or in plaintext; it doesn't matter all that much. They're typically kept in plaintext format.

Let's call the Hash that is kept after first computing H( P, S ) = "Hstored".

When you login, your password is combined again at the moment of login with the stored salt, the password is obliterated from memory in the server, and Hnow = f ( P, S) is computed again.

The server then compares two things:

1. is the Username given equal to the U that we kept in the database? AND…

2. is Hnow = Hstored? (i.e., are the hashes of the password combined with salts the same?)

If the answer is yes, you're considered logged in; then the 8kun server computes another function Trip T = f (U, H, S). This becomes your “tripcode”, which is displayed to other users next to your username on 8kun. All it means is “this is a verified authentic user.” The tripcode is itself a form of a “hash” in the sense that it is unlikely that any two users password hash + salts would generate the same tripcode.

Here's the thing: the 8kun servers *cannot* change the salt value S ("salt rotation") while you are logged out; because the server does NOT have your password P, and therefore cannot recompute H = f (P,S) to store a new value for H. There's no way to store the new salt S and new Hash without knowing your password P--and they don't have it!

Therefore, when salt rotation DOES happen (which just means a new random salt value S is chosen) this happens AT THE TIME YOU NEXT LOGIN. Then the new values (U, H, and S) can be stored in the database for future authentication. Some systems do this once a year, for example. Some never change the salt.

If Q didn't login from Dec 2020 until now, then the salt CANNOT have been changed. The 8kun admins might have set things up to change salts for other users, who did login during an interval when salt-rotation was enabled. That just means at some particular time when those users logged in, a new salt was chosen FOR THEM, and a new Hash H was calculated and tucked away FOR THEM for subsequent logins.

But the 8kun syadmins DO NOT WANT the salt for "Q" to be changed, anyway; because then the tripcode would be changed, since it is calculated from Trip T = f ( U, H, S.) The "Q" community relies on that tripcode as a "seal of authenticity" to try to differentiate "valid Q drops" from fake ones. So it needs to be kept intact.

It turns out there is minimal value in "rotating the salt" anyway; it doesn't help all that much, but it doesn't hurt, so if it is done, it is done ONLY AFTER A SUCCESSFUL LOGIN.

To prevent that account from having its salt changed (and thus the tripcode altered) the admins simply "whitelisted" the account, meaning "for this one account, don't periodically refresh the salt even after a login". This might otherwise occur once a year, for example.

For this reason, the whole salt topic for the Q account is a red herring. It couldn’t have happened without Q having logged in sometime since the last drop was posted.

What we can say, with a fair degree of confidence, is that whoever recently logged into 8kun to post as "Q" at least knew the password that was used back in December of 2020. We cannot know if that is the same person or group of people; we cannot know if someone "sold off" the password and its now known by someone else.

We can also say with confidence that if the tripcode was somehow “faked”, it can only have been the (presumably trusted) sysAdmins at 8kun who could have done it.

Because we can assert that the same password was used, it’s reasonable to speculate that the recent Q may be the same as the old Q.

Other confirmation will hopefully be forthcoming in the context of "Q proofs". But for now, this is what we know about passwords and salts.