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)
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