这是我的解决方案的html代码。它适用于Chrome-Safari-Internet Explorer。我创建了新的字体，所有字符看起来都是“●”。然后我使用这种字体作为密码文本。注意:我的字体名是“passwordsecreregular”。

<style type="text/css">
         #login_parola {
             font-family: 'passwordsecretregular' !important;
            -webkit-text-security: disc !important;
            font-size: 22px !important;
         }
    </style>


<input type="text" class="w205 has-keyboard-alpha"  name="login_parola" id="login_parola" onkeyup="checkCapsWarning(event)"  
   onfocus="checkCapsWarning(event)" onblur="removeCapsWarning()" onpaste="return false;" maxlength="32"/>

我不确定它是否能在所有浏览器中工作，但你应该尝试在表单上设置autocomplete="off"。

<form id="loginForm" action="login.cgi" method="post" autocomplete="off">

禁用表单和密码存储提示并防止表单数据在会话历史中缓存的最简单和最简单的方法是使用值为“off”的自动完成表单元素属性。

从https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

一些小研究表明，这可以在IE中工作，但我不能保证;)

@Joseph:如果严格要求通过实际标记的XHTML验证(不知道为什么会这样)，理论上你可以在之后用javascript添加这个属性，但禁用js的用户(可能可以忽略不计，如果你的网站需要js，则为零)仍然会保存他们的密码。

jQuery示例:

$('#loginForm').attr('autocomplete', 'off');

您可以通过在每个显示中随机为密码字段使用的名称来防止浏览器匹配表单。然后浏览器看到与url相同的密码，但不能确定这是相同的密码。也许它在控制其他东西。

更新:注意，这应该是使用自动补全或其他策略的补充，而不是替代它们，因为其他人指出的原因。

还要注意，这只会阻止浏览器自动完成密码。它不会阻止它以浏览器选择使用的任意安全级别存储密码。

真正的问题比在HTML中添加属性要深刻得多——这是常见的安全问题，这就是为什么人们为了安全发明了硬件密钥和其他疯狂的东西。

假设autocomplete="off"在所有浏览器中都能正常工作。这对安全有帮助吗?当然不是。用户将把密码写在课本上，写在每个办公室访客都能看到的显示器上贴的贴纸上，保存在桌面上的文本文件中等等。

一般来说，web应用程序和web开发人员不以任何方式对最终用户的安全负责。最终用户只能保护自己。理想情况下，他们必须把所有的密码都记在脑子里，并使用密码重置功能(或联系管理员)以防他们忘记密码。否则，总有一个风险，密码可以看到和窃取以某种方式。

所以，要么你对硬件密钥有一些疯狂的安全策略(比如，一些银行提供的网上银行基本上采用双因素认证)，要么基本上没有安全。当然，这有点夸张了。重要的是要了解你想要保护的是什么:

Not authorised access. Simplest login form is enough basically. There sometimes additional measures taken like random security questions, CAPTCHAs, password hardening etc. 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. 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.

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插件:

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

相关源代码来自上述链接:

(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));

演示:

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

点击菜单中的“添加条目”，然后滚动到页面底部的“模块:停止密码管理器”。

免责声明:虽然这种方法适用于视力正常的人，但屏幕阅读器软件可能存在问题。例如，屏幕阅读器可能会大声读出用户的密码，因为它看到的是纯文本字段。使用上述插件还可能产生其他不可预见的后果。改变内置的web浏览器功能应该通过测试各种各样的条件和边缘情况来进行。

我被给了一个类似的任务禁用自动填写登录名和密码的浏览器，经过大量的试验和错误，我发现下面的解决方案是最优的。只需在原始控件之前添加以下控件。

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

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

这在IE11和Chrome 44.0.2403.107上运行正常