On Oct 11, 2018, at 12:06 AM, Random Coder <random.co...@gmail.com> wrote: > > On Wed, Oct 10, 2018 at 3:45 PM Warren Young <war...@etr-usa.com> wrote: >> The salt is the project code combined with the user ID, not a secret >> per-user salt. Both of those values are publicly visible, but it does >> defeat rainbow table attacks, which is the main point of salting. > > This does not prevent new rainbow tables from being generated
Since part of the salt is the user name, that requires a “rainbow table” per user, which means it isn’t much of a rainbow table at all. Basically, it devolves to a brute-force hash attack. > You're using a single iteration of the (technically insecure) hash > function to generate the password If you take the faux “rainbow table” approach — which again is really just brute force in this case — the known weaknesses in SHA-1 don’t matter. You still have to generate half of the SHA-1 possibilities on average to brute force one of these passwords. In [one experiment][1] a single large GPU generated SHA-1 hashes at a rate of 160 million per second. To generate 2^80 hashes (half the SHA-1 space) you’d need 4.6x10^39 seconds, or about 1.45x10^32 years. Current top-end GPUs are about twice as fast as the one used in that experiment, and you could rack a bunch of those up, but even a time reduction of 1000x doesn’t make the attack practical. Instead, you might try to take advantage of the SHA-1 weaknesses to generate a second preimage, which in this case amounts to a password that happens to work even though it isn’t actually the password known to the legitimate user. I have no idea how difficult that is, but it’s probably still awfully difficult. To pull that off, you need a copy of the user table, which is not synchronized down to clones unless you’re the Fossil “setup” user, who is all-powerful and doesn’t need to resort to such things to break into the repository in the first place. An attacker without such privileges would have to break into the server hosting the Fossil instance, at which point he wouldn’t *need* to break the password hash: he could just modify the user table directly! [1]: https://security.stackexchange.com/a/3450 > creating a rainbow table is much > less computationally hard than if a modern password hashing function > had been used. Okay, so replace the algorithm with N-thousand rounds of PBKDF2 and whatever hash algo you like. How does it practically change what I’ve said above? > I'd be curious if someone's taken the effort to setup hashcat with > your rule set What rules? As I said, Fossil currently has no restrictions on the password. Fossil assumes you will use good passwords for purely selfish reasons, and don’t need to be forced to do so. And again, hashcat is a silly way to attack Fossil. If you have access to the Fossil user table, you can just edit the database and insert whatever hash you like. Or, insert content directly into the block chain. Or add users with arbitrary permissions. Or... The primary attack the Fossil password system fends off is the remote one, which is gated by the maximum number of password tries allowed per second. I don’t know of any internal limits on this in Fossil, so it amounts to the maximum number of HTTP connections the host machine can process per second, which will be orders of magnitude lower than the hash rates above. If that still bothers you, put Fossil behind an HTTP proxy and set up fail2ban on the access log. With 5 passwords allowed per user per second, an 8 character random password takes decades to break. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
