91c59ff1d0bafc5b070bde01ab9c201e8b6849ab
[ikiwiki.git] / doc / plugins / contrib / unixauth / discussion.mdwn
1 The security of this plugin scares me. As noted in the plugin
2 documentation, you basically have to use it with SSL, since snooping on the
3 login password doesn't give you an essentially useless account -- it gives
4 you an actual account on the machine!
5
6 Also, apparently pwauth defers *all* auth attempts if one fails, and it
7 does this by using a lock file, and sleeping after a failed auth attempt.
8 Which is needed to avoid brute-forcing, since this is a significant
9 password.. but how will that interact with ikiwiki? Well, ikiwiki _also_
10 uses a lock file. So, at a minimum, someone can not only try to brute-force
11 the pwauth password, but the ikiwiki processes that stack up due to that
12 will also keep ikiwiki's lock held. Which basically DOSes the wiki for
13 everyone else; noone else can try to log in, or log out, or edit a page,
14 all of which require taking the lock.
15
16 So I don't think I'll be accepting this plugin into ikiwiki itself..
17 --[[Joey]]
18
19 Thanks for the comments. That's definitely an undesirable interaction between pwauth and ikiwiki; in my current application it wouldn't be a serious problem, but I'd like this plugin to be general-purpose and safe enough for inclusion in ikiwiki. It's the system-users-are-wiki-users idea I'm married to here, not pwauth itself; can you suggest another approach I might take?
20 -- [[schmonz]]
21
22 > Have you considered using [[plugins/httpauth]] and then the appropriate apache module?  There are apache modules like [mod_authnz_external](http://unixpapa.com/mod_auth_external.html) that might help.  The advantage of these solutions is that they usually make the security implications explicit.  -- Will