How do I encrypt a password so that it cannot be viewed in a web browsers markup?

How do I encrypt my client side  password so that it can not be viewed in the HTML markup. If I go to a login page of a website, and enter in my username and password, the password is not visible, because it is masked with big dots or astericks. Yet if I press the F12 button, and view the html markup on the page, I am still able to view the password as readable text.

Is their a way to hide or encrypt the password when the html is inspected?
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:
It is only visible on your computer where you are entering it.  No one else can see it because at that point, that page Only exists on your computer.  It is encrypted in transmission if the next page uses HTTPS and it is usually encrypted on the server and the database.

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
brgdotnetcontractorAuthor Commented:
Yes but that leaves people with a big vulnerability if they open a web page that pre-populates the username and password. No all people are tech savy enough, or do not have the desire to not have their password autosaved when they close the web page? How can I encrypt the client side password so that it cannot be viewed in the html markup?
btanExec ConsultantCommented:
Will be good to consider hashing password once received the input - ideally it should have  the server sends a random salt string in the login page which gets appended to the password in javascript in the browser and the SHA2 hash of the result gets then submitted back to the server for verification.
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

Dave BaldwinFixer of ProblemsCommented:
How can I encrypt the client side password so that it cannot be viewed in the html markup?
I don't believe you can, other people's web pages are not under your control.  Except that you should not allow others to use your computer where they can get that info.  I think that you will see that not even the biggest web sites like Google and Amazon do anything to prevent what you are seeing.

Also, it has become common to have a checkbox to show the password in plain text because too many people have had trouble remembering or typing their passwords correctly.

For 'real' security, many other things are done in addition to username and password.  Your bank and even Facebook know when a login is used from a different computer.
btanExec ConsultantCommented:
actually if you have proxy in the browser, the clear password entered can still be seen likely hence it is not silver bullet and there isn't any either... but do aovid having the password only which is in my post suggested salted password to reduce hijacked password from being replayed by attacker for having new session.

Also do avoid storing password file in server or txt file, it is not going to help and using of autocomplete is not advisable. for the "hiding" of password, I rather avoid that and have a challenge and response instead, every user login session using second factor where all e-services are moving too - esp applicable if your apps is dealing with sensitive or transactional tasks. Need to avoid being easily brute force as well not with simple password and 2FA may help.
Rich RumbleSecurity SamuraiCommented:
Security 101, don't use browsers to remember your password :) There are html markup tag that tell browsers they should not memorize or prompt to memorize (autocomplete="off"), but you can't encrypt them in the box before they are sent, how will the other side know what the password is? Encryption doesn't work that way, have a look at my introduction article to hashing and encryption here:
Client-side what your seeing with F12 is how it HAS to be. Same thing when you login windows... your password is plain-text, hidden by *******'s, if you were to inspect the GINA you'd find your password sitting there in plain-text. When you hit OK, the plain-text is hashed by the gina, and then compared to the hash stored in the SAM database, or the AD db. There is no other way.
If you want more layers to your security, many services offer 2-factor auth, start using those. FB, Twitter, Gmail etc... all offer 2nd factor authentication.
btanExec ConsultantCommented:
which if the browser is intercepted or machine is infected with keylogger, all the user keys in will still be in "clear" - what is important as shared by all in this forum, so far is to back to security basic - secure by default, go for secure coding practice. OWASP has reference, here is one in 2010 (I believe there will be newer one but it suffice to emphasis the purpose) - see "Authentication and Password Management"
 If your application manages a credential store, it should ensure that only cryptographically strong one-way salted hashes of passwords are stored and that the table/file that stores the passwords and keys is write-able only by the application. (Do not use the MD5 algorithm if it can be avoided)

 Password hashing must be implemented on a trusted system (e.g., The server).

 Authentication credentials for accessing services external to the application should be encrypted and stored in a protected location on a trusted system (e.g., The server). The source code is NOT a secure location

 Use only HTTP POST requests to transmit authentication credentials

 Only send non-temporary passwords over an encrypted connection or as encrypted data, such as in an encrypted email. Temporary passwords associated with email resets may be an exception
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.