On Wed, Oct 10, 2018 at 3:45 PM Warren Young <war...@etr-usa.com> wrote: > Fossil currently has no restrictions on password length[1] or content. The > input text is simply salted, hashed, and inserted into the user table: > [...] > 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, and since: https://fossil-scm.org/fossil/file?udc=1&ln=436-441&filename=src%2Fsha1.c You're using a single iteration of the (technically insecure) hash function to generate the password, creating a rainbow table is much less computationally hard than if a modern password hashing function had been used. I'd be curious if someone's taken the effort to setup hashcat with your rule set and see how quickly it can brute force it's way to the plaintext. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users