https://bugzilla.wikimedia.org/show_bug.cgi?id=28419
Tyler Romeo <tylerro...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tylerro...@gmail.com
--- Comment #14 from Tyler Romeo <tylerro...@gmail.com> 2011-09-27 18:38:11 UTC
---
I was experimenting a while ago with Extension:SecurePasswords, which was an
attempt to improve upon MediaWiki's default password hashing scheme. Many of
the measures implemented were clearly unnecessary, but it got me thinking.
First of all, I don't see how the speed of C code for a hashing algorithm v.
the speed of PHP code means anything in terms of brute-forcing. Maybe I'm
missing something (and if I am, please explain it). The rate of brute-forcing
is only affected by the speed of the language the code is written in. Now since
MediaWiki throttles password attempts, we can safely assume that any brute
force attempt will only be successful if the attacker has direct database
access anyway. And any attacker with any knowledge of programming languages is
going to program their brute forcing application in C. So in the end the rate
at which the attacker can brute force passwords has nothing to do with how fast
PHP does it. It's not like the brute forcing application is racing against the
MediaWiki installation to hash passwords.
> Among other things, I found that a PBKDF-style iteration scheme was about six
> times slower in PHP than in C, not orders of magnitude. With 32k iterations
> of
> SHA1, PHP took around 50-100 ms, while C (using OpenSSL's SHA1 implementation)
> took around 8 ms, or about 120 passwords/second. On a GPU, I got about 10,000
> passwords a second. (With straight uniterated SHA1, I got 1.8 million
> passwords/second on a CPU, and 220 million on a GPU. I didn't salt, but
> salting would make no difference to the performance, since it only affects
> initialization.)
With this in mind, I wouldn't say using PBKDF2 is that bad an idea, and to
further the scheme, the current password hash (double MD5 hash) can be combined
with an external salt as aforementioned before being put through PBKDF to add
that extra layer of security.
(Another idea that I personally think is unnecessary but was used in
Extension:SecurePasswords is a method by which each user's password hash is
done using a different HMAC hash, i.e., depending on some manipulation of the
user ID, one user may have Whirlpool while another might have SHA-512. To see
what I mean exactly you can look at the Extension:SecurePasswords source.)
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
