3 ms·

The author links to a page that describes how the developer password (used in the web interface) is stored in the database in plain text. Is that still the cas

The author links to a page that describes how the developer password (used in the web interface) is stored in the database in plain text. Is that still the case? (I sure hope not!)

de6u99er 4y ago
The article is from 2016. I doubt passwords are still stored in plaintext.
- sgbeal 4y ago
  > The article is from 2016. I doubt passwords are still stored in plaintext. Fossil has not stored a plaintext password in many years (2008-ish). Only a one of the small handful of "first-generation" repositories has any chance whatsoever of having such a password (and only if the user has never updated their password since then).
- b3morales 4y ago
  This is fairly shocking for 2016 as well. It wasn't really that long ago.
schemescape 4y ago
It sounds like clear text is still supported, but new passwords are written as a SHA-1 hash of the password concatenated with user+database-specific strings (since 2010): https://fossil-scm.org/home/doc/trunk/www/password.wiki https://fossil-scm.org/home/doc/trunk/www/password.wiki That’s an improvement, but I doubt it’s best practice.
- chrismorgan 4y ago
  Ouch. A single round of SHA-1 means you can easily make over a million attempts per second on a single general-purpose processor, considerably more on GPUs or specialised hardware. Ignoring any of the other weaknesses of SHA-1, this means that if someone gets read-only access to the database, anything but a long random password will fall very quickly (like, probably within a few seconds).
  - sgbeal 4y ago
    > Ouch. A single round of SHA-1 means you can easily make over a million attempts per second on a single general-purpose processor... That's FUD: you cannot connect to a remote anywhere nearly that fast. Fossil's passwords are hashed in such a way that they are useless for any repository clone other than the one they were established on. Even if i manage to get your password hash, it doesn't do me any good unless i have physical access to the exact copy of the repository on which that password was initially stored/hashed, because only that copy has the secret key needed to reverse-engineer your password. Local physical access trumps any and all security measures.
    - chrismorgan 4y ago
      As I said later in the comment: if someone gets read-only access to the database. Certainly you won’t be able to guess that quickly through Fossil’s web interface. If you could, this would be a catastrophe. As it is, it’s only very bad. These sorts of things are all about defence in depth. Some have said: “What’s wrong with storing passwords in cleartext? No one else can access them anyway!” But then a bug in another part of your system allows exfiltration of the database. It’s that kind of thing. Weak password storage is also as much a problem for other systems as it is for one’s own system, due to password reuse. I gather from a little more research that current CPUs can probably do over ten million SHA-1 hashes per second (some extrapolation of old figures there), and consumer-grade GPUs over twenty trillion. This will crack even moderately strong passwords in a very short time. For comparison, Argon2 is designed as a proper password hash (resistant against acceleration) and its recommendation is to make passwords take a few hundred milliseconds to check (increasing the number of iterations as hardware gets faster). So maybe three per second, which basically renders any cracking whatsoever infeasible.

The author links to a page that describes how the developer password (used in the web interface) is stored in the database in plain text. Is that still the case? (I sure hope not!)

de6u99er 4y ago

The article is from 2016. I doubt passwords are still stored in plaintext.

sgbeal 4y ago
> The article is from 2016. I doubt passwords are still stored in plaintext. Fossil has not stored a plaintext password in many years (2008-ish). Only a one of the small handful of "first-generation" repositories has any chance whatsoever of having such a password (and only if the user has never updated their password since then).
b3morales 4y ago
This is fairly shocking for 2016 as well. It wasn't really that long ago.

schemescape 4y ago

It sounds like clear text is still supported, but new passwords are written as a SHA-1 hash of the password concatenated with user+database-specific strings (since 2010): https://fossil-scm.org/home/doc/trunk/www/password.wiki https://fossil-scm.org/home/doc/trunk/www/password.wiki That’s an improvement, but I doubt it’s best practice.

chrismorgan 4y ago
Ouch. A single round of SHA-1 means you can easily make over a million attempts per second on a single general-purpose processor, considerably more on GPUs or specialised hardware. Ignoring any of the other weaknesses of SHA-1, this means that if someone gets read-only access to the database, anything but a long random password will fall very quickly (like, probably within a few seconds).
- sgbeal 4y ago
  > Ouch. A single round of SHA-1 means you can easily make over a million attempts per second on a single general-purpose processor... That's FUD: you cannot connect to a remote anywhere nearly that fast. Fossil's passwords are hashed in such a way that they are useless for any repository clone other than the one they were established on. Even if i manage to get your password hash, it doesn't do me any good unless i have physical access to the exact copy of the repository on which that password was initially stored/hashed, because only that copy has the secret key needed to reverse-engineer your password. Local physical access trumps any and all security measures.
  - chrismorgan 4y ago
    As I said later in the comment: if someone gets read-only access to the database. Certainly you won’t be able to guess that quickly through Fossil’s web interface. If you could, this would be a catastrophe. As it is, it’s only very bad. These sorts of things are all about defence in depth. Some have said: “What’s wrong with storing passwords in cleartext? No one else can access them anyway!” But then a bug in another part of your system allows exfiltration of the database. It’s that kind of thing. Weak password storage is also as much a problem for other systems as it is for one’s own system, due to password reuse. I gather from a little more research that current CPUs can probably do over ten million SHA-1 hashes per second (some extrapolation of old figures there), and consumer-grade GPUs over twenty trillion. This will crack even moderately strong passwords in a very short time. For comparison, Argon2 is designed as a proper password hash (resistant against acceleration) and its recommendation is to make passwords take a few hundred milliseconds to check (increasing the number of iterations as hardware gets faster). So maybe three per second, which basically renders any cracking whatsoever infeasible.