브라우저 '비밀번호 저장'기능 비활성화

StackOverflow https://stackoverflow.com/questions/32369

문제

정부 의료 기관에서 일하는 즐거움 중 하나는 PHI (Protected Health Information)를 다루는 모든 편집증에 대처해야한다는 것입니다. 오해하지 마세요. 저는 사람들의 개인 정보 (건강, 재정, 서핑 습관 등)를 보호하기 위해 가능한 모든 일을 다했지만 때로는 사람들이 너무 불안해합니다.

사례 : 최근 Google 주 고객 중 한 명이 브라우저가 귀하의 비밀번호를 저장하는 편리한 기능을 제공한다는 사실을 발견했습니다. 우리 모두는 그것이 한동안 거기에 있었고 완전히 선택 사항이며 사용하는 것이 현명한 결정인지 여부를 결정하는 최종 사용자에게 달려 있음을 알고 있습니다. 그러나 현재 약간의 소란이 있으며 사이트에서 해당 기능을 비활성화하는 방법을 찾아야합니다.

질문 : 사이트에서 브라우저에 비밀번호 기억을 제안하지 않도록 지시하는 방법이 있습니까? 저는 웹 개발을 오랫동안 해왔지만 전에는 그것을 접한 적이 없습니다.

어떤 도움을 주시면 감사하겠습니다.

도움이 되었습니까?

해결책

모든 브라우저에서 작동하는지 확실하지 않지만 양식에서 autocomplete="off"를 설정해야합니다. 라코 디스 <인용구>

양식 및 비밀번호 저장 프롬프트 를 비활성화하고 양식 데이터가 세션 기록에 캐시되지 않도록하는 가장 쉽고 간단한 방법은 값이 "off"인 자동 완성 양식 요소 속성을 사용하는 것입니다.

http://developer.mozilla.org/En/How_to_Turn_Off_Form_Autocompletion 에서

몇 가지 사소한 연구에 따르면 이것이 IE에서 작동하는 것으로 나타 났지만 보장 할 수는 없습니다.)

@Joseph : XHTML 유효성 검사를 통과해야하는 엄격한 요구 사항 실제 마크 업 (왜 그런지 모르겠 음)은 이론적으로 나중에 자바 스크립트를 사용하여이 속성을 추가 할 수 있지만 js가 비활성화 된 사용자 (아마도 js가 필요한 경우 무시할 수있는 사용자 기반 또는 0)는 여전히 암호를 가지고 있습니다. 저장되었습니다.

jQuery를 사용한 예 : 라코 디스

다른 팁

나는이 문제에 대한 독특한 비틀림과 함께 한동안이 문제로 고심하고 있었다. 권한이있는 사용자는 저장된 암호를 사용할 수 없었지만 일반 사용자에게는 필요했습니다. 즉, 권한이있는 사용자는 두 번 로그인해야했고 두 번째는 저장된 암호를 적용하지 않았습니다.

이 요구 사항에 따라 표준 autocomplete="off" 방법은 모든 브라우저에서 작동하지 않습니다. 비밀번호가 처음 로그인 할 때 저장되었을 수 있기 때문입니다. 동료가 새 암호 필드로 초점이 맞춰 졌을 때 암호 필드를 대체하는 솔루션을 찾은 다음 새 암호 필드에 초점을 맞 춥니 다 (그런 다음 동일한 이벤트 핸들러를 연결). 이것은 작동했습니다 (IE6에서 무한 루프를 일으킨 것을 제외하고). 그 문제를 해결하는 방법이 있었을 수도 있지만 편두통을 일으켰습니다.

마지막으로 양식 외부에 사용자 이름과 비밀번호 만 사용하려고했습니다. 놀랍게도 이것은 효과가있었습니다! IE6과 Linux의 Firefox 및 Chrome 최신 버전에서 작동했습니다. 더 이상 테스트하지는 않았지만 모든 브라우저는 아니지만 대부분의 브라우저에서 작동한다고 생각합니다.

다음은 작동을위한 jQuery와 함께 몇 가지 샘플 코드입니다. 라코 디스

그냥 사용 <인용구>

readonly onfocus="this.removeAttribute ( 'readonly');"

외 <인용구>

autocomplete="off"

아래에 표시된 것처럼 양식 데이터 (username, password 등)를 기억하지 않으려는 입력에 : 라코 디스

주요 브라우저의 최신 버전 (예 : Google Chrome, Mozilla Firefox, Microsoft Edge 등)에서 테스트되었으며 매력처럼 작동합니다.도움이 되었기를 바랍니다 ...

글쎄요, 아주 오래된 글이지만, 저희 팀이 오랫동안 달성하려고 노력해 왔던 해결책을 제공하겠습니다.양식에 새로운 input type="password"필드를 추가하고 div로 감싸고 div를 숨겼습니다.이 div가 실제 비밀번호 입력 전에 있는지 확인했습니다. 이것은 우리에게 효과가 있었고 암호 저장 옵션을 제공하지 않았습니다.

Plunk- http://plnkr.co/edit/xmBR31NQMUgUhYHBiZSg?p=preview

HTML : 라코 디스

CSS : 라코 디스

각 쇼의 비밀번호 필드에 사용 된 이름을 무작위로 지정하여 브라우저가 양식과 일치하지 않도록 할 수 있습니다.그러면 브라우저는 URL과 동일한 비밀번호를 볼 수 있지만 동일한 비밀번호 인지 확신 할 수 없습니다.다른 것을 제어하고있을 수도 있습니다.

업데이트 : 이는 다른 사람이 지적한 이유로 자동 완성 또는 기타 전술을 대체하는 것이 아니라 사용하는 추가 해야합니다.

또한 이렇게하면 브라우저가 비밀번호를 자동 완성 하는 것만 방지합니다.브라우저가 사용하기로 선택한 임의 수준의 보안에서 비밀번호를 저장 하는 것을 막지는 않습니다.

Use real two-factor authentication to avoid the sole dependency on passwords which might be stored in many more places than the user's browser cache.

The cleanest way is to use autocomplete="off" tag attribute but Firefox does not properly obey it when you switch fields with Tab.

The only way you could stop this is to add a fake hidden password field which tricks the browser to populate the password there.

<input type="text" id="username" name="username"/>
<input type="password" id="prevent_autofill" autocomplete="off" style="display:none" tabindex="-1" />
<input type="password" id="password" autocomplete="off" name="password"/>

It is an ugly hack, because you change the browser behavior, which should be considered bad practice. Use it only if you really need it.

Note: this will effectively stop password autofill, because FF will "save" the value of #prevent_autofill (which is empty) and will try to populate any saved passwords there, as it always uses the first type="password" input it finds in DOM after the respective "username" input.

I have tested that adding autocomplete="off" in form tag in all major browsers. In fact, Most of the peoples in US using IE8 so far.

  1. IE8, IE9, IE10, Firefox, Safari are works fine.

    Browser not asking "save password". Also, previously saved username & password not populated.

  2. Chrome & IE 11 not supporting the autocomplete="off" feature
  3. FF supporting the autocomplete="off". but sometimes existing saved credentials are populated.

Updated on June 11, 2014

Finally, below is a cross browser solution using javascript and it is working fine in all browsers.

Need to remove "form" tag in login form. After client side validation, put that credentials in hidden form and submit it.

Also, add two methods. one for validation "validateLogin()" and another for listening enter event while click enter in textbox/password/button "checkAndSubmit()". because now login form does not have a form tag, so enter event not working here.

HTML

<form id="HiddenLoginForm" action="" method="post">
<input type="hidden" name="username" id="hidden_username" />
<input type="hidden" name="password" id="hidden_password" />
</form>

Username: <input type="text" name="username" id="username" onKeyPress="return checkAndSubmit(event);" /> 
Password: <input type="text" name="password" id="password" onKeyPress="return checkAndSubmit(event);" /> 
<input type="button" value="submit" onClick="return validateAndLogin();" onKeyPress="return checkAndSubmit(event);" />

Javascript

//For validation- you can modify as you like
function validateAndLogin(){
  var username = document.getElementById("username");
  var password = document.getElementById("password");

  if(username  && username.value == ''){
    alert("Please enter username!");
    return false;
  }

  if(password && password.value == ''){
    alert("Please enter password!");
    return false;
  }

  document.getElementById("hidden_username").value = username.value;
  document.getElementById("hidden_password").value = password.value;
  document.getElementById("HiddenLoginForm").submit();
}

//For enter event
function checkAndSubmit(e) {
 if (e.keyCode == 13) {
   validateAndLogin();
 }
}

Good luck!!!

Not really - the only thing you could realistically do is offer advice on the site; maybe, before their first time signing in, you could show them a form with information indicating that it is not recommended that they allow the browser to store the password.

Then the user will immediately follow the advice, write down the password on a post-it note and tape it to their monitor.

What I have been doing is a combination of autocomplete="off" and clearing password fields using a javascript / jQuery.

jQuery Example:

$(function() { 
    $('#PasswordEdit').attr("autocomplete", "off");
    setTimeout('$("#PasswordEdit").val("");', 50); 
});

By using setTimeout() you can wait for the browser to complete the field before you clear it, otherwise the browser will always autocomplete after you've clear the field.

if autocomplete="off" is not working...remove the form tag and use a div tag instead, then pass the form values using jquery to the server. This worked for me.

Because autocomplete="off" does not work for password fields, one must rely on javascript. Here's a simple solution based on answers found here.

Add the attribute data-password-autocomplete="off" to your password field:

<input type="password" data-password-autocomplete="off">

Include the following JS:

$(function(){
    $('[data-password-autocomplete="off"]').each(function() {
        $(this).prop('type', 'text');
        $('<input type="password"/>').hide().insertBefore(this);
        $(this).focus(function() {
            $(this).prop('type', 'password');
        });
    });     
});

This solution works for both Chrome and FF.

Just so people realise - the 'autocomplete' attribute works most of the time, but power users can get around it using a bookmarklet.

Having a browser save your passwords actually increases protection against keylogging, so possibly the safest option is to save passwords in the browser but protect them with a master password (at least in Firefox).

I have a work around, which may help.

You could make a custom font hack. So, make a custom font, with all the characters as a dot / circle / star for example. Use this as a custom font for your website. Check how to do this in inkscape: how to make your own font

Then on your log in form use:

<form autocomplete='off'  ...>
   <input type="text" name="email" ...>
   <input type="text" name="password" class="password" autocomplete='off' ...>
   <input type=submit>
</form>

Then add your css:

@font-face {
    font-family: 'myCustomfont';
    src: url('myCustomfont.eot');
    src: url('myCustomfont?#iefix') format('embedded-opentype'),
         url('myCustomfont.woff') format('woff'),
         url('myCustomfont.ttf') format('truetype'),
         url('myCustomfont.svg#myCustomfont') format('svg');
    font-weight: normal;
    font-style: normal;

}
.password {
  font-family:'myCustomfont';
}

Pretty cross browser compatible. I have tried IE6+, FF, Safari and Chrome. Just make sure that the oet font that you convert does not get corrupted. Hope it helps?

Markus raised a great point. I decided to look up the autocomplete attribute and got the following:

The only downside to using this attribute is that it is not standard (it works in IE and Mozilla browsers), and would cause XHTML validation to fail. I think this is a case where it's reasonable to break validation however. (source)

So I would have to say that although it doesn't work 100% across the board it is handled in the major browsers so its a great solution.

