For example, suppose I already typed username and password at this Facebook page:


But I wrongly clicked 'Create New Account' instead of Log In. My question is, does it increase any security risk?

3 Answers 3


I admit this question seemed like it had a straightforward answer at first but then after looking into Facebook's page and the button functionality it definitely does beg the question.

I discovered that if you have the username/password fields filled in with the credentials of a legitimate account, or have auto-fill username/password in place pulling from either Chrome itself or a password manager- which may/may not be a good practice depending on your level of security paranoia- then selecting the 'Create New Account' button actually does send a POST message that includes details of your login information from the previous page, including username/password. If you're curious and aren't already aware, this can be done by simply monitoring the network requests in your browser.

Despite this, I would still say that it depends on the application you are interacting with. In this case, since it's Facebook and- though this may be a point of contention within the community- we can trust Facebook with our data, then as long as the POST request that had my username/password information in its payload was made over secure transmission I can presume to be unworried about a security risk. I would only imagine that at this point the information being sent to Facebook via this POST request would need to be equally as secure as the login button itself.

I have never encountered another site that does this, but am hoping to see other answers on this based on other experiences.

  • Ah, indeed, you're right: the form is submitted (browser also asks whether to remember that password). That's also the only website I know that does it. I wonder what happen if you enter the right credentials and click "Create account"...
    – Xenos
    Jul 20, 2018 at 8:34
  • I've monitored my HTTP requests when clicking create new account and it doesn't send the username and password to the server. Out of interest, what browse did you use? I don't understand why it would do that either because it's a complete separate form in HTML. I've tested this in Chrome for the HTTP post request.
    – Paul
    Jul 20, 2018 at 9:05
  • You'll need to toggle persist logs. Tested on Chrome, Firefox, Safari. My suspicion is that it does this so that it can prevent someone from attempting to create a new account if they are already a Facebook user....but I feel like there could be other ways of accomplishing this that are less o.O
    – jonroethke
    Jul 20, 2018 at 9:14
  • imgur.com/a/0lXBJZm still no sign of username or password even if I use the standard DevTools from Chrome or FireFox Quantum using same behaviour. Just tried under VMWare under fresh install of Windows 10 and Chrome and same behaviour too.
    – Paul
    Jul 20, 2018 at 9:35

The action your performing is no more risk than clicking login button.

The data will only be stored client side as your not performing an POST HTTP request for that form.


My Request body when clicking sign up with username and password as "fake"

__a=1&__be=-1&__dyn=5V8WXBzamaUCUx2u6Xolg9odpbGEW8yExLFwgoqwWhE98nwgUaqwHx24UJi28rxuF98ScDKuEjKewExaag4idxK4ohyVeE8UnyogKcx2785aayoe8hxG1awxwxgeEtwqUbQ3a1NDx6WK6pE9GBy8pxO12wRyUa8nyESbwgUgUKezUny9EbE9E-dgoV8O2V7yolwPzpp8GcxmUpzUryEqz85CGDwHx-5UO5bAyEa8aoCubK&__pc=PHASED:DEFAULT&__req=11&__rev=4123490&__user=0&action_dialog_shown=&asked_to_login=0&birthday_day=20&birthday_month=7&birthday_year=1993&captcha_persist_data=AZkj-5HqoXlsmEo3clgW9gmBHEKtRG3BQoRQ8EdYxrW2JTVg7sw6i_5wAqibWnE5Ubf2XivTgVpW70CJLfLwbtcAJkFylMxpep13OHyDh8Y7MPVI7LZTpeznA5e4yFJ8fUGPW4fUjAKngzl5rqJ91bZx7pKYErtj_GVhUDMLivUq0XlKibMoci2qPry7TRJskGjruNBWsAgTHolP5fHqFzssS8m3-OQoFJPjmX9vYye-3K5_0POt0oQ2J7q_iuE-Spdmv_0r4GdpOA-R-Fr0USs8V9OJd3jGCa1SZiFruN6pPh4no-CGqA5MJm-f3G1ID1yvAyFifk6No2QOv-yVcrG7PFX4eaE4UWEklZzmlcbBsENSFZt7M3f7KG-nLCUTZTk&captcha_response=&contactpoint_label=email_or_phone&firstname=Paul&ignore=reg_second_contactpoint__%7Ccaptcha&lastname=Smith&locale=en_GB&lsd=AVrgQt1V&ns=1&referrer=&[email protected]&[email protected]&reg_instance=9p9RW-B5RLUuCETwQ0f6VBig&[email protected]&reg_second_contactpoint__=&ri=9f2afcc5-92b5-6f74-f171-c2a48740f98d&sex=1&skstamp=eyJyb3VuZHMiOjUsInNlZWQiOiI2ZmNkN2MwN2U2OTNkZDc3NGYxMTgzMTc3ZGY0MzNhMCIsInNlZWQyIjoiYjRjYjI0NzJmMTA2ZmI4YzhhMmNmYWZhN2I4NWZkMjIiLCJoYXNoIjoiMmY0NmQ4NGJmYmJhMTcyMmI2MjA1Yjc0YTZhNGFhOTQiLCJoYXNoMiI6ImViOGI2MTQ3ZGFjYTRiNDNjMTM2MzMzYmU3M2JkZmFkIiwidGltZV90YWtlbiI6NDA5OSwic3VyZmFjZSI6InJlZ2lzdHJhdGlvbiJ9&terms=on

So, I put some garbage information in there:

From the above POST request there is no mention of the word "fake"

This time I typed in username and password as "test" and clicked login:


Finally, I've set auto-complete on and done the sign up, same behaviour. No mention of username or password been sent off to the server.

Let's even assume for one moment that the username and password was sent off to the server. You're risk would be same as clicking login anyway so your standard attacks like MITM and XSS apply.

I've tested this on Chrome Version 67.0.3396.99 (Official Build) (64-bit) and only extension I have installed is Tamper Data for Chrome.

  • 1
    It's even not stored since browser did not submit the form (it won't save it for autocompletion; besides, whether to save the password will be asked to the user anyway, unless you've set it to "always Yes/No" before)
    – Xenos
    Jul 20, 2018 at 8:04
  • I did my test in Internet Explorer and it was keeping it in memory even if you had gone to another page but it's good point about auto-completion. I didn't think about auto completion forms but they are in separate forms. So, they won't get send off to the server.
    – Paul
    Jul 20, 2018 at 8:51

Unless the page designer was truely schizophrenic, there should be no increased security risk. A HTML form consists of:

  • a target URL that will receive the request
  • a set of input fields
  • one or more submit buttons

If you do not click on one of the submit buttons of the form, the input fields should not be member of the request. So if you click to a link, no data will not be added to the link url, and is you click on a submit button of a different form, only the data of that other form will be sent.

Things can be different for a Javascript button. The invoked javascript can access to any data on the page, so could send any data to any URL. But I cannot imagine why someone could have coded that! Said differently, if you write your credentials on a page, you trust the site. That trust extends to the login page not to do too stupid or dangerous things (*). So even if technically risks could be increased, they are still the same on a trust point of view.

(*) a not too cautious programmer could send the credentials to a wrong page but still on the same site or inside the same security zone. So I cannot imagine a data leak here. And if the site is poor enough to store the password in an unencrypted form on that other page, you cannot trust it to correctly handle your password in any other place including when you click on the correct button.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .