Important info about passwords in 4.6.0

Bloke · 2015-12-03 21:39:23

Password reset requests and account activation is changing for the better at long last. Get the lowdown and please provide feedback on the new features here.

Note that this change means plugins such as smd_user_manager are out of date. A plugin update is planned prior to the release of 4.6.0.

ruud · 2015-12-03 23:05:19

The default of 20 minutes for RESET_EXPIRY_MINUTES seems a bit on the low side. Due to things like greylisting, mail doesn’t always arrive immediately and can be delayed up to an hour or so (depending on how often the sending MTA retries delivery).

Is there any particular reason why RIPEMD* was chosen over the more popular SHA* algorithms?

Other than that, yay!

Bloke · 2015-12-03 23:26:54

ruud wrote #296949:

The default of 20 minutes for RESET_EXPIRY_MINUTES seems a bit on the low side.

Good point about retries. That value can be increased no worries. Would an hour do? Two?

Is there any particular reason why RIPEMD* was chosen over the more popular SHA* algorithms?

Nope, just plucked one from the list that seemed reasonable, had a good rep and performed well. We could go with one of the SHA variants as default if you think it’s a better fit. Which one would you favour? I’ll bow to your superior knowledge in this arena.

ruud · 2015-12-04 10:33:47

1 or 2 hours should be enough. I rarely see mail delayed longer than that unless there’s a malfunction somewhere.

What happens if you issue a second retry request; does that invalidate the first one (and is this rate-limited)? I’m asking because I typically issue a second one if the first one takes too long to arrive.

I don’t have superior knowledge about encryption algorithms, although they do interest me. Having googled a bit, I found that the ripemd-160 family (to which ripemd-256 belongs) was developed around the same time as sha1. Ripemd-160 is used by bitcoin and opengpg, but was deprecated last year in VeraCrypt (not because it is broken, but because it has an older design).

Finding good info on how strong it really is compared to sha2 is difficult. These two seem to contradict each other:
https://msdn.microsoft.com/en-us/library/system.security.cryptography.ripemd160%28v=vs.110%29.aspx
https://pthree.org/2014/05/02/analysis-of-ripemd-160/

So I guess ripemd-160 (or 256 to reduce chance of collisions) is fine. The alternative would be sha512, but it’s slower.

Bloke · 2015-12-04 11:11:38

ruud wrote #296954:

1 or 2 hours should be enough.

I’ve made it 90 minutes by default. Thanks for the tip.

What happens if you issue a second retry request; does that invalidate the first one

Yes. Same for new registrations.

On that note, it’s a shame that you can use multi-edit to send out ‘welcome’ messages to existing authors who have already logged in. Maybe I should alter it so it will silently fail if the last_access column is not null, informing you only of the ones that made sense to send out (i.e. authors who have never logged in).

I feel that would be better, although it’s potentially confusing to the admin to select a bunch of accounts and find that some won’t get the message (unless you go into the DB and NULL the last_access field first). Anyone have any thoughts on this?

(and is this rate-limited)?

No rate limiting is applied. You’re the admin, you can reissue as often as you like. Each one invalidates the previous one sent.

Finding good info on how strong it really is compared to sha2 is difficult.

Yes, I struggled too. I deemed ones higher up the table as overkill (in terms of security/complexity/speed) for a simple unique token. From memory I think the other main contender was indeed SHA512, but as you point out, it’s slower. Not that speed is a major issue given that generating tokens is not on the critical path. We could use it instead if you feel it has a brighter future than ripemd160, I don’t mind either way.

ruud · 2015-12-04 13:42:10

Bloke wrote #296955:

On that note, it’s a shame that you can use multi-edit to send out ‘welcome’ messages to existing authors who have already logged in. Maybe I should alter it so it will silently fail if the last_access column is not null, informing you only of the ones that made sense to send out (i.e. authors who have never logged in).

Using the multi-edit, I wouldn’t expect a welcome message, but rather a message that the password was reset, forcing the user to pick a new one.

No rate limiting is applied. You’re the admin, you can reissue as often as you like. Each one invalidates the previous one sent.

I was referring to the ‘password lost’ option for regular users, but I’m guessing the same applies there as well.

We could use it instead if you feel it has a brighter future than ripemd160, I don’t mind either way.

No, it’s fine. I was just curious.

Bloke · 2015-12-04 14:12:10

ruud wrote #296967:

Using the multi-edit, I wouldn’t expect a welcome message

There are now two multi-edit options:

Reset password [for existing users]
Send activation request [for new users who haven’t responded within a week of their account being set up]

If you highlight a bunch of users and send an activation request, they all get them, whether they’ve previously logged in or not. That kinda feels wrong to me, upon reflection so I might change it to only send to those who haven’t yet logged in. Conversely, you can send a reset request to someone who has never logged in. The endpoint is largely the same: set a new password for that account, it’s just the email that’s different.

Thinking out loud, I wonder if we even need two options at all? Perhaps the existing ‘reset password’ request could be relabelled slightly such that it could take a different action depending on the state of the last_access field. If it’s null, send an activation request. If it’s set, send a password reset request.

Is that too obtuse?

I was referring to the ‘password lost’ option

Ah, sorry. Yes, we should probably rate limit that as a precaution. Good point. Should be fairly easy to do: if we check for a previous token that has been issued for that user account within the last N minutes, we can take action.

Presumably the safest (from a security standpoint) action would be to silently fail in the same manner we do if the user account doesn’t exist: report the standard message that a request is on its way. We can’t very well do anything else without revealing the existence (or otherwise) of an account.

ruud · 2015-12-04 16:15:29

Bloke wrote #296969:

Thinking out loud, I wonder if we even need two options at all? Perhaps the existing ‘reset password’ request could be relabelled slightly such that it could take a different action depending on the state of the last_access field. If it’s null, send an activation request. If it’s set, send a password reset request.

Sounds good.

Ah, sorry. Yes, we should probably rate limit that as a precaution. Good point. Should be fairly easy to do: if we check for a previous token that has been issued for that user account within the last N minutes, we can take action.

With N = 5 minutes (or less)

ruud · 2015-12-05 14:37:40

You have until 12 December 2015, 14:29 to respond before this link expires.

Timezone is missing in both the reset and activation email.

Destry · 2016-01-07 13:12:44

Bloke wrote #296948:

Note that this change means plugins such as smd_user_manager are out of date. A plugin update is planned prior to the release of 4.6.0.

If I interpret this correctly, it means a certain naughty boy shouldn’t try and update a production site using smd_user_manager to Txp 4.6 on a PHP 7 server?

Bloke · 2016-01-09 08:38:53

Destry wrote #297283:

If I interpret this correctly, it means a certain naughty boy shouldn’t try and update a production site using smd_user_manager to Txp 4.6 on a PHP 7 server?

I wouldn’t advocate doing that, but it might still work. The plugin will just use the old methods of password generation: they’re currently deprecated, not removed, so it should still behave.

Destry · 2016-01-09 17:14:30

Thanks. I probably won’t update a production server to 4.6 until I see your public announcement that smd_user_man is good to go.

Textpattern CMS

Textpattern CMS support forum

#1 2015-12-03 21:39:23