# How to avoid reveal password in a form?

I've recently discover that if you use inspect element to see the source code of the Html, you can change this <input type="password"/> to <input type="text"/> then you can see the password revealed, So, how can I avoid that in angularJS? or pure Javascript?

Any dark in the light will be appreciated.

• Can you please describe the attack you are trying to prevent? Are you worried that I will type in my password, then I will make the change you suggested so that other people can see my password? :D – TTT Jan 28 '16 at 17:01
• Am I the only one that's confused by this question? Are we talking about the situation when a user enters a password, then someone physically attacks them and rips them off of their chair before they press enter, then fiddles with the page source so they can see the password that was entered in? I feel like I'm taking crazy pills! – TTT Jan 28 '16 at 17:21
• @TTT This could be a scenario that takes place like in this question I just asked where a user types in their password then leaves for whatever reason leaving the typed password in the box. – DasBeasto Jan 28 '16 at 17:33
• @DasBeasto - that is not something I would worry about. The user would have to type in their password, not press enter, leave their workstation unlocked, walk away, and this has to be on a shared computer or in a public setting. If you're worried about that, you should also worry that the user will write their password on a piece of paper and leave it next to the keyboard, and you should be much more concerned about someone installing a keylogger on the machine. – TTT Jan 28 '16 at 17:40
• This is basically a case of 'if an attacker has access to your machine, its not your machine anymore'. Similar statements are true even on the server side. – David Grinberg Jan 28 '16 at 17:48

This sounds like a bad case of Security Theater

Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it.

I say this because in all reality...

Given enough time, effort, and computing power security is nothing more than a delay.

Of course it gets worse than that. Javascript is an computer based language, which means it must be run by a machine. That machine can be told to ignore your Javascript.

What this really means though is that you're asking the wrong question. What you're really asking:

How do you keep your forms safe from someone using saved passwords to fill out the form, and then changing the type of the form to read it?

And to this answer it's pretty simple:
Keep your terminal safe and secure. The only way to prevent this kind of attack is to not let an attacker on a system with a saved password in the first place.

Why? Because you have a "spectrum". Let's call it the security spectrum in this simplified example:
At the basis of simple security you have the following:

Security >----------------------------------------------< Ease of Use

In most cases this is what happens:
The more Security you have, the less Ease of Use you have.
The more Ease of Use you have, the less Security you have.

By using a form that has a password in it and leaving it there, you are increasing your Ease of Use and decreasing your Security

• Pedantry: it's not just a spectrum. Some people decrease ease of use without doing anything to increase security. In other cases, you can increase security without decreasing ease of use. – Michael Jan 28 '16 at 18:39
• Javascript being interpreted has nothing to do with the problem. Even if it were compiled (which it frequently is), the browser could still ignore and not run it. – user2357112 Jan 28 '16 at 18:47
• @Michael this was a simplified example, so I'll clarify that. – Robert Mennell Jan 28 '16 at 19:37
• Now I am wondering what is the point of asking for system password when opening Chrome's manage password. Attacker can easily know the password from the auto-populated fields. Only benefit is he won't be able to list down the saved passwords at one go. – aaa Jan 29 '16 at 0:44
• @aaa that is kind of the idea. If you have left your information in an area where someone can get access to the debugger you have used your computer in an unsafe location in a bad way, which is already a breach of security – Robert Mennell Apr 4 '16 at 20:20

There is no way to prevent an attacker doing this if they are already accessing the developer tools - they can simply pause the javascript and continue what they are doing. The best you may be able to do is clear the password box after a small amount of inactivity.

• Note that clearing the password field with Javascript may not work against CTRL+Z. – Mark Buffalo Jan 28 '16 at 16:59
• No way to prevent an attacker from doing what exactly? Looking at their own password? – TTT Jan 28 '16 at 17:17
• I assumed he is worrying about people leaving their login details on the screen while they make a Coffee, and an attacker using the vector he described to see it – William Dunne Jan 28 '16 at 18:26
• @WilliamDunne - yep. I probably could have deleted my comment here after we clarified it up above. – TTT Jan 28 '16 at 18:52
• I'll add to thiscomment that if i have access to developer tool i can see every request sent by the browser with their data non-encrypted (even if HTTPS) so i'll be able to see the password there too. – Walfrat Jan 29 '16 at 11:07

The bottom line is that you can't, but this is not as much of an issue as one might think.

The thing to keep in mind is that when you change the source in a browser's debugger (which is what you're describing), it doesn't get saved anywhere. This means that the change only affects the machine the debugger is running on. I can't change the password field to 'text' on everyone's machine, just mine. It also means that the change only takes effect until the next time the page is loaded, so even if I set it up once, I can't turn a machine into a password-collecting robot by doing this.

Another thing to keep in mind is that scripts don't have to change the password field's type to get at its value. They can get it through plain old scripting, and there are very real advantages to doing it that way. The biggest is that since you don't change the field's type, the user doesn't see anything unusual, so users aren't tipped off that something could be wrong.

Now, all of this said, you do have to be wary of cross-site scripting attacks, which can do the sorts of things you mention (though they still don't have to change the field's type to get its value). There are already a number of best practices to avoid XSS attacks, and the common XSS filter evasion methods are well known, so you can test against them too. None of these will stop the debugger trick, but as I outlined above, the debugger trick doesn't need to be stopped: XSS does.

The bottom line is that you don't need to be alarmed about the browser debugger. There are related attacks that you should be worried about, but they're well-studied, and none of them involve the browser debugger.

You can not do this because all things are happening on the client side and he has almost full access to your code (html, css, javascript) using developer tools. So, he can pause or stop javascript.

• Sure, but the user may not be logged into their email on the same computer and it prevents the potential to expose a password which the user may use on other sites. If someone has access to your email they can already easily reset your password on most sites. In reality, the whole scenario is a bit ridiculous and there's not much you can do as a developer, as other answers have stated. – Sam Jan 29 '16 at 15:47

You can't. The form needs to be able to send the password to the server for validation. Even if you develop some kind of obfuscation technique (not recommended) then, like William Dunne said, you can simply pause/stop Javascript.

You are trying to achieve security through obscurity, and it won't work.

You might be able to use divs and other elements to make your own text field, kinda like the text fields on google forms. If you did this, you could set it up so that as the user types, it just modifies the content of a encrypted JavaScript variable, and does not actually type in the text field.

1. save the value of the input in a variable
2. replace the value the input with a random sting with the same length

console.log( passwordVAR );