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.
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
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.
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.
If you're really worried about this, you could do away with passwords entirely in your application. Have the user enter their username or email and send them an email with a temporary login link.
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.
In Javascript, for already saved passwords, a way could be:
Someone can anyway read the password from the variable through javascript
for example:
console.log( passwordVAR );
