Prevent User To Find Password Through Firebug/chrome Dev Tools

For the passport input field: When the <

Solution 1:

Short answer: It can not be prevented, unfortunately. This is because all client-side code (JavaScript) is modifiable by the client itself - thus making a client-based security system vulnerable.

The only workable solution I can think of, is to store a hashed representation of the password, instead of the raw password. This will (if you disregard hash-bruteforce attacks) keep the raw password safe.

A hash is a representation of the original text, and is non-reversable. That is, the original string of characters can not be retrieved by any algorithm, using only the hash. Examples of hash' is MD5 and SHA. This technique is commonly used in routers, where password often is stored in the browser.

Clarification: Never store your passwords in plain-text, and if you want to adopt this technique of pre-entered password; the hashing and/or encryption must occur on server side.

Solution 2:

I saw solutions in different answers. In all of them, it is just harder to see the password, but it does not prevent someone from seeing it.

Note: On client side JavaScript objects can be manipulated and inspected. In the solutions provided in other answers I could easily access the password information.

---

As others stated, you cannot prevent the user from viewing the password using developer tools on client side.

I could not think of a use case, but you mentioned automatic form filler and the Remember me option.

Automatic form filler, as far as I know are master password protected. They should be; I would not use one if I could not switch it on or off securely. In this case it is my responsibility to log out, whenever I am in situation of sharing a computer.

Remember me option, as often promoted by web sites, should only be used when it is your personal computer and you do not expect to share your device with another person. Don't use it or make sure no one else uses your account. Again, it is your responsibility.

Now, you still see a need to prevent such an attack. All I can come up with is the following:

1. There is no viable solution on client side. So your solution must work on server side.
2. On server side you can encrypt or hash the function. Please see this question for more details. I will discuss this further in the rest of this answer. You can opt for either solution, however implementation differs.

If you use encryption, then you can always decrypt.

That might help you in the following scenario: Keep the password always encrypted. They should always match. However, when the user wants to change his password it will be clear text. The user cannot type it in an encrypted form. You have to solve that. There are solutions. I am sure you get that.

If you use (encrypted) hashing, then it is very hard to crack. You cannot decrypt it.

This might help you in the following scenario: The server sends only the hashed version. This way no attacker can use this information. You need to design it accordingly, but I imagine you figure that out too.

Having said that, I really don't see an acceptable use case for your requirement.

Let me explain why. You want to prevent an attacker from seeing the password in case a user remembers the passwords or uses an automatic form filler. Well, if an attacker is able to access a user's computer he would be able to simply log in, why bother seeing the password?

There is a reason why companies like Google or Facebook did not bring in a solution for your use case. The went another path and trying to push for increased security by 2-factor authentication

If you can use that, do it. It does not solve the issue completely, but you can expect it to increase security. In particular it is harder for an attacker.

Solution 3:

As it is clientside, there is no real way to prevent this. In terms of a security model: we can't trust the client. On the other hand, however, there is no real way to implement this differently without the use of a third party device.

If you're willing to go through the trouble of having a third party device assist in authentication: have the website generate and show a random seed, have the device ask for the seed and password to generate a hash, and authenticate on the site using the hash. Of course, the hash will still be visible if you use a web debugger, but at least there's no point in storing/reading it as the hash will differ for each session. This isn't completely secure either, by the way, as this method is prone to chosen plaintext attack.

Kudos if you're willing to go through all this trouble though. I suppose you could write an app for this to have a smartphone function as the third party device.

Solution 4:

Absolutely not. You can't prevent the end user to manipulate the DOM from Developer tools or firebug.

Use of any client side trick can't prevent user to do that. Until or unless the browser restrict user's from doing that.

Solution 5:

    I believe the issue you are facing is multiple people using the same computer, and if one user saves their password on your site, then any one else that visits the site on the same pc will be able to manipulate the field to reveal the password.

    One way of preventing this from happening is to disable the auto-complete. autocomplete="off" Place this code in the input element and even if the password is saved, it shouldn't show up. <input autocomplete="off" type="text" required="" tabindex="2" class="std_textbox" placeholder="Enter your account password." id="pass" name="pass">

Pros You don't have to worry about users sharing computers, and passwords being revealed for the most part. ConsUsers may think their passwords are saved (and they can still save passwords) but when they get to your site, it will not show up. NOTE This isn't the full-proof way of preventing users form manipulating the form and retrieving other users passwords.

As a side note, if the site does not refresh after entering a password and user name the web browser will not ask to save the password. For example, using an ajax call in stead of form submit.

You can use JavaScript to erase the text inside the password field when the page loads. A better style would be adding the field when the page loads with JavaScript like so:var x = document.createElement("INPUT"); x.setAttribute("type", "password");

An alternative to the autocomplete="off" autocomplete alternative It involves generating a name from the backend and using it as the name of the fields so that the autocomplete will never know where to put your users saved data