The current stored password algorithm hashes the user’s cleartext password, the project code, and the user name with SHA-1. This will defeat a rainbow table, but it means the security of this scheme relies solely on the complexity of executing a preimage attack.
Today such an attack would cost about $700k, assuming you’re using publicly known techniques: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html Maybe others have better techniques. Are there Fossil passwords worth that much? I think so, and the cost is continually falling. Replacing SHA-1 with $BetterHash would help, but to execute such an attack, you have to have access to the Fossil server. If you have that, I don’t see why it isn’t less work to just replace the Fossil binary with one that invalidates all cookies and saves the plaintext password from the HTTP login transaction somewhere. There are algorithms that allow the server to verify a password without storing either it or its hash, and which do not require that the password be transmitted in plaintext: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism There are C and JavaScript implementations of both protocols, readily found with a search engine. That’s as much as I know about this. I have not tried to implement either one. I’m purposely not covering HTTPS here since the attack requires local access to the server, so HTTPS doesn’t help. That said, SRP and SCRAM remove the need to use HTTPS in the first place, at least for maintaining password security in the face of a MITM attack. You should still use HTTPS, though, since a MITM could substitute bad deltas into a checkin, for example. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
