FreeLists / dokuwiki / [dokuwiki] Re: DokuWiki BugTracker: [LDAP] getUserData fails if no$conf[bindpw] (1053)

["Steenhagen, Jacob" <Jacob.Steenhagen@xxxxxxxxxxxxx>]

> that is not true. The password is stored encrypted in the
> session cookie and can be decrypted by dokuwiki.

Quite honestly, this concerns me. Yes, I know it's encrypted and the
salt is stored in a secured directory on the server, but cookie contents
are transmitted in the clear every time a page is requested. Also,
cookie contents can be stored in the browser. There are also numerous
ways to steal cookies other than packet sniffing such as XSS and browser
vulnerabilities. Because of this, it's generally recommended that
passwords not be stored in cookies but instead that a unique session ID
be generated and tracked.

I was also going to say something about the load on the Auth server (in
my case LDAP server) by having to authenticate the user for every visit,
but apparently the cookie information w/the password is used as a
session cookie which would keep the load off the third party auth
server. It shouldn't be too much work (famous last words) to transition
that to a session cookie that doesn't contain the password. The only
side effects should be that DokuWiki can't do it's silent reauth when
the session info is missing and the hack mentioned in the parent to this
thread
(http://www.freelists.org/archives/dokuwiki/02-2008/msg00064.html) won't
work.
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist