发表新帖
发表新帖

Prevent user to find password through Firebug/Chrome Dev Tools

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

\"Hidden

For the passport input field:
相关标签:
13条回答
  • 太阳男子
    2020-12-30 23:16

    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.

    0 讨论(0)
  • 野的像风
    2020-12-30 23:16

        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.
    Cons
    Users 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

    0 讨论(0)
  • 南笙
    2020-12-30 23:17

    As already said, having a password in an input element will let the user easily reveal password.

    ...And as @Elyasin asks, you really should let us know what your use-case is.

    Being in the dark about your use-case, let's assume you have a website that users can subscribe to for a fee and you don't want multiple users sharing one person's login to get around paying your subscription fee.

    You might use cookie authentication to check that a user is subscribed to your site.

    1. When a new user subscribes, send them an email containing a link to a special registration page on your website.

    2. When the user follows that link, place a cookie on the user's computer indicating they are a valid subscriber.

    3. Create a landing page on your site. This landing page will read the cookie from the user's computer and authenticate that they are indeed a valid subscriber.

    4. All other pages on your site must redirect users to the landing page if those users don't have the validating cookie.

    5. Since un-subscribed users may be redirected to the landing page, you might offer to let them become subscribers on the landing page.

    6. If a subscribed user's subscription has expired, you take the cookie off the (now unsubscribed) user's computer the next time they visit your site. Like any unsubscribed user, you redirect them to the landing page.

    While it's true that cookies can be intercepted or stolen, it's usually beyond the casual user's ability to do so.

    If you want more security using cookies, you can capture a user's IP address when they initially subscribe. Then you can verify that the user both has a validating cookie and also is accessing from the same IP address they originally subscribe from. Of course, this limits the subscribe to using only their original IP address to access your site.

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

    You can use a simple Javascript code to store the password value in a variable onblur and then restore it onfoucs or/and onsubmit.

    Look at the following demo code and its online demo here:

    <!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>JS Bin</title>
<script>
password = '';
function setPasswordBack(){
  showPassword();
}
function hidePassword(){
  p = document.getElementById('pass');
  password = p.value;
  p.value = '*********';
}
function showPassword(){
  p = document.getElementById('pass');  
  p.type= "password"; 
  p.value = password;
}
</script>
</head>
<body>
<form action="" method="get" onsubmit="setPasswordBack()">
<input type="password" value="" name="password" id="pass" onblur="hidePassword()" onfocus="showPassword()" />
<input type="submit" />
</form>
</body>
</html>

    It is clear that solution is JavaScript dependent solution, so in the case of disabling javascript, you may use noscript asking for JavaScript enabled browser.

    0 讨论(0)
  • 我寻月下人不归
    2020-12-30 23:20

    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.

    0 讨论(0)
  • 南方客
    2020-12-30 23:23

    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.

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