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. --Skizzerz 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: <securepasswords-password>. 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? --Skizzerz 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 --[[kgh]] 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 --[[kgh]] 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. --Skizzerz 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. --Skizzerz 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:

#0 /.../includes/GlobalFunctions.php(781): MessageCache->get(Array, true, false)
#1 /.../includes/GlobalFunctions.php(902): wfMsgGetKey(Array, true, false, false)
#2 /.../includes/specials/SpecialUserlogin.php(328): wfMsgExt(Array, Array, '10')
#3 /.../includes/specials/SpecialUserlogin.php(188): LoginForm->addNewAccountInternal()
#4 /.../includes/specials/SpecialUserlogin.php(132): LoginForm->addNewAccount()
#5 /.../includes/specials/SpecialUserlogin.php(34): LoginForm->execute()
#6 [internal function]: wfSpecialUserlogin(NULL, Object(SpecialPage))
#7 /..../includes/SpecialPage.php(851): call_user_func('wfSpecialUserlo...', NULL, Object(SpecialPage))
#8 /.../includes/SpecialPage.php(578): SpecialPage->execute(NULL)
#9 /.../includes/Wiki.php(251): SpecialPage::executePath(Object(Title))
#10 /.../includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#11 /.../index.php(114): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#12 {main}

Cheers --[[kgh]] 19:03, 24 November 2011 (UTC)

That backtrace doesn't look like it has anything to do with the SecurePasswords extension... What version of MediaWiki are you running? --Skizzerz 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 --[[kgh]] 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. --Skizzerz 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. --Skizzerz 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. --Skizzerz 20:11, 27 September 2012 (UTC)

Hash Algorithms/Security Levels?

Hi. This extension looks useful. What algorithms are used, and to which security level do they adhere? I'm not sure I like the sounds of "both hashes chosen are random, but guaranteed to be secure." We might have different definitions of "secure" :) Noloader (talk) 21:50, 27 February 2013 (UTC)

Missing parameter to pspell_new?

I am trying this with PHP 5.3. It appears that there is a missing parameter to the calls to pspell_new on lines 272 and 279. The symptom is that it is incorrectly treating the mode parameter as the encoding parameter. If I pass an additional empty string before the mode, it works as desired.