The simplest way to solve this problem is to place INPUT fields outside the FORM tag and add two hidden fields inside the FORM tag. Then in a submit event listener before the form data gets submitted to server copy values from visible input to the invisible ones.

Here's an example (you can't run it here, since the form action is not set to a real login script):

<!doctype html>
<html>
<head>
  <title>Login & Save password test</title>
  <meta charset="utf-8">
  <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js"></script>
</head>

  <body>
      <!-- the following fields will show on page, but are not part of the form -->
      <input class="username" type="text" placeholder="Username" />
      <input class="password" type="password" placeholder="Password" />

      <form id="loginForm" action="login.aspx" method="post">
        <!-- thw following two fields are part of the form, but are not visible -->
        <input name="username" id="username" type="hidden" />
        <input name="password" id="password" type="hidden" />
        <!-- standard submit button -->
        <button type="submit">Login</button>
      </form>

    <script>
      // attache a event listener which will get called just before the form data is sent to server
      $('form').submit(function(ev) {
        console.log('xxx');
        // read the value from the visible INPUT and save it to invisible one
        // ... so that it gets sent to the server
        $('#username').val($('.username').val());
        $('#password').val($('.password').val());
      });
    </script>

  </body>
</html>

My js (jquery) workaround is to change password input type to text on form submit. The password could become visible for a second, so I also hide the input just before that. I would rather not use this for login forms, but it is useful (together with autocomplete="off") for example inside administration part of the website.

Try putting this inside a console (with jquery), before you submit the form.

$('form').submit(function(event) {
    $(this).find('input[type=password]').css('visibility', 'hidden').attr('type', 'text');
});

Tested on Chrome 44.0.2403.157 (64-bit).

I tried above autocomplete="off" and yet anything successful. if you are using angular js my recommendation is to go with button and the ng-click. 

<button type="button" class="" ng-click="vm.login()" />

This already have a accepted answer im adding this if someone cant solve the problem with the accepted answer he can go with my mechanism.

Thanks for the question and the answers.

I tested lots of solutions. Dynamic password field name, multiple password fields (invisible for fake ones), changing input type from "text" to "password", autocomplete="off", autocomplete="new-password",... but nothing solved it with recent browser.

To get rid of password remember, I finally treated the password as input field, and "blur" the text typed.

It is less "safe" than a native password field since selecting the typed text would show it as clear text, but password is not remembered. It also depends on having Javascript activated.

You will have estimate the risk of using below proposal vs password remember option from navigator.

While password remember can be managed (disbaled per site) by the user, it's fine for a personal computer, not for a "public" or shared computer.

I my case it's for a ERP running on shared computers, so I'll give it a try to my solution below. 

<input style="background-color: rgb(239, 179, 196); color: black; text-shadow: none;" name="password" size="10" maxlength="30" onfocus="this.value='';this.style.color='black'; this.style.textShadow='none';" onkeypress="this.style.color='transparent'; this.style.textShadow='1px 1px 6px green';" autocomplete="off" type="text">

One way I know is to use (for instance) JavaScript to copy the value out of the password field before submitting the form.

The main problem with this is that the solution is tied to JavaScript.

Then again, if it can be tied to JavaScript you might as well hash the password on the client-side before sending a request to the server.

The real problem is much deeper than just adding attributes to your HTML - this is common security concern, that's why people invented hardware keys and other crazy things for security.

Imagine you have autocomplete="off" perfectly working in all browsers. Would that help with security? Of course, no. Users will write down their passwords in textbooks, on stickers attached to their monitor where every office visitor can see them, save them to text files on the desktop and so on.

Generally, web application and web developer isn't responsible in any way for end-user security. End-users can protect themselves only. Ideally, they MUST keep all passwords in their head and use password reset functionality (or contact administrator) in case they forgot it. Otherwise there always will be a risk that password can be seen and stolen somehow.

So either you have some crazy security policy with hardware keys (like, some banks offer for Internet-banking which basically employs two-factor authentication) or NO SECURITY basically. Well, this is a bit over exaggerated of course. It's important to understand what are you trying to protect against:

  1. Not authorised access. Simplest login form is enough basically. There sometimes additional measures taken like random security questions, CAPTCHAs, password hardening etc.
  2. Credential sniffing. HTTPS is A MUST if people access your web application from public Wi-Fi hotspots etc. Mention that even having HTTPS, your users need to change their passwords regularly.
  3. Insider attack. There are two many examples of such, starting from simple stealing of your passwords from browser or those that you have written down somewhere on the desk (does not require any IT skills) and ending with session forging and intercepting local network traffic (even encrypted) and further accessing web application just like it was another end-user.

In this particular post, I can see inadequate requirements put on developer which he will never be able to resolve due to the nature of the problem - end-user security. My subjective point is that developer should basically say NO and point on requirement problem rather than wasting time on such tasks, honestly. This does not absolutely make your system more secure, it will rather lead to the cases with stickers on monitors. Unfortunately, some bosses hear only what they want to hear. However, if I was you I would try to explain where the actual problem is coming from, and that autocomplete="off" would not resolve it unless it will force users to keep all their passwords exclusively in their head! Developer on his end cannot protect users completely, users need to know how to use system and at the same time do not expose their sensitive/secure information and this goes far beyond authentication.

Facing the same HIPAA issue and found a relatively easy solution,

  1. Create a hidden password field with the field name as an array.

    <input type="password" name="password[]" style="display:none" />

  2. Use the same array for the actual password field.

    <input type="password" name="password[]" />

The browser (Chrome) may prompt you to "Save password" but regardless if the user selects save, the next time they login the password will auto-populate the hidden password field, the zero slot in the array, leaving the 1st slot blank.

I tried defining the array, such as "password[part2]" but it still remembered. I think it throws it off if it's an unindexed array because it has no choice but to drop it in the first spot.

Then you use your programming language of choice to access the array, PHP for example,

echo $_POST['password'][1];

Since most of the autocomplete suggestions, including the accepted answer, don't work in today's web browsers (i.e. web browser password managers ignore autocomplete), a more novel solution is to swap between password and text types and make the background color match the text color when the field is a plain text field, which continues to hide the password while being a real password field when the user (or a program like KeePass) is entering a password. Browsers don't ask to save passwords that are stored in plain text fields.

The advantage of this approach is that it allows for progressive enhancement and therefore doesn't require Javascript for a field to function as a normal password field (you could also start with a plain text field instead and apply the same approach but that's not really HIPAA PHI/PII-compliant). Nor does this approach depend on hidden forms/fields which might not necessarily be sent to the server (because they are hidden) and some of those tricks also don't work either in several modern browsers.

jQuery plugin:

https://github.com/cubiclesoft/php-flexforms-modules/blob/master/password-manager/jquery.stoppasswordmanager.js

Relevant source code from the above link:

(function($) {
$.fn.StopPasswordManager = function() {
    return this.each(function() {
        var $this = $(this);

        $this.addClass('no-print');
        $this.attr('data-background-color', $this.css('background-color'));
        $this.css('background-color', $this.css('color'));
        $this.attr('type', 'text');
        $this.attr('autocomplete', 'off');

        $this.focus(function() {
            $this.attr('type', 'password');
            $this.css('background-color', $this.attr('data-background-color'));
        });

        $this.blur(function() {
            $this.css('background-color', $this.css('color'));
            $this.attr('type', 'text');
            $this[0].selectionStart = $this[0].selectionEnd;
        });

        $this.on('keydown', function(e) {
            if (e.keyCode == 13)
            {
                $this.css('background-color', $this.css('color'));
                $this.attr('type', 'text');
                $this[0].selectionStart = $this[0].selectionEnd;
            }
        });
    });
}
}(jQuery));

Demo:

https://barebonescms.com/demos/admin_pack/admin.php

Click "Add Entry" in the menu and then scroll to the bottom of the page to "Module: Stop Password Manager".

Disclaimer: While this approach works for sighted individuals, there might be issues with screen reader software. For example, a screen reader might read the user's password out loud because it sees a plain text field. There might also be other unforeseen consequences of using the above plugin. Altering built-in web browser functionality should be done sparingly with testing a wide variety of conditions and edge cases.

Is there a way for a site to tell the browser not to offer to remember passwords?

The website tells the browser that it is a password by using <input type="password">. So if you must do this from a website perspective then you would have to change that. (Obviously I don't recommend this).

The best solution would be to have the user configure their browser so it won't remember passwords.

If you do not want to trust the autocomplete flag, you can make sure that the user types in the box using the onchange event. The code below is a simple HTML form. The hidden form element password_edited starts out set to 0. When the value of password is changed, the JavaScript at the top (pw_edited function) changes the value to 1. When the button is pressed, it checks the valueenter code here before submitting the form. That way, even if the browser ignores you and autocompletes the field, the user cannot pass the login page without typing in the password field. Also, make sure to blank the password field when focus is set. Otherwise, you can add a character at the end, then go back and remove it to trick the system. I recommend adding the autocomplete="off" to password in addition, but this example shows how the backup code works.

<html>
  <head>
    <script>
      function pw_edited() {
        document.this_form.password_edited.value = 1;
      }
      function pw_blank() {
        document.this_form.password.value = "";
      }
      function submitf() {
        if(document.this_form.password_edited.value < 1) {
          alert("Please Enter Your Password!");
        }
        else {
         document.this_form.submit();
        }
      }
    </script>
  </head>
  <body>
    <form name="this_form" method="post" action="../../cgi-bin/yourscript.cgi?login">
      <div style="padding-left:25px;">
        <p>
          <label>User:</label>
          <input name="user_name" type="text" class="input" value="" size="30" maxlength="60">
        </p>
        <p>
          <label>Password:</label>
          <input name="password" type="password" class="input" size="20" value="" maxlength="50" onfocus="pw_blank();" onchange="pw_edited();">
        </p>
        <p>
          <span id="error_msg"></span>
        </p>
        <p>
          <input type="hidden" name="password_edited" value="0">
          <input name="submitform" type="button" class="button" value="Login" onclick="return submitf();">
        </p>
      </div>
    </form>
  </body>
</html>

autocomplete="off" does not work for disabling the password manager in Firefox 31 and most likely not in some earlier versions, too.

Checkout the discussion at mozilla about this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

We wanted to use a second password field to enter a one-time password generated by a token. Now we are using a text input instead of a password input. :-(

I was given a similar task to disable the auto-filling up of login name and passwords by browser, after lot of trial and errors i found the below solution to be optimal. Just add the below controls before your original controls.

<input type="text" style="display:none">
<input type="text" name="OriginalLoginTextBox">

<input type="password" style="display:none">
<input type="text" name="OriginalPasswordTextBox">

This is working fine for IE11 and Chrome 44.0.2403.107

autocomplete="off" works for most modern browsers, but another method I used that worked successfully with Epiphany (a WebKit-powered browser for GNOME) is to store a randomly generated prefix in session state (or a hidden field, I happened to have a suitable variable in session state already), and use this to alter the name of the fields. Epiphany still wants to save the password, but when going back to the form it won't populate the fields.

I haven't had any issues using this method:

Use autocomplete="off", add a hidden password field and then another non-hidden one. The browser tries to auto complete the hidden one if it doesn't respect autocomplete="off"

Another solution is to make the POST using an hidden form where all the input are of type hidden. The visible form will use input of type "password". The latter form will never be submitted and so the browser can't intercept at all the operation of login.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top