I am working on a login dialog to my site. To spare users the frustration of having to remember their login details, I want to cooperate with the built-in browser password managers. I have worked out that to get Firefox to play ball, I must use a plain-vanilla HTML Form. Fine, so be it. However, I will not transfer unencrypted passwords. So my form content looks like so:
input#1 type="text" name="login"
input#2 type="password"
input#3 type="hidden" name="passwd"
I then intercept the submit and encrypt the content of #2 into #3, and off goes the form. Works a treat in IE and Firefox, not so in Opera and Chrome. Just rifled around SO and find that the problem is input#2, which does not have a "name" attribute. A quick test reveals that when I add name="ignore" it does work indeed in Chrome and Opera. Only trouble is that the password is now sent across the network plain text, with the label "ignore". Thanks a bunch. The whole point of omitting the "name" was to omit that field from the form.
If there a way that I can suppress input#2 from being sent while still giving it a "name"? Or is there another trick I could use?
Thanks.
The answer in the narrowest sense of the original question is: yes, it is possible via Ajax. Create a vanilla FORM with two named INPUTs and submit BUTTON. (Don't forget to feign some action in the FORM attributes.) Now it looks like a plain-text HTML affair. Next in JS, intercept the onsubmit from the FORM and launch an Ajax request to your PHP script, POSTing the plain login and hashed password. Return FALSE from onsubmit to suppress the FORM's action. You're done. No more plain-text passwords across the wire...
Related
Is there any way to stop this behavour?
<div class="form-group">
<label for="user-profile-name-input">Name</label>
<input type="text" id="user-profile-name-input" class="form-control" aria-describedby="name" placeholder="Name" value="...">
</div>
So every time a change anything is this input field and navigate to a new page within my website, the browser prompts me if I would like to update my username for the saved password of the site.
Is there any way to stop this behaviour?
I trying adding autocomplete=off but there was no change.
-----
UPDATE
Ok so I managed to figure it out. It was an error on my part. Keeping this post here incase anyone else encounters this issue.
I have a couple of bootstrap modals on the same page. One of them has a type=password input. Since these are not completely removed when hidden the browser still has a reference to the password input.
I removed the modal and the browser is no longer prompting for me to update my username to the saved password every time i change a value in an input field.
Make sure you dont have a hidden input "type=password" somewhere on your page.
What you're asking for cannot be done at a code level. The behavior you're experiencing is browser specific and is something that can only be turned off by the user themselves if they choose to.
An example of how you can turn it off in Chrome here.
The browser recognizes the input field as a password field and therefore prompts for a password save, since the browser does not have a password stored for that specific page. Clicking "Never" will only stop the prompt for that page specifically, and any future page will still continue to prompt you until you completely disable the feature.
There are some hacky, tacky solutions to your problem if you really wanna go about it - check this post for instance, or this one. However, I strongly recommend that you don't use them as they are detrimental to the user experience. Let the user decide whether they want the feature or not.
That's a default functionality provided by chrome to save your credentials while you enter your credentials in your account in browser and not to repeat the credentials when you are trying to re login. There's no way to stop it by using HTML code.
I have a web application that uses old-fashioned HTML forms to submit information to the server. It was recently pointed out that the system does not work in Chrome with translation. (The system has its own internal translation for users, but occasionally someone wants to translate another language back to English for viewing. I got complaints that the system didn't work when viewing another language in Chrome with translation to English, and sure enough it didn't.)
I think I solved the problem by embedding the submit buttons in <span class="notranslate"></span>, but wondered why translation would disable submit buttons in the first place. They are basic <input type=submit value="[label on button]" ... />. Chrome would translate the value attribute (the text labels on the buttons) if the buttons were not in a notranslate span. But somehow that seems to disable them.
The buttons have not been disabled. The issue is that your form will POST/GET the values in the buttons. If these are selected as translated in Chrome by the user then they may not match the conditions required to detect a successful form submit.
E.g. There's a button in your form:
<input type=submit value="Continue" ... />
Google Chrome translates this in German:
<input type=submit value="Fortsetzen" ... />
and it will submit this translated value.
But, your submit detect code is (in php for example):
if (isset($_POST["submit"]) && $_POST["submit"]=="Continue")
so the form will be submitted but the value will not match.
It seems to me this will have been breaking large parts of the internet, not just your system.
BTW thanks for the suggestion: <span class="notranslate">
This problem can be due to faulty html structure of the form.
Things like extra </div> may OK in a normal web page, but after google translation kicks in the browser can no longer show the form in a correct way, causing the submit button to appear outside the form and hence clicks on it does not trigger any action.
By correcting the Dom structure of the form (and/or other parts of the page) the problem can be resolved.
I tried to look through SO for similar question but I couldn't find one, also searched through the web with my best effort, sorry if it's a silly/duplicate question
The focus of my question is :
If I have a form with a unencoded password in it, is it "safe" to pass the form back to [self] i.e. <form action="">
EDIT: I would like to focus on security regarding third parties, assuming the user himself is NOT the hacker.
I this is a broad question, so I would like to narrow it down to:
does server handle submit form to self as a internal-forward thing or do it actually treat is as a normal server-to-server http call?
Is it possible to somehow intercept the form submit and extract the password from this action? (including things like tapping the connect between server and client??)
If anyone knows any potential security problem in general for [submit to self], feel free to leave it as answer so that future SO user might benefit from it, thanks.
The only thing safe regarding submitting data to a webpage is to never trust the users input.
Now regarding your 2 questions:
submitting the form will be handled as a regular request, albeit a POST request probably.
internet traffic can be captured, so if you're sending password data over the internet you'd better make sure it's over HTTPS.
Using a developer tool like Mozilla's FireBug it's pretty easy to change all the data that is submitted through the form. You don't even have to use your webpage, one can easily spoof a POST request to your page by using a tool like Telnet.
So I'd say it doesn't really matter what the action of the form is; use HTTPS if possible and always validate the input...
Whether you submit your form to the same page or not has no security implications. There are many other things you can/should do to secure your forms. Submitting-to-self is irrelevant. It could however pose a UX annoyance. Have you ever tried refreshing a page only to have the browser try to resubmit the form.
Not a redirect. Normal post. However to mitigate this UX annoyance I
mentioned, you would redirect to the same page after doing whatever
you need to to with the data.
It depends on many other things other than whether the form submits to itself or not. Starting with is your form on a secure (https) server.
I was just searching for this types of posts.
Yeah..
As far as i know, this is not a valid approach,
attacker can change the methods to download the content like he can use the parameters from POST to GET.
We actually have tools like tamper data which is an addon to the firefox browser. We can post the data or tamper the data which is in form submit. You can add this addon to your browser and you can check out that the data can be modified by clicking tamper before submitting the form. You can also check out the online http tampers, tamper data, modifying live headers to change your data. This may also result in sql injection.
Correct me if im wrong. :)
Cheers.
After many updates:
The action="" is the same as action="somefile" in sense of security. So there is nothing wrong with action="", and as far I know most websites treats forms like that. The most popular solution is to:
At first check with PHP if there is any post data
Check if this data is OK (safety, server side verification)
Make something with data (save to database, mail to someone)
Render the form with action="".
A quick example:
<?php
$name = '';
if (isset $_POST['name']) {
$name = $_POST['name'];
if (ctype_alpha(str_replace(' ', '', $name)) !== false) { // verify data
// in that case name consist only letters and spaces, it is ok.
// do something with data here, for example save to database
header('Location: successfile'); // Remove post data after all
}
}
// render form
$name = htmlspecialchars($name); // if name was in POST, here it is!
echo '<form action="" method="post" />'
echo '<label id="name" name="name" value="'.$name.'" />';
echo '</form>';
?>
In that case one file is doing two jobs. It checks for data and do something with it, and render form.
Please, remember that the form can be rendered using the "partly" data from submit (POST). So for example if someone enter his name with special characters, while you need name only with letters and spaces, the data is not missed. You can render form, and in input name value, you can enter the wrong posted data.
So the form "remember" what was filled, and what was not filled.
Hope it helps
When I submit a form with a password field in, for example, Firefox, the browser asks me if I'd like it to remember the username and password for me. For example, logging into gmail in Firefox, I get this message in a popup:
Would you like to remember the password for "markamery#gmail.com" on google.com?
with 'Remember password', 'Not now' and 'Never for this site' options.
I'm developing a plugin that will be used to provide a service on multiple websites. Users will have an account on our mysite.com, and our clients, like someclient.com, include a Javascript script from mysite.com on their webpages which adds our content and functionality to their page, including a login form that users can use to sign in to our site. (The actual mechanics of the login process are all handled with iframes, AJAX and HTML5 postMessages, not that it matters).
When users log into our plugin on someclient.com, I want their browser to prompt them to remember the password on mysite.com, and when they see our login form on someotherclient.com, I want it to be autocompleted with the same username and password that they entered into it on someclient.com. However, currently, they get a prompt asking
Would you like to remember the password for "yourname" on someclient.com?
instead, which isn't what I want.
Is what I want possible, and if so, how?
Putting the form inside an iframe will cause Firefox at least to associate any stored passwords with the domain of the iframe instead of that of the main page. You can communicate with the iframe using postMessages.
Just have the iframe catch the form submit event, serialise the content of the form, and send it to the main window via postMessage; then the main window can grab the content of the form from the message and handle it using Javascript.
Of course, even in simple cases this is a fairly ugly hack, and if there are complicated interactions between content in the iframe and content or code in the main page, then trying to handle them all properly via postMessage may result in a quick descent into pain and spaghetti. If the value of having cross-domain password autocompletion is low and the main issue is that having a remember password message featuring the wrong domain name is bad, then consider simply disabling the feature altogether instead of mutilating your codebase with hacks to fix it. You can disable it by setting the 'autocomplete' attribute of the form to 'off', as described here: Disable browser 'Save Password' functionality
I've researched it and cannot find a standard, dependable way to make a browser prevent autofill and not remember the password in a standard login form.
This is important to me as I'm working on a mobile web app, so if the user clicks logout and someone else gets hold of their phone, the browser shouldn't help them out by just handing them the password!
The only solution I can come up with is to make the password field type="text".
Sure, this would mean people can 'shoulder surf' and see what the user is typing in, but that same person could almost as easily just watch the user's fingers to see what password they're typing in...
I don't think spyware is a real issue here either, as I don't think a type="password" character mask is going to stop a malicious keylogger, etc. from doing its stuff.
So, I'm wondering if there are any other security concerns that I may have missed for using type="text" for a password field?
Maybe if I combined this idea with a dynamic/random 'name' attribute for the input, could I be onto a winner?
NB - The solution needs to be compliant with XHTML Mobile Profile.
Also, please refrain from advising me on what is semantically correct here. My priority is security, not semantics. :)
Bad idea - The browser will remember text fields, it just wont enter them automatically as it does with passwords. Instead it will suggest the password as an autocomplete for all to see. I also think reading a password over someones shoulder is much easier than reading their keystrokes.
The reason some browsers dont respect the autocomplete option for passwords is probably because passwords are handled by a separate (in theory more secure) method for handling/storing password data - obviously by using a text field you are bypassing this system with whatever risks that entails.
I dont think there is a definitive solution that doesnt involve js, since at the end of the day you have no real control over what their browser remembers. You can only provide hints and suggestions. Which will be handled in different ways by different browsers. Your best bet is to start by adding :
autocomplete="off"
to your form and input. Works in most browsers - but not all.
The above would go in your form tag and your password input tag, something like:
<form id="form1_randomstring" name="form1" method="post" action="process.php" autocomplete="off">
<input name="password_randomstring" type="password" value="">
As you said in your question, randomizing the form and input names will also trick some browsers into thinking it is dealing with a different form
Also, browser will be extra conservative about what they remember if you use ssl. So this may help.
Finally, as another layer of protection you could have a little onload jquery to clear the form field manually on docready:
$("input[type='password']").val('');
Obviously no help if not running js.
The Definitive solution (maybe?)
You could go a step further and inject the form field using an ajax call (plus generating the random form names + autocomplete and serving the page through ssl). Meaning js would be a requirement for logon but you could then make sure the field was clear and generate the form after page load. I would challenge any browser to complete it then.
If you went for that option both the outer page and the ajax loaded page would have to run through ssl - If you didnt want this an alternative might be to load the ssl form through an iframe (again trade-offs -user base would need to be considered.)
Depending on your requirements and userbase, this could present the most guaranteed option.
NOTE
Autocomplete="off" may not pass strict XHTML validation. An option then may be to add the autocomplete attribute after page load with jquery (again, obviously this wont work without js enabled):
$('#form1').attr('autocomplete', 'off');
As an added point, The simplest way to prevent a key logger would be to provide a select option drop down box and ask them to enter a letter/number from their password. Practically speaking you would have to limit passwords to alphanumeric and ask the user to enter at least three letters/numbers from their password in a series of drop downs.
Summary
No perfect solution but lots of options, you'll have to consider what is right for you. I would maybe go for the ajax call as the main method. You could initially load a link to the form and dynamically replace it with the ajax content so that there is still an option for non js users (less users compromised by autocomplete)