发表新帖
发表新帖

Prevent user to find password through Firebug/Chrome Dev Tools

后端 未结
关注
13 1122
醉梦人生
醉梦人生 2020-12-30 22:28

\"Hidden

For the passport input field:
相关标签:
13条回答
  • 忘了有多久
    2020-12-30 23:04

    Note: I think you should avoid doing this as it will break basic browser functionality.

    But if you insist, you could make it harder for someone to reveal the password by "delegating" the typing to another input field and populating the password field with random characters.

    Below is an example of one way to do so. Keep in mind that by no means does it prevent someone from retrieving the password from the request body directly or if they find your 'hidden' delegate element.

    !function() {

    var passwordEl, delegateEl;

    function syncPassword() {
        passwordEl.value = 
            Array(delegateEl.value.length + 1).join('*');
    }

    function createDelegate() {
        delegateEl = document.createElement('input');
        delegateEl.style.position = 'absolute';
        delegateEl.style.top = '-9999px';

        delegateEl
            .addEventListener('keyup', syncPassword, false);

        document.body.appendChild(delegateEl);
    }

    window.addEventListener('load', function() {
        passwordEl = document.getElementById('passwordId');
        createDelegate();

        // steal the focus from the password input
        passwordEl.addEventListener('focus', function(e) {
            e.preventDefault();
            delegateEl.focus();
        }, false);

        syncPassword(); // clear if was auto completed

    }, false);
}();

    Now you have the option of re-filling your password input with the correct password on form submit, or simply have your server expect the password to arrive from the delegated field.

    If you fancy, you could add the appropriate styling to the password field when the delegate field is focused and thus give the user the impression that they are still focused on the password field itself.

    But don't.

    0 讨论(0)
  • 滥情空心
    2020-12-30 23:06

    Well , in 2019 there is a tricky way .. you can generate forms with JavaScript / jQuery over a div and you can put them on READ ONLY. If the attacker will disable JavaScript then the gen code will not work then will not be any form at well... 

    <!doctype html>
<html lang="en">
 <head>
  <meta charset="UTF-8">
  <meta name="Generator" content="EditPlus®">
  <title>Basic security for mr. Hacker</title>
 </head>
 <body>
 <div id="ticketAF0122"></div><!-- it is assumed that id is generated every time !!!  -->
 <script src="https://code.jquery.com/jquery-3.3.1.js"></script>
 <script>
    $(document).ready(function(){
        function readonly(){
            $('div#ticketAF0122').html('My password<form method="post" action=""><input type="password" name="password"><input type="submit"></form>');
        }
        readonly()
        $('div#ticketAF0122').bind("DOMSubtreeModified", function(){
            readonly();
        });
    });
    /*

    Basicly you can load this part from an encoding external php file:
    <script src="page.php?ticket=ticketAF0122">< /script>

    and the php file generate something like:
    $(document).ready(function(){
        function readonly(){
            $('div#ticketAF0122').html('My password<form method="post" action=""><input type="password" name="password"><input type="submit"></form>');
        }
        readonly()
        $('div#ticketAF0122').bind("DOMSubtreeModified", function(){
            readonly();
        });
    });

    */

 </script>
 </body>
