I agree with your conclusions. for my part I'm just glad that my password is not stored in plain text in the fossil database - especially when I don't control the repository. I know that the transmissions are no more secure than before.
many people, for better or worse, reuse usernames and passwords at other online portals. i wouldn't want someone to inspect the reopository and try my username and password at other online portals. rw from my mobile 434.851.1612 On Jan 10, 2010, at 6:32 AM, "Twylite" <twyl...@crypt.co.za> wrote: > > Hi, >> Do the same thing as at present, in that the client sends the >> password hashed >> and not in cleartext. >> >> The server takes that hashed value and the user name, hashes again >> (perhaps >> with a different algorithm) and compares to what it has stored. >> Neither the >> original password (stored in the local machine or entered by the >> user) nor >> the value sent on the wire (first hash) are stored in the server. >> > Cryptographically this is equivalent to sending a cleartext password > over HTTP and storing a hash of the password. > > C: username, password --> S > S: compute H(salt, username, password) and compare against stored hash > > What you are proposing is to substitute password = H(password) in the > above protocol. If you can sniff the interaction then you will > recover > H(password), which is sufficient for you to log in to the server. The > only thing this change buys you is that the attacker would need a > modified client (so that he can enter H(password) directly, instead of > entering password). > > The existing (now "old") fossil protocol secures the wire interaction > against compromise. It is generally believed that it is easier to > sniff > HTTP traffic than the compromise a server and retrieve a file with > passwords. > > Also, unless I am misunderstanding drh's followup message, the "new" > fossil protocol is similarly no more secure that the old protocol, > just > very slightly more irritating for an attacker. Instead of the client > and server sharing the secret cleartext password p, they share the > secret hash H(p). If you can compromise the server then you know the > shared secret H(p), and can use it with a small modification to the > client. > > The only way to solve this problem - securing both the wire and the > server storage - is to move to a more advanced cryptographic protocol > (preferably asymmetric crypto). That is not workable however, as it > would leave no way to log on through the web interface (which is > limited > to the mechanisms reasonably supported by browsers). Fossil is not > alone in this dilemma. > > Regards, > Twylite > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
