should you allow login passwords to autofill

Hi - is it a good idea to allow login passwords to auto-fill?  If not, what would be the best approach to suppress that feature?

For your reference, the application that I am developing will contain somewhat proprietary information, but neither is it top secret.

Thanks in advance,
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Dave BaldwinFixer of ProblemsCommented:
For what it's worth, Chrome will 'auto-fill' my bank username and password while other browsers won't.
Julian HansenCommented:
There is the autocomplete="off" attribute for forms and controls - but it is browser specific.

Having said that - users have the option to turn autocomplete on or off for a particular site - messing with that is probably going to irritate them - especially if the site is not "top secret"

One way to do it if you really wanted to (and I have not tried this) is have a javascript function intercept password entry on a standard text (not password) input. It then places a star (*) in the text box and sets a hidden value.

Personally though I would not mess with it
If the data isnt subject to privacy, then i wouldn't worry too much. However if this does change then you may want to review.
Exploring SQL Server 2016: Fundamentals

Learn the fundamentals of Microsoft SQL Server, a relational database management system that stores and retrieves data when requested by other software applications.

Ray PaseurCommented:
I generally agree with all the other comments.  I believe that passwords should auto-fill, especially if you couple them with two-factor authentication, like the ATM at the bank.  It uses something you know - your PIN - and something you have - your bank ATM card.  Either by itself is not useful.  In the case of a web application sign-in you would receive the client id and contemporaneously send a message with a random string.  The login would only be complete with the client id, the password and the random string.

One of the nicest features of Apple password entry forms is the ability to hide / show the characters that are typed into the password input box.  It seems like a "show password" feature could be developed that would apply or remove the type=password attribute.

The general design for PHP client authentication is given in this article.  May be helpful.

Best of luck with your project, ~Ray
Tony GiangrecoCommented:
Auto-fill password functionality is in itself, not dangerous, however if you ever expect to save any confidential information like credit card, birth date, SSN or other personal information, then I would definitely turn that off.

Hope this helps!
shafer23Author Commented:
Thanks for all of the feedback!  

Ray - I am just trying to fully understand what you mean by sending a message with a random string; I assume that you mean that this should be the case upon the initial registration, as opposed to each time that a user logs in.  (p.s. excellent write-up!)

Also, someone else had recommended using multi-factor authentication.  I don't want to make it overly cumbersome to log in (as the application will not contain credit card, social security or similar information), so that seems like over-kill to me.  Does anyone think otherwise?

Thanks again,
Ray PaseurCommented:
Yes, I think if you're not keeping sensitive data, you probably want to keep the minimum needed security measures in place.  Security always seems to be a trade-off between what is adequate and what sucks for your clients.  Awkward password-reset routines, silly rules about "one letter one number one special one upper one lower" all work together in the direction of making the user experience suck.

At the low end of security you can store passwords in clear text.  If a user forgets her password, you can email it to her.  This has the obvious risk that if you lose the list of passwords to a hacker, all of the users in your app are compromised.  The less obvious risk is that your user chooses the same password for your app and her bank account.  For this reason, we almost never store clear-text passwords, and we salt our passwords before encoding them.

Two-factor or multi-factor authentication is at the higher end of the security spectrum.  When the client starts the sign-in process, you would check the user name and password, and if these both match, you would send a text message to the client's cell phone with a short code that must be entered to finish the sign-in process.  By doing that, you will only authenticate a user who knows the user name and password, and also has the registered cell phone.  Not perfect, but better security, at the cost that if your perfectly legitimate client loses a cell phone, they're locked out of your site until they get a new phone.

For an example of how to do a "handshake" on initial registration, please see this article:
Julian HansenCommented:
Does anyone think otherwise?
If nobody's personal info is compromised then the only person who can answer this question is you.

There are actually three components to a secure solution
Something you know (password)
Something you have  (keycard / random number generator)
Something you are (biometric)

The weakest link is always the human factor.

The decision points are
a) Are your users going to be compromised if there is a security breach (identity theft etc)
b) Are you going to be compromised by unauthorised entry (non paying users having access to paid content for example)

Depending on the answers to the above and the severity in each case of an unauthorised entry determines how much of the security matrix you need to cater for.

Personally, based on the description of your setup - not sure why you would need anything more than most sites out there are using anyway (Amazon, Facebook, Banks even - I can logon to my bank site only with what I know - but if I want to transact - something I have comes into play).

Bottom line - leave the autofill up to the users and go with a standard password entry - just make sure your password database is secure (hashed and salted).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
shafer23Author Commented:
Thanks for everyone's feedback.  As suggested, I intend to allow auto-fill and use a standard password approach, and I also intend to incorporate the 'remember me' functionality that is incorporated within one of Ray's write-ups.

As a practical matter, the only significant issue that I foresee is if a user logs in via a public computer.  In which case, I assume that the best advice to them would be to ensure that they delete the recent history (i.e. to avoid any issues with auto-fill, in case another user subsequently accesses the application).  If you have anything to add to this, please let me know.

And thanks again!
Ray PaseurCommented:
I think eBay has a note to the client about "remember me" that says something to the effect of "Do not check this on a public computer."  You can also shorten the "remember me" time to a day or so.

You can also generate the PHP session id and use it in the input control names.  So instead of name="userid" it could say name="userid_c3c8559f5b0eb3a76d447354de85f25c" thereby limiting the likelihood that autocomplete would successfully match an existing named control.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.