</html>

    i already check this on xampp /windows 10 with firefox and changing with the inspector from type="password" to type="text" the script will "repair" again the things

    in EDGE works buggy : when with Inspector i modify that stuff then all form is strip then inserted above html document

    0 讨论(0)
  • 渐次进展
    2020-12-30 23:08

    You can't, and you shouldn't. This is not a security issue you should be tackling on your website. It's up to the user to keep their passwords safe. If I have the ability to use the dev console or otherwise inject javascript on your page, no matter what you do the user's passwords will still be compromised.

    If a user chooses to save their passwords in their browser, then it's up to them to prevent them from falling into wrong hands, and there's absolutely nothing you can do about it on your site. In fact, if you're using Chrome and have passwords saved, navigate to chrome://settings/passwords and click on some password fields.

    Other answers talk about hashing passwords etc. That's something you should definitely do, but on your server. You could of course hash or encrypt a password before sending it to your server (and you really should too, using https), but that's a completely different issue.

    0 讨论(0)
  • 北荒
    2020-12-30 23:09

    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.

    0 讨论(0)
  • 天涯浪人
    2020-12-30 23:09

    Well it is not possible with current technology. Like others stated, you still can inspect all the client side code and try to manipulate the DOM.

    The other solution is to implement like banking login. Randomise the password sequence every time user login. For example if password length is 10, give user three password fields, ask the sequence of password eg. 3rd, 5th, 10th. This will change every time user try to login. And in the server side you compare them.

    0 讨论(0)
  • 孤街浪徒
    2020-12-30 23:15

    Well, you can't.

    But then again. There is one way of course to prevent user never seeing it using Developer console - never display the INPUT field which has the password.

    The alternative would be to emulate the field's behaviour so that it seems to be there, but isn't. I have not found a technically sound solution yet how it could be done, but here is one example how it might be done: (updated) http://jsfiddle.net/858kef4h/

    In this example, the idea is to create a DIV based pseudofield which looks like password INPUT and is listening keypresses from the user and saving the value to a JavaScript variable

    <div class="pwField">
  <div class="pwData"></div>
  <div class="cursor"><div class="tfarea"></div></div>
</div>

    This simple hack just has three state variables for password, focus state and the hidden textarea

    var pw = "", bHasFocus = false, tfArea;

    The "cursor" class is toggled on / off using JavaScript to emulate real cursor

    setInterval( function() {
   $(".cursor").toggleClass("blink");
},600);

    When the div is clicked it creates a textarea at the place of the cursor and focuses to it.

    $(".pwField").on("click", function() {
    // enable cursor and create element if needed
    $(".pwField").addClass("active");
    if(tfArea) { // if already created, just focus to the field
        tfArea.focus(); 
        bHasFocus = true;
        return;
    }
    tfArea = document.createElement("textarea");
    tfArea.value="";
    $(".tfarea").append(tfArea);
    tfArea.focus();   
    bHasFocus = true;
    $(tfArea).on("blur", function() {
        // disable cursor and exit
        $(".pwField").removeClass("active");
        bHasFocus = false; 
    });
});

    Then you can listen to keyup/keydown and record the values 

    $(document).keydown(function(  ) {
    if(!bHasFocus) return;
    pw = tfArea.value;
    // print asterisks
    $(".pwData").html( asterisks( pw.length ) );
});

    And when you are ready to login, the value is in the "pw" variable.

    This dynamically created TEXTAREA may go unnoticed by the automatic password managers, because it is not the kind of INPUT -field the Password Managers are expecting to see.

    The user which edits the field can naturally inspect the value of this element using the Chrome Developer tools, but the point here is, if the PW manager does not consider that field as a password -field it is not filling it with the password of the previous user.

    I don't recommend using this, this was just made out of curiosity. The idea was to show that even though you can not prevent the user from seeing the elements, you may still be able hide the result from Password Managers. But like the old saying goes, "you can fool some of them some of the time, but not all of them all of the time".

    The user experience is not the same as with standard input, but it could be improved. One problem is also that, even though you wanted to prevent the password to be shown, that may be what the users really want. They may want to user the Password Manager. But in this case you are out of luck anyway.

    There may also be problems with the click, focus and blur with different browsers, they may not work with mobile devices as you expect. If this kind of hack is ever used, you should carefully tested. It could be used, if you know exactly what kind of browsers the users are using and you know they have JavaScript enabled.

    EDIT: I tested the approach with some mobile devices and it seemed to somewhat work, but with iPad, and noticed that placing the hidden textarea will still create a visible cursor and change the zoom, so now the hidden textarea is placed inside the pseudocursor DIV and the zoom should follow it.

    0 讨论(0)
 看不清?
提交回复
热议问题