summaryrefslogtreecommitdiff
path: root/doc/plugins/contrib/unixauth
diff options
context:
space:
mode:
authorJoey Hess <joey@kodama.kitenet.net>2008-07-29 16:19:53 -0400
committerJoey Hess <joey@kodama.kitenet.net>2008-07-29 16:19:53 -0400
commite2612c7873a9bbc79e9c250e700d634792570e59 (patch)
tree04f2437efee569146008fc1879b59eecdaa615dd /doc/plugins/contrib/unixauth
parentb8d3c83ee048100aca2311ad1bd0d190d07ed10e (diff)
on the security of this plugin..
Diffstat (limited to 'doc/plugins/contrib/unixauth')
-rw-r--r--doc/plugins/contrib/unixauth/discussion.mdwn17
1 files changed, 17 insertions, 0 deletions
diff --git a/doc/plugins/contrib/unixauth/discussion.mdwn b/doc/plugins/contrib/unixauth/discussion.mdwn
new file mode 100644
index 000000000..162e5d323
--- /dev/null
+++ b/doc/plugins/contrib/unixauth/discussion.mdwn
@@ -0,0 +1,17 @@
+The security of this plugin scares me. As noted in the plugin
+documentation, you basically have to use it with SSL, since snooping on the
+login password doesn't give you an essentially useless account -- it gives
+you an actual account on the machine!
+
+Also, apparently pwauth defers *all* auth attempts if one fails, and it
+does this by using a lock file, and sleeping after a failed auth attempt.
+Which is needed to avoid brute-forcing, since this is a significant
+password.. but how will that interact with ikiwiki? Well, ikiwiki _also_
+uses a lock file. So, at a minimum, someone can not only try to brute-force
+the pwauth password, but the ikiwiki processes that stack up due to that
+will also keep ikiwiki's lock held. Which basically DOSes the wiki for
+everyone else; noone else can try to log in, or log out, or edit a page,
+all of which require taking the lock.
+
+So I don't think I'll be accepting this plugin into ikiwiki itself..
+--[[Joey]]