Salt Reuse + Hash Collisions

[LandonPowell]

The Hash function you're using for your 6 char tripcodes is comically vulnerable.

Salt Reuse:

Attack to gain server-side salt:

Generate 10 legit hashes yourself, which you will know the password (but not the salt) to.

Brute forcefully generate salts until you find one which allows all 10 of your password hashes to resolve correctly.

The attacker only needs to know that one doesn't work before skipping to the next possible salt.

If your sysadmin fails to have a randomly generated salt, you can substitute brute-force for dictionary.

Hash Collisions:

Collisions alone nearly guarantee someone to guess every other user's trip after about 16 billion runs of the function.

Simple Solution:

Generate salt based on (username + config.salt). Also has issues, but at least now every user has a salt of their own.

Good Solution:

Generate a salt for each username and save it locally. Authenticate users properly, not by telling the end-user to read and remember a bunch of random characters for each user.

Useful Information:

https://crackstation.net/hashing-security.htm#salt

[AndrewBelt]

Brute forcefully generate salts until you find one which allows all 10 of your password hashes to resolve correctly.

This would take several ages of the universe to crack, for the size of the salt I'm using.

Collisions alone nearly guarantee someone to guess every other user's trip after about 16 billion runs of the function.

Because of the rate limiter, you can only evaluate a trip from a password at least every 2 seconds, so it would take 1,000 years to find a collision based on your estimated number of runs.

Generate salt based on (username + config.salt). Also has issues, but at least now every user has a salt of their own.

Usernames should be independent of your tripcode, so you can switch usernames and still verify your identity.

Generate a salt for each username and save it locally. Authenticate users properly, not by telling the end-user to read and remember a bunch of random characters for each user.

This is how tripcodes have worked with every imageboard for two decades and nobody has had a problem with them. Feel free to fork hack.chat and write your own solution.

[ghost]

based vortico

[LandonPowell]

Because of the rate limiter, you can only evaluate a trip from a password at least every 2 seconds, so it would take 1,000 years to find a collision based on your estimated number of runs.

You show trip-codes publicly. Please reread what I said. It's all proposed that I'll do these things from my home computer. You can't rate limit me if I'm not actively connected to your website.

This would take several ages of the universe to crack, for the size of the salt I'm using.

I doubt this very highly. Please note that SHA256 can be increased in speed by a magnitude of 20x using a cheap consumer GPU. It might take a month, at most, and at that point, you'll have gained access to everyone's account.

This is how tripcodes have worked with every imageboard for two decades and nobody has had a problem with them. Feel free to fork hack.chat and write your own solution.

Tripcodes on commercial imageboards such as 4chan are notorious for being cracked and stolen when a tripcode user gets someone mad at them.

Your single point of failure is your salt. If a user is able to get access to that, they are seconds away from having any tripcode they want. Even if your salt is infinitely secure, simply gaining access to a plaintext file on your server, your config file, is enough to compromise your entire system. What you're doing is tantamount to storing passwords in plaintext.

[ghost]

i use sha512 on my instance tbh

[ghost]

and the config doesnt show salt

[ghost]

bassicly, off yourself you fucking autist

[AndrewBelt]

You show trip-codes publicly. Please reread what I said. It's all proposed that I'll do these things from my home computer. You can't rate limit me if I'm not actively connected to your website.

You can't evaluate the (correct) tripcode unless you have the salt in config.json

I doubt this very highly. Please note that SHA256 can be increased in speed by a magnitude of 20x using a cheap consumer GPU.

My salt has 300 bits of entropy or something.

Tripcodes on commercial imageboards such as 4chan are notorious for being cracked and stolen when a tripcode user gets someone mad at them.

I misspoke---hack.chat tripcodes are like "secure tripcodes". You're talking about the ones with no hash. If a secure tripcode password has been stolen, either the salt was stolen or the password was stolen directly by other means.

simply gaining access to a plaintext file on your server, your config file, is enough to compromise your entire system

If you can gain access to my config.js, you've already compromised my system.

[LandonPowell]

@AndrewBelt

My salt has 300 bits of entropy or something.

That isn't sufficient for a shared salt. Nothing is sufficient for a shared salt, because attackers can feasibly spend years trying to steal your salt on their local machines since the reward is so high.

You're talking about the ones with no hash.

...what?

If you can gain access to my config.js, you've already compromised my system.

You're going to piss off someone with access to your server, like a dickish sysadmin, and you'll be fucked long-term.

Most of these apply to your current implementation:

http://stackoverflow.com/questions/1197417/why-are-plain-text-passwords-bad-and-how-do-i-convince-my-boss-that-his-treasur

If you're still not convinced, I'll just stop wasting both our time.

@nanotechxz

And the config doesn't show the salt.

Yes it does. https://github.com/AndrewBelt/hack.chat/blob/master/config-sample.json#L10 You can use the 'edit' feature on GitHub to append more things to your posts, so no need to make a bunch of new ones. 😄

[AndrewBelt]

No, debating is fine, but I think we understand the system differently.

attackers can feasibly spend years trying to steal your salt on their local machines since the reward is so high.

But before I continue on this point, I'd like to ask you to do an practical calculation of the "cost" required to acquire someone's tripcode, and/or the server salt.

Here's an example of an imageboard which supports both basic tripcodes, and "secure" tripcodes. https://www.4chan.org/faq#sectrip

You're going to piss off someone with access to your server, like a dickish sysadmin, and you'll be fucked long-term.

I'm the only admin.

Most of these apply to your current implementation:

No they don't. Which ones do you think apply?