My company website, which I develop, requires a login using a form.
Firefox correctly asks for and remembers login details, but test instances of IE6, IE7 do not remember either the username or password, and IE8 will give a dropdown of usernames previously used, but will not remember the password.
What is it about the design of my password form that allows or prevents IE from prompting?
Can I alter the design of my page so IE will remember username/password form data (assuming the user has their preferences set correctly)?
Is there some magic HTML tag, name, or style I should be using?
You might try looking into DOM storage to store username/password persistently on the client side. It'll require JavaScript though and won't work in older versions of IE.
Try adding the site(s) you're trying to access to the "Local Intranet" zone, rather than the "Internet" zone. (assuming this won't cause you security worries)
Tools/Options/Security/Intranet/Sites/Advanced --> add your site(s) here. In my experience, by putting them in the more highly trusted "Intranet" zone my passwords are remembered.
I assume the input box for the password is set as an input type of password?
One thought I had was to explore the naming convention of your form and input fields. Perhaps IE is looking for certain combinations to know that this is a login form that it can offer to save the login credentials for. Also, I have noticed that some web technologies/languages read different elements to get the field names. You might need to set your input fieldnames using both "id" and "name" to get everything to work.
Does your IE remember passwords for other sites than your company website?
Just want to make sure you have not disabled password storage in your IE.
Related
It's well documented that Chrome and Firefox ignore the standard autocomplete="off" attribute in html as they (Google) feel it wasn't being used correctly. They have even come up with workarounds and their own set of values for autofilling fields.
However, We need to prevent users passwords from being auto-filled for a website we're working on, and none of the suggestions put forward by Google appear to work.
The current situation on our website is that login names and passwords are stored by the browser, and so when a user visits the site and they're forced to login, their username and passwords are pre-populated in the relevant fields and they simply click the login button to login.
This has been deemed insecure, and while the infosec team are happy for the username to be pre-populated, they insist the password field is not.
To start with I tried adding the autocomplete="off" attribute to the password fields, but the password was still pre-populated. After some googling I found this link that shows Google decided to ignore this value and come up with a list of their own values for the autocomplete attribute...
Google ignores autocomplete="off"
They state that if we add our own, non-recognised value (such as autocomplete="please-dont-auto-fill-me") if shouldnt auto fill as it wouldnt know what that value is for.
However, I added something more meaningful - autocomplete="non-filled-value" - and it still populated the field. I've since tried a number of other things, such as renaming the password input control (removing the word "password" from the control name) etc and nothing seems to work. every time I load the login page, the password is pre-populated.
The issue I have is that my login form will be loaded on multiple browsers as different users from around the world login, and I need a solution that works for all browsers, not just Chrome.
Does anyone have any experience of this, and has a working solution for preventing fields being pre-populated/auto-filled that works cross browser? Everything I've tried (renaming fields, adding hidden fields, setting obscure autocomplete attribute values) fails to work, and whatever I try, the password is pre-populated.
Obviously, I have no control over the users actual browser settings and cant force them all to change their own personal settings.
New approach
I know how frustrating it is to try all solutions and seeing user and password fields ignore them.
Unforturnately, I haven't found a straightforward way of doing this, but I have a workaround for avoiding user password fields getting autofilled.
The problem
The main problem is that if you set input type="password", browsers automatically try fo autofill the field with saved passwords and users for the webapp, and nothing seems to work in order to stop it.
The solution
My approach is to avoid setting input type="passoword", but making the field look like a password field.
The way I found to achieve this was to build a font composed only by discs, so when you type anything in the input field, it looks like a password field, but you will never be prompted with saved user and password credentials.
I've tested this solution on Chrome, Firefox and Microsoft Edge, please let me know if is something worong with other browsers.
I know the solution is awful, but seems to work.
Link to the font, made by me using Font Forge: https://drive.google.com/file/d/1xWGciDI-cQVxDP_H8s7OfdJt44ukBWQl/view?usp=sharing
Example
Browsers will not fill in the input elements because none of them is type="password"
Place the .ttf file in the same directory where you create the following html file:
<!DOCTYPE html>
<html>
<head>
<title>Font Test</title>
</head>
<body>
<span>Name: </span><input type="text"/>
<span>Password: </span><input class="disk-font" type="text"/>
</body>
<style>
#font-face {
font-family: disks;
src: url(disks.ttf);
}
.disk-font{
font-family: disks;
}
</style>
</html>
Hope this is helpful, feel free to comment any issue.
Actually, i've recently faced this issue, and a workaround which worked form me is just setting the value as an empty string on a method (can be onload, for example if the input is in your main screen). Would be something like:
let login = document.querySelector('#inputLogin');
let password = document.querySelector('#inputPassword');
function someFun () {
login.value = '';
password.value = '';
}
Also I've already tried to put autocomplete="false" but didn't work.
As explained in this MDN article, autocomplete="off" will be ignored for password auto-fill, but autocomplete="new-password" is likely to work, though it carries additional semantic information:
If you are defining a user management page where a user can specify a new password for another person, and therefore you want to prevent autofilling of password fields, you can use autocomplete="new-password".
This is a hint, which browsers are not required to comply with. However modern browsers have stopped autofilling elements with autocomplete="new-password" for this very reason. For example, Firefox version 67 (see bug 1119063) stopped autofilling in this case; however, Firefox 70 (see bug 1565407) can suggest securely-generated passwords, but does not autofill a saved password. See the autocomplete compat table for more details.
Scenario
On site example.com I have 3 different accounts (e.g. usernameA:passwordA, usernameB:passwordB, usernameC:passwordC). I have let the browsers store them.
So the next time I go to example.com, the browser autofill/prefills the username and password fields of the first account (usernameA:passwordA). There's a dropdown list containing the other accounts (usernameB:passwordB and usernameC:passwordC.)
Question
When the first usernameA:passwordA is autofill/prefilled by browser... is it known to example.com before I choose usernameC:passwordC? (if example.com is tracking form input fields?)
Can example.com know that both usernameA and usernameC are used by same person? (by tracking form input fields?)
Can example.com know that the browser had autofill/prefilled the form fields of currently logged-in user (which is usernameC) with usernameA & passwordA first, before this user manually chose usernameC?
Update
So it appears my question remains without any interest. Meanwhile I have tried googling this issue, and tried Chrome, Firefox and Opera forums, but haven't found anything (most probably because I am not using right terms to look for perhaps?). I'll just leave it here hoping someone in the know eventually stumbles on to it. Thanks.
It appears that Browsers do not sent the <input> fields of login and passwords to the sites until after submission via <form> so I think it's a safe practise.
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)
In the registration page on the website I'm working on Firefox prompts the user if they want to save their password.
If the user chooses yes then the password is saved for the registration page which is quite useless considering that the login page is different, and that the browser will prompt the user again in the login page, which makes poor user experience.
Is there any way I can tell the browser that there is no need to save the password on the registration page?
You can use the following form tag ->
<form id="<someid>" action="<action>" method="<method>" autocomplete="off">
Not sure that all browsers support it -> https://developer.mozilla.org/En/How_to_Turn_Off_Form_Autocompletion
Well, I found a solution right after posting the question:
<form autocomplete="off">
disables prompting the user to remember the password, and turns off auto complete of fields which is a good idea for a registration form.
Try making the name and/or id/class of the password input something else than password, passwd, pass. I believe FF tries to recognize password fields by looking at their names.