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?
Is their a way to hide or encrypt the password when the html is inspected?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
http://www.codeproject.com/Articles/844722/Hashing-Passwords-using-ASP-NETs-Crypto-Class
http://programmers.stackexchange.com/questions/76939/why-almost-no-webpages-hash-passwords-in-the-client-before-submitting-and-hashi
http://www.codeproject.com/Articles/844722/Hashing-Passwords-using-ASP-NETs-Crypto-Class
http://programmers.stackexchange.com/questions/76939/why-almost-no-webpages-hash-passwords-in-the-client-before-submitting-and-hashi
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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)https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf
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
ASKER