Suppose you did have a pre-image attack against SHA1 that worked in one millisecond. How would this help you to break into a Fossil system?

But leaks of databases containing passwords is rather common occurence

The password hash in fossil hashes against 3 components: the user name, their password, and a repository-local secret (random bytes which differ for every clone of a given repo). Thus having a hashes password doesn't help you brute-force crack it unless you also know the repo-specific secret. The only way to get the repo's secret is to have direct access to it (not a clone), and direct access to any secure system essentially trumps any and all security measures.

Yes, passwords still use SHA1, but... so what? git still uses SHA1 exclusively.

Users may not regard repository files for public projects as sensitive informatinon. ... They can put backups in publically accessible storage.

As soon as someone does that, all bets are off: physical access always trumps security measures.

Users may not regard repository files for public projects as sensitive informatinon. They can put a backup (not clone) of repo on flash drive and carry it around for someone to steal.

Then it goes back to Richard's question: can you crack it? If not, it's a moot point and not worth expending development/documentation effort on.

AFAIK repository-local secret doesn't help that much, since you can't get hashes without also getting access to secret.

That's true about access, i believe, but i'm not enlightened enough on the voodoo of hash-cracking to say whether the secret is truly irrelevant.

From marketing perspective, I see sha1 for passwords, I think that project doesn't value security, I go away.

And yet here you are ;).

Even if decision is reached not to change hashes, it probably should be documented in docs with reasons of that decision so people would consider whether fossil's threat model match their one.

i'll leave that discussion/decision to those who understand the potential risks/odds better than i do, e.g. Richard and Warren.

From marketing perspective, I see sha1 for passwords, I think that project doesn't value security, I go away.

And yet here you are ;).

And anonymously, may I add.

I see that the pattern continues.

From marketing perspective, I see sha1 for passwords, I think that project doesn't value security,

That's the crux of the issue, isn't it. This is not a security problem; this is marketing and buzz-word compliance problem.

I forgot to mention earlier that, despite the "SHA1" in the name, the algorithm is not really SHA1, but the enhance SHA1 developed by Marc Stevens which is immune to the shattered attack and its kin. But, that doesn't really matter does it. Because this is not about truth, but about marketing and buzz-words.

OK, then. I will see what I can do about providing a migration path from using SHA1 in the USER table to using SHA3-256 instead. For most people the upgrade will be seamless and painless. But for a few individuals will upgrade, change passwords, then downgrade to an earlier version of Fossil that does not support SHA3 password hashes. Those folks will encounter grief. To those innocent souls, I apologize in advance...

a migration path from using SHA1 in the USER table to using SHA3-256 instead

It can be basically the same as for Fossil 2.0: existing double salted and hashed passphrases stay the same, but when the length indicates 256 bits of hash, you know it must be the new algorithm.

I don't see that Fossil's current usage of SHA-1 here presents any particular problem. I advocated for the move to SHA-3 for repo artifacts because they're distributed to everyone who can clone or browse via /info links and such, so they're exposed to client-side attack. That is only the case for user.pw column values if you've given out Setup privileges to untrustworthy people, or your remote server is deeply compromised. Either way, you have bigger problems than Fossil's passphrase hashing algorithm.

The current double-salting scheme prevents use of rainbow tables, so only brute-force guessing is practicable. Even with all of SHA-1's known weaknesses, that currently means you're talking about an effort to guess a single password on the order of the entire PC-class computing budget of the planet for a day, according to some quick Fermi estimations I've made.

That result only applies under optimal password cracking conditions: you've broken into the remote Fossil server and have a copy of column user.pw to crunch on locally. As others have said, if you have that, you've probably got the ability to just overwrite the password to the value of your own choice...or steal or alter the Fossil-managed data directly.

If you're guessing from afar, HTTP round-trip delays and processing overhead from handling each hit will increase that by orders of magnitude. You'd probably notice a years-long DDoS of all computers in the world banging on your server in parallel.

If even that isn't enough, set up fail2ban against a recent version of Fossil to reduce the guess rate to a handful per 5 minutes, making guessing essentially impossible.

It might be nice to have some PBKDF2 style key-stretching in the new algorithm, with the iteration count being either a random admin-configurable value or computed somehow to put it into the right range. For an example of the latter, you could find the first 14-bit value in the project code beginning with a 1, resulting in a random iteration count between 8192 and 16383, inclusive, giving an additional 13 bits of key length and some server-side processing delay to make both remote guessing and rainbow table generation even more costly.

My thoughts on it: if Richard, Stephan, Andy (both of them) or Warren thought it was an issue, it would have been handled by now.

My thoughts on it: if Richard, Stephan, Andy (both of them) or Warren thought it was an issue, it would have been handled by now.

With the caveat that i am certainly the least security-aware/security-conscious of that group! All of the others have demonstrated far more enlightenment in that area.