> 2011/9/29 Lluís Batlle i Rossell <virik...@gmail.com>
> Well, if someone has studied those attacks, and the code by dmitry looks fine
> and works based on some heavier studies than our first thoughts on that, let's
> use it. No?
>
> i can't object, i just think it's paranoid :).
Well, it is paranoid, yes :-) I'm overly paranoid about everything concerning
security. Evidence: it was unnecessary to do constant-time comparison of hashes
in xfer.c.
I'm mostly concerted about cookies, as it's impossible to time non-plain-text
passwords -- the attacker simply cannot supply passwords which, when hashed,
have a few bytes of hash modified (that is, when you supply "password", the
server looks for "5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8" in the database,
it's impossible [at least now, with SHA-1] to supply such password which hash
has, say, "5baa61" in the beginning, but a different ending).
However, due to the use of plain-text passwords in the old versions and
compatibility with them, it is currently possible to supply password hash (if
you know project-id) instead of the password:
uid = db_int(0,
"SELECT uid FROM user"
" WHERE login=%Q"
" AND length(cap)>0 AND length(pw)>0"
" AND login NOT IN ('anonymous','nobody','developer','reader')"
" AND (pw=%Q OR pw=%Q)",
zUsername, zPasswd, zSha1Pw
);
Once we get rid of plain-text passwords, we no longer need constant-time
comparison functions in password-handling code. That leaves cookies, which are
just a 25-byte random blob + project-code + login, and Fossil searches for that
blob in database.
--
Dmitry Chestnykh
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
