Extension talk:SecurePasswords

maximum length
Why enforce a maximum length? If some cap is needed at all, it should at least be a lot longer than 30... --brion 19:53, 23 December 2008 (UTC)
 * The nature of the hashing/encryption method totally bloats the size of the hash. The maximum length was so that long passwords don't get truncated in the database... although with the schema change to MEDIUMBLOB that shouldn't be an issue anymore. I'll rm it. -- Skiz zerz  20:12, 23 December 2008 (UTC)

Messages are not displayed properly
Hi, I just installed this extension and it seems to work since my attempts to set an invalid password are being blocked. However, the message which is supposed to give me a hint about the problem with the new password is not shown. Instead it get this: &lt;securepasswords-password&gt;. It would be cool to get a fix for this. Thanks and cheers --kgh 22:22, 17 November 2010 (UTC)
 * I will look into this, sorry for the delayed reply. Out of curiosity, what version of MediaWiki are you using? -- Skiz zerz  13:22, 28 November 2010 (UTC)
 * Hi Skizzerz, no problem at all. Take your time. I am using 1.16.0 and Monobook. Cheers --kgh 22:26, 28 November 2010 (UTC)
 * Hi Skizzerz, I will upgrade to 1.17 soon and provide you with a note if this issue still persists. Cheers --&#91;&#91;kgh&#93;&#93; 08:07, 7 July 2011 (UTC)

Pspell not longer supported by PHP 5.3
Hi Skizzerz, on the page about Pspell somebody dropped a note that it is not longer supported by PHP 5.3+ and one should use Enchant Functions instead. I this something to worry about since 5.3+ is ante portas? Cheers --&#91;&#91;kgh&#93;&#93; 08:11, 7 July 2011 (UTC)
 * pspell isn't required to run this extension, although I'll look into the possibility of supporting enchant as well (it entirely depends on whether or not I can get it to compile in windows, since that is my dev environment). I'll probably ship an update mid-October. -- Skiz zerz  15:12, 27 September 2011 (UTC)

Safe to try?
I'd like to try this, but I don't want a messed up wiki if it doesn't work out. Is it safe to try? Can it be removed easily? Or, is it a "break it, you bought it" kind of thing, where once you install it, you need it forever? Badon 07:21, 26 August 2011 (UTC)
 * If anyone signs up while the extension is enabled, they won't be able to log in once you disable the extension, meaning they have to use the password reset feature built into MediaWiki in order to be able to log in again. Beyond that, it doesn't break existing accounts, so as long as your password reset feature works properly, you should be able to try this extension without too large of an impact. -- Skiz zerz  15:08, 27 September 2011 (UTC)

Internal error after PHP upgrade
Hi, after an PHP upgrade from 5.2.13 to 5.3.6 I get the following internal error

Non-string key given

Backtrace: Cheers --&#91;&#91;kgh&#93;&#93; 19:03, 24 November 2011 (UTC)
 * 1) 0 /.../includes/GlobalFunctions.php(781): MessageCache->get(Array, true, false)
 * 2) 1 /.../includes/GlobalFunctions.php(902): wfMsgGetKey(Array, true, false, false)
 * 3) 2 /.../includes/specials/SpecialUserlogin.php(328): wfMsgExt(Array, Array, '10')
 * 4) 3 /.../includes/specials/SpecialUserlogin.php(188): LoginForm->addNewAccountInternal
 * 5) 4 /.../includes/specials/SpecialUserlogin.php(132): LoginForm->addNewAccount
 * 6) 5 /.../includes/specials/SpecialUserlogin.php(34): LoginForm->execute
 * 7) 6 [internal function]: wfSpecialUserlogin(NULL, Object(SpecialPage))
 * 8) 7 /..../includes/SpecialPage.php(851): call_user_func('wfSpecialUserlo...', NULL, Object(SpecialPage))
 * 9) 8 /.../includes/SpecialPage.php(578): SpecialPage->execute(NULL)
 * 10) 9 /.../includes/Wiki.php(251): SpecialPage::executePath(Object(Title))
 * 11) 10 /.../includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 12) 11 /.../index.php(114): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 13) 12 {main}
 * That backtrace doesn't look like it has anything to do with the SecurePasswords extension... What version of MediaWiki are you running? -- Skiz zerz  11:42, 25 November 2011 (UTC)
 * I am running MW 1.17.0. This is the backtrace I get when I want to create a new account. A similar one gets thrown when I try to change the password in the preferences. I think its because of the new PHP version which caused some other extensions not to work, too. Cheers --&#91;&#91;kgh&#93;&#93; 13:43, 25 November 2011 (UTC)
 * And this worked properly up until you upgraded PHP? My advice to help you debug this is a) try re-uploading MediaWiki 1.17 (don't re-run the installer, just re-upload the files). b) Try disabling all of your extensions to see if the problem goes away (note that disabling SecurePasswords will cause existing accounts to likely not work, but you should be able to test by creating new accounts and logging in). c) If disabling all of your extensions fixes the issue, re-enable them one-by-one until you find which one it is. If SecurePasswords is indeed the misbehaving one, let me know and I will try to ship a fix ASAP. -- Skiz zerz  21:10, 25 November 2011 (UTC)

File system leak
If both the database and LocalSettings.php and other configuration files leak, you're still hosed though, right? Leucosticte (talk) 17:18, 25 September 2012 (UTC)
 * No, it just means that the password hashes are susceptible to brute-force attacks, so the only line of defense is how strong the password actually is in the event of both a database and filesystem leak. The passwords are stored hashed in the database (aka a one-way process, it is impossible to "unhash" a password), so it is still non-trivial for an attacker to actually compromise an account unless the users chose weak passwords. I am shipping an update in a couple of weeks that implements password strength checking and the use of the bcrypt algorithm to hash passwords -- both of which would make brute force attempts much more difficult in the event of a complete leak. By having strength requirements, common dictionary attacks should not work as effectively making attackers resort to an actual brute force rather than a dictionary check, and the bcrypt hash algorithm is designed to be slower than SHA-based hashes so that an attacker would have to use significantly more time in order to check a single password. -- Skiz zerz  20:10, 27 September 2012 (UTC)
 * Obviously in the event of any leak, you should inform your users (and other steps that need to be taken according to laws or whatnot) and encourage them to change their passwords, even if there is only a small possibility that the attackers managed to get access to the hashes. -- Skiz zerz  20:11, 27 September 2012 (UTC)