Security Implications of repopulating the password on Registration

[tenants]

I've noticed that one of the things XenForo does on failed registration is that they clear the password and password_confirm feilds

But why?

Quite a lot of registration forms do this, so there must be a good reason

I have noticed that when someone fails the CAPTCHA (by accident, particularly if the default ReCapatch is used), often they will try again and not notice the password has been blanked.. this means they are now on their 3rd attempt of registering (people don't like being told they have done something wrong), .. they may make the mistake of populating the password/password_confirm and this time forget about the CAPTCHA (this means that they would now be on their 4th attempt of a very basic registrion process).

<= This is the case of a simple registration form with no customisations, it only get's more complicated with added customisations and some users may give up very easily.

In my custom case, it's not the CAPTCHA that people have issues with, but making sure a certain textarea field is populated (the datawriter verification for textareas on the registration page seems to be skipped over)

So

I know that you can sit an application in the middle (such as paros etc), and look at request/responses, but in this case the response is related to the request.. so you're only getting back what you send. You could watch the packets over the network (sitting on the users network), but if you are doing this, you would have seen the sent password anyway... Even more so, if you don't send the password, but store it as a hash, you can only capture the hash, which is meaningless on it's own

1) I will need to write a custom js to validate the textareas in the form
2) I might pass the password and password_confirm back to make the registration easier

What are the security Implications of repopulating the password on Registration

And wouldn't it also be possible to store the password as a hash in the session, and then use this to repopulate the password (avoiding plain text being sent)

I find password/password_confirm being blanked very annoying and I don't think it's neccassiry

 

[Arty]

I suggest doing it another way: once user has entered password save it and replace password field on form with text like "Password: ***" (where number of * matches length of password). That way you won't need to send password back to user and user won't have to enter it again.

To allow user to change it, make *** clickable. Clicking it will replace it with password inputs where user can enter new password.

 

[tenants]

Or, even simpler

can we not just do this

1)
XenForo_Application::getSession()->set('password', $passwords['password']);
XenForo_Application::getSession()->set('password_confirm', $passwords['password_confirm']);

and repopulate if it's stored

and if we can't do this (and can't see why yet, since the session is not passed over the network)

can we not do this:

2)
Store password for uuid in DB
XenForo_Application::getSession()->set('password', $password_uuid);
XenForo_Application::getSession()->set('password_confirm', $password_confirm_uuid);
Then do a look up for the uuids stored on the database to repopulate the passwords

3)
Save session-id to database, and add password
On going back to the form, look up DB, repopulate the password if it exists for the session_id

I don't think security has to always be less user friendly (unless you are one of those people that believe only mouth wash that hurts works, or the worse the medicine tastes, the better it is for you). Security does not mean we have to be less user friendly, I think there must be ways we can repopulate the password on failed registration attempts without reducing security

-- Edit: actually the 1st idea of adding them as plain text in the session is bad, since you can capture someonese session (you don't also want to give them the password). But storing them as uuids as the second example shouldn't be an issue, and would make the form more user friendly

 

[tenants]

I suggest doing it another way: once user has entered password save it and replace password field on form with text like "Password: ***" (where number of * matches length of password). That way you won't need to send password back to user and user won't have to enter it again.

To allow user to change it, make *** clickable. Clicking it will replace it with password inputs where user can enter new password.

That's really just cosmetics... adding place holder text

This bit

once user has entered password save it

is the important bit, how?

1) By saving it in the session it's self (as above, that could cause issues),
2) By saving a uuid in the session and then looking up the uuid to get the password to repopulate the form
3) By saving it to the database for that session (so session_id is directly related to the password)

or another method?... either way, surely it can be done, making the form more user freindly without reducing security

I can't yet see a problem with the above methods (2) or (3)... so why do registration forms not do this, and why do we not do this in XenForo core?

 

[Arty]

You can store it in session. No need to send password back to user.

 

[tenants]

Not sending the password back to the users form is trivial, since if you add it to the session, it's already stored in their session, so you have affectively already sent it back to the user when they get redirected back to the registration form.. why not just use it to repopulate the field (from session to form, there are no issues)

However, storing as plain text in the session would be an issue.

It is possible to steel someones session

For instance, old versions of a particular plugin allowed you to add JavaScript .. you can then use the JavaScript to get the session and send it to nastysite/myform and use it to login as that user (there are many ways of steeling sessions, this is just an example)

You can do nasty things once you've stolen someones session, but at least you don't know their password, so if the session ends, you can't do anything. If you store the password in the session as plain text, you've lost that account for good (they can login when ever they want)

So (1) is out of the window, I don't seen an issue with (2) or (3) which are essentially the same

 

[AlexT]

You can do nasty things once you've stolen someones session, but at least you don't know their password, so if the session ends, you can't do anything. If you store the password in the session as plain text, you've lost that account for good (they can login when ever they want)

Hmm, isn't session data stored on the server only (in the xf_session table)? A user's cookie (which is what you're afraid of being stolen) only contains the session id which references to the xf_session table.

 

[tenants]

Hmm, isn't session data stored on the server only

You retrieve this session when using the cookie by retrieving the session from the database for that session_id

If adding password directly to the session,
... this user is then roaming around the site with "password" in their "XenForo_Application::getSession()"

How they would then get to dump it out, I'm not yet sure. But if it's there, then there is a potential for this to happen.
I know I would feel safer if a hash was stored in their session rather than the actual password, and this hash was then deleted after registration was complete (sorry, I keep adding ideas)

So (2) and (3) are still methods that I would prefer.

I think my real question is, why don't we do this in the core (2 or 3). Having to re-populate the password for failed registration is a usability pain, and I'm sure we should be able to do this without reducing security (even if my methods are silly/ nonsensical for whatever reason)

 

[AlexT]

You retrieve this session when using the cookie by retrieving the session from the database for that session_id

If adding password directly to the session,
... this user is then roaming around the site with "password" in their "XenForo_Application::getSession()"

How they would then get to dump it out, I'm not yet sure. But if it's there, then there is a potential for this to happen.
I know I would feel safer if a hash was stored in their session rather than the actual password, and this hash was then deleted after registration was complete (sorry, I keep adding ideas)

You're referring to temporarily storing the password in the session table for until the registration is completed, so that you can pull out the password from it if the registration form isn't compelted yet. After completition of the form you can unset the password from the session data, and the user wouldn't "roam around the site" anymore with their password in it.

Of course you can make it complicated and store the hash of the password in the session table instead. But then you'd have to keep in mind that xF supports pluggable authentication methods, so you'd have to make sure that the hash is generated through the authentication method that's in place. Then you'd only show **** in the password fields when the form is reloaded. Then, as long as the user doesn't touch the password fields again (you can use Javascript to detect that or look at the returned fields server-side), you'd know for certain that the stored hash is still current.

Remember there is a much bigger security issue involved here - unless your site uses SSL encryption - which is the transmission of the password in clear text (xF doesn't use any client-side hashing).

 

[tenants]

You're referring to temporarily storing the password in the session table for until the registration is completed, so that you can pull out the password from it if the registration form isn't compelted yet. After completition of the form you can unset the password from the session data, and the user wouldn't "roam around the site" anymore with their password in it.

Yes that's exactly it (so far as I can think anyway), there shouldn't be an issue with doing this.. it would remove the usability issue of blanking out the passwords when the user makes a mistake on registering

Of course you can make it complicated and store the hash of the password in the session table instead. But then you'd have to keep in mind that xF supports pluggable authentication methods, so you'd have to make sure that the hash is generated through the authentication method that's in place. Then you'd only show **** in the password fields when the form is reloaded. Then, as long as the user doesn't touch the password fields again (you can use Javascript to detect that or look at the returned fields server-side), you'd know for certain that the stored hash is still current.

I'm not sure I understand you here. The password is not stored in the session now, the same method used for pluggable authentication that is used now, should be used even if there was a temporary hash for passwords added (I may have missed something)

Using JavaScript would not be an option (about 2% of users browse without js.. and XF for the most part, supports a non js environment). The only thing that needs to be done to keep supporting a non JS environment is, after making a mistake on the form:
1) Re-populate the password on the form (by getting the passwords for that sessions id)
2) On attempting to re-register, update the passwords for that session ID (so the passwords are always current, even if the user retyped different passwords on their 2nd attempt)

Remember there is a much bigger security issue involved here - unless your site uses SSL encryption - which is the transmission of the password in clear text (xF doesn't use any client-side hashing).

Still ... we can avoid users having to re-type their passwords (and do it securely)... and while we're at it, we could avoid sending the passwords in clear text (do other content delivery applications / blogs / etc do client side hashing for registration?)

 

[AlexT]

... and while we're at it, we could avoid sending the passwords in clear text

I am afraid you cannot (assuming you don't run your site with SSL), unless you want to break the pluggable authentication feature of xF. xF makes no assumption of how authentication methods process the user password. This is why I asked you what "hash" you were referring to. You shouldn't assume that every xF site uses the core XenForo_Authentication methods for processing a user password. In particular sites that bridge xF with other software may use another authentication plug, which means they are totally open in what format they ultimately store a user's password.

(do other content delivery applications / blogs / etc do client side hashing for registration?)

vBulletin does, for instance. But with hashing client-side you lose the flexibility xF offers with its pluggable authentication system.

 

[Deebs]

I am afraid you cannot (assuming you don't run your site with SSL), unless you want to break the pluggable authentication feature of xF. xF makes no assumption of how authentication methods process the user password. This is why I asked you what "hash" you were referring to. You shouldn't assume that every xF site uses the core XenForo_Authentication methods for processing a user password.

This, FH uses Bcrypt to store user passwords.