[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 7 Jun 2013 23:09:17 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: wiki upgrade (was: OT: HTTPS for openwall.info?)
On Tue, Mar 12, 2013 at 02:10:03AM +0400, Solar Designer wrote:
> BTW, DokuWiki uses md5crypt (at least the version we have deployed).
> If we were serious about improving the security of our wiki, we'd need
> to patch that, but frankly I don't bother. Irresponsible of me? In a
> way, yes, but there are just so many other things to spend time on.
>
> If anyone wants to review what password hashes new versions of DokuWiki
> use, and maybe patch that (perhaps to use phpass, which would default to
> bcrypt on recent PHP) and submit the patch upstream, feel free to work
> on that. It'd make more of a difference for the world at large than
> patching or/and SSL'ing our one DokuWiki install.
I've upgraded DokuWiki on http://openwall.info/wiki/ and
http://oss-security.openwall.org/wiki/ to dokuwiki-2013-05-10 with the
captcha plugin added and with some local modifications. Turns out this
version supports bcrypt, as long as PHP supports bcrypt. So I've
enabled bcrypt hashes. Also, turns out this new version of DokuWiki
still generates ridiculously weak passwords, such as for new users.
I've now patched this in a quick-n-dirty way:
function auth_pwgen() {
$pw = `pwqgen`;
if (strlen($pw) > 10 && substr($pw, -1) === "\n")
return substr($pw, 0, -1);
Yes, this is fail-open (unfortunately), and it is followed by the
original broken implementation, which relies on rand() (included here
for amusement):
$pw = '';
$c = 'bcdfghjklmnprstvwz'; //consonants except hard to speak ones
$v = 'aeiou'; //vowels
$a = $c.$v; //both
//use two syllables...
for($i = 0; $i < 2; $i++) {
$pw .= $c[rand(0, strlen($c) - 1)];
$pw .= $v[rand(0, strlen($v) - 1)];
$pw .= $a[rand(0, strlen($a) - 1)];
}
//... and add a nice number
$pw .= rand(10, 99);
return $pw;
}
Hopefully, fallbacks to this broken implementation won't be happening on
our server frequently, and hopefully the issue will be patched properly
in upstream code soon.
Someone may create a JtR external mode that would quickly iterate over
all possible DokuWiki-generated passwords (for certain versions of PHP).
This would be similar to the existing "Strip" external mode.
Another detail possibly worth mentioning: for backwards compatibility,
on the openwall.info wiki (and only on this one) I added the relativens
plugin, which makes internal links of the form namespace/link (that is,
not starting with "/" nor ":", yet containing "/" inside them) treated
as relative links. I patched this plugin so that it applies to links
that use "/" only, and not to those that use ":". This weirdness
appears to match the behavior of the much older DokuWiki version that we
had before. Without it, many links on at least 3 pages (and probably
more) would be broken. (On the oss-security wiki, I identified only one
such link, so I edited that one link instead.)
--- relativens.orig/syntax.php 2008-12-31 11:59:02 -0800
+++ relativens.hack/syntax.php 2013-06-07 12:01:43 -0700
@@ -64,7 +64,7 @@
// Sadly excluding the non internal links is a complicated process
// and we end up doing it twice, but at least the results of these
// handle functions are cached.
- if($isMedia || $this->isLinkInternal($linkTrimmed)) {
+ if(!preg_match('/^[^|]*:/', $originalMatch) && ($isMedia || $this->isLinkInternal($linkTrimmed))) {
// unless it's explicitly absolute,
// Make it look like relative
$modifiedMatch = preg_replace('/(^(?:\[\[|\{\{)\s*)(?![\:\/])/', '\\1./', $modifiedMatch, 1);
If you identify any issues with the wikis, especially those likely
caused by the recent upgrade, please let me know.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
