Desativar a funcionalidade 'Salvar senha' do navegador


423

Uma das alegrias de trabalhar para uma agência de saúde do governo é ter que lidar com toda a paranóia de lidar com PHI (Informações Protegidas de Saúde). Não me interpretem mal, sou a favor de fazer todo o possível para proteger as informações pessoais das pessoas (saúde, finanças, hábitos de surf etc.), mas às vezes as pessoas ficam um pouco nervosas.

Caso em questão: um de nossos clientes estaduais descobriu recentemente que o navegador fornece o recurso útil para salvar sua senha. Todos sabemos que ele já existe há algum tempo e é completamente opcional e cabe ao usuário final decidir se é ou não uma decisão inteligente usar ou não. No entanto, há um alvoroço no momento e estamos sendo solicitados a encontrar uma maneira de desativar essa funcionalidade para o nosso site.

Pergunta : Existe uma maneira de um site dizer ao navegador para não se lembrar de senhas? Estive em desenvolvimento web há muito tempo, mas não sei que já me deparei com isso antes.

Qualquer ajuda é apreciada.


6
Você deve fornecer um script greasemonkey para que as pessoas possam reativá-lo. Eu não acho que os usuários gostem de ser forçados a digitar a senha todas as vezes ...
ThiefMaster 20/12/11

14
A questão merece um voto positivo por ser útil e clara. Por outro lado, não quero que as pessoas encontrem uma solução para esse "problema".
22712 Ian Boyd

11
Isso nem sempre é um "problema". Eu vim aqui porque o Firefox pede para salvar uma senha para um formulário que contenha senha WiFi / SSID, não para um formulário de nome de usuário / senha de login. É muito chato e eu quero parar com isso.
SRD

1
Se a informação é crítica, ela deve ser protegida por mais do que apenas uma senha.
Sam Watkins

Uma maneira que parece funcionar é não usar <form>. Se você estiver usando o javascript para enviar os dados (XHR), não precisará deles. Eu queria desabilitar em um sistema que usa autenticação "senha única" (sem motivo para armazená-lo). Para autenticação de usuário / senha, eu não recomendaria desativar esse recurso.
Lepe

Respostas:


322

Não tenho certeza se funcionará em todos os navegadores, mas você deve tentar definir o preenchimento automático = "desativado" no formulário.

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

A maneira mais fácil e simples de desativar os prompts de armazenamento de Formulário e Senha e impedir que os dados do formulário sejam armazenados em cache no histórico da sessão é usar o atributo de elemento de formulário de preenchimento automático com o valor "off".

De http://developer.mozilla.org/En/How_to_Turn_Off_Form_Autocompletion

Algumas pesquisas menores mostram que isso funciona no IE, mas não deixarei garantias;)

@ Joseph : Se for um requisito estrito passar a validação XHTML com a marcação real (não sei por que isso seria), teoricamente você poderia adicionar esse atributo com javascript posteriormente, mas usuários com js desativado (provavelmente uma quantidade negligenciável de sua base de usuários ou zero se o site exigir js) ainda terá suas senhas salvas.

Exemplo com jQuery:

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

48
Apenas um comentário rápido, já que isso está mudando, o HTML5 adiciona o atributo de preenchimento automático à especificação, portanto é válido agora.
precisa saber é o seguinte

11
Apenas para sua informação, a Microsoft decidiu que o Internet Explorer 11 não será mais aceito autocomplete="off"pelos input type="password"campos. msdn.microsoft.com/pt-br/library/ie/ms533486%28v=vs.85%29.aspx
JW Lim

6
Assim como o @JWLim mencionou o IE 11, cancelando o suporte para desativar a funcionalidade de salvar senha, o Firefox também. bugzilla.mozilla.org/show_bug.cgi?id=956906
Gregory Cosmo Haun

3
O Firefox (infelizmente) seguiu o exemplo da Microsoft e "removeu" também o suporte ao preenchimento automático. Para obter detalhes, consulte o comentário 100 na discussão da edição a seguir: bugzilla.mozilla.org/show_bug.cgi?id=956906
Bouncing Bit

8
Agora, não funcione para o Firefox 38+ mozilla.org/pt-BR/firefox/38.0/releasenotes
Illuminator

44

Além de

autocomplete="off"

Usar

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

para as entradas que você não quer que eles se lembrem de dados do formulário ( username, password, etc.) como mostrado abaixo:

<input type="text" name="UserName" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

<input type="password" name="Password" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

Testado nas versões mais recentes dos principais navegadores, ou seja Google Chrome, Mozilla Firefox, Microsoft Edge, etc, e funciona como um encanto. Espero que isto ajude.


2
@Murat Yıldız: Eu tenho que implementar o mesmo e segui seu código. Está funcionando bem para mim em todos os navegadores. Obrigado !
Sree

1
@Sree Estou feliz que tenha sido útil para você :) #
Murat Yıldız

3
Acabei de testar o Mozilla Firefox 52.0 , o Google Chrome 57.0 , o Microsoft Edge 38.1 e funcionando como um encanto! ..
Murat Yıldız

1
Não pode haver um erro no Safari móvel como esta resposta é corrigi-lo stackoverflow.com/questions/2530/...
Ferie

1
O Windows Firefox 57.0.2 (64 bits) ainda está sugerindo salvar a senha após a implementação.
Panu Haaramo

37

Eu estava lutando com esse problema há um tempo, com uma reviravolta única no problema. Usuários privilegiados não poderiam ter as senhas salvas para eles, mas usuários normais precisavam disso. Isso significava que usuários privilegiados precisavam fazer login duas vezes, a segunda vez sem impor senhas salvas.

Com esse requisito, o autocomplete="off"método padrão não funciona em todos os navegadores, porque a senha pode ter sido salva no primeiro login. Um colega encontrou uma solução para substituir o campo de senha quando ele era focado por um novo campo de senha e depois focar no novo campo de senha (depois conecte o mesmo manipulador de eventos). Isso funcionou (exceto que causou um loop infinito no IE6). Talvez houvesse uma maneira de contornar isso, mas estava me causando uma enxaqueca.

Por fim, tentei apenas ter o nome de usuário e a senha fora do formulário. Para minha surpresa, isso funcionou! Ele funcionou no IE6 e nas versões atuais do Firefox e Chrome no Linux. Não testei mais, mas suspeito que funcione na maioria dos navegadores, se não em todos (mas não me surpreenderia se houvesse um navegador lá fora que não se importasse se não houvesse forma).

Aqui está um exemplo de código, juntamente com alguns jQuery para fazê-lo funcionar:

<input type="text" id="username" name="username"/>
<input type="password" id="password" name="password"/>

<form id="theForm" action="/your/login" method="post">
  <input type="hidden" id="hiddenUsername" name="username"/>
  <input type="hidden" id="hiddenPassword" name="password"/>
  <input type="submit" value="Login"/>
</form>

<script type="text/javascript" language="JavaScript">
  $("#theForm").submit(function() {
    $("#hiddenUsername").val($("#username").val());
    $("#hiddenPassword").val($("#password").val());
  });
  $("#username,#password").keypress(function(e) {
    if (e.which == 13) {
      $("#theForm").submit();
    }
  });
</script>

1
Parece uma boa solução. Faz sentido, pois o formulário que você envia não inclui uma senha. Suponho que você tenha dois formulários, o primeiro apenas para garantir que o nome de usuário e a senha estejam visíveis em todos os navegadores.
Alexis Wilke

3
Eu gosto da sua solução e implementei uma similar no meu site, é ridículo como hoje, os navegadores não oferecem uma maneira simples de resolver isso.
AgelessEssence 27/03

Não tenho certeza se é porque eu estou preso usando o jquery 1.6, mas o jquery acima só funcionou após quebrar dentro de um $ (document) .ready (function () {});
rgbflawed

A única alma correta é essa, pois alguns navegadores não aceitam mais o preenchimento automático = "off"!
Abadis 19/01/2015

1
Eu apenas tentei esse método no chrome, opera e internet explorer e parece funcionar, mas não funciona com o Firefox de forma imprudente
chenks

29

Bem, é um post muito antigo, mas ainda vou dar a minha solução, que minha equipe estava tentando alcançar há muito tempo. Acabamos de adicionar um novo campo type = "password" dentro do formulário e agrupá-lo em div e ocultá-lo. Verifique se essa div está antes da entrada da senha real. Isso funcionou para nós e não deu nenhuma opção Salvar senha

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

HTML:

<form method="post" action="yoururl">
      <div class="hidden">
        <input type="password"/>
      </div>
      <input type="text" name="username" placeholder="username"/>
      <input type="password" name="password" placeholder="password"/>
    </form>

CSS:

.hidden {display:none;}

1
Uma vantagem desta forma contra os que usam entradas escondidas é que desta forma uma senha nunca é armazenado em um campo de texto simples
pvgoddijn

@ whyAto8 Isso não funcionou para mim no Chrome 47.0.2526.111 ... o truque para fazê-lo funcionar era adicionar outro texto de campo na div oculta. O navegador pede para salvar a senha, MAS diz: "Tem certeza de que salvar essas credenciais?" e então mostra um nome de usuário em branco e uma senha em branco. Isso deu certo.
David Bélanger

1
A solução whyAto8, juntamente com o comentário de @David Bélanger, funcionou para mim (nenhuma das outras soluções funcionou). Também devo mencionar que adicionei os dois campos ocultos em branco ANTES dos realmente usados ​​para entrada de dados, e os campos duplicados (ocultos) tinham os mesmos nomes respectivos. Dessa forma, o Chrome (48.0.2564.103) nem perguntou se alguma senha deveria ser salva.
Vadim

Nenhuma combinação disso está funcionando no Chrome 48.0.2564.116. Mesmo combinado com o comentário de DavidBelanger, o pop-up Chrome pedindo-lhe para salvar a senha ainda guarda a senha se você clicar em ok
Chriso

Ótima resposta .. Por favor, diga-me por que você disse "Certifique-se de que esta div esteja antes da entrada da senha real" ? Coloquei essa div após a entrada da senha real e ainda funciona. Então, por que você mencionou isso?
Martin AJ

16

Você pode impedir que o navegador corresponda aos formulários aleatoriamente o nome usado para o campo de senha em cada programa. Em seguida, o navegador vê uma senha para o mesmo URL, mas não pode ter certeza de que é a mesma senha . Talvez esteja controlando outra coisa.

Atualização: observe que isso deve ser um acréscimo ao uso do preenchimento automático ou de outras táticas, não um substituto para elas, pelos motivos indicados por outras pessoas.

Observe também que isso impedirá que o navegador preencha automaticamente a senha. Isso não impedirá que ela armazene a senha em qualquer nível de segurança arbitrária que o navegador opte por usar.


5
[@Joel] (# 32409) que pode impedir o preenchimento automático do formulário, mas impediria que o navegador pedisse para salvar a senha desse suposto novo formulário?
Joseph Pecoraro

3
Não acredito que isso funcione agora. No FF 13, tenho um formulário com vários campos de senha, todos com nomes diferentes. O FF, depois de salvar uma senha para essa página, coloca a senha salva em TODOS os campos da senha. Ele não se importa com o nome dos campos (eu tenho "new_password" e "old_password", por exemplo, e a senha salva é despejada em ambos). Neste formulário em particular, não tenho um nome de usuário para salvar a senha - apenas dois campos de senha, caso isso faça alguma diferença.
19412 Jason

1
Acenos @ Jason, dando o campo de senha um novo UUID para um nome de cada vez que não fez nada para derrotar as tentativas do navegador para preenchê-lo.
FP Livremente

14

Use autenticação de dois fatores real para evitar a única dependência de senhas que podem ser armazenadas em muito mais lugares do que o cache do navegador do usuário.


2
btw é autenticação não autenticação
Jonathan.

26
Pity @ Jonathan, eu prefiro autenticação
Ian Boyd

Outra solução pode estar implementando um JavaScript, que fecha o navegador com força quando o usuário é desconectado do aplicativo. Isso liberará a memória completa do navegador e, portanto, nenhum dado poderá ser recuperado da memória do navegador.
precisa

13

A maneira mais limpa é usar autocomplete="off" atributo tag, mas o Firefox não o obedece corretamente quando você alterna os campos com Tab.

A única maneira de impedir isso é adicionar um campo falso de senha oculta, que engana o navegador para preencher a senha lá.

<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"/>

É um truque feio, porque você altera o comportamento do navegador, o que deve ser considerado uma má prática. Use-o apenas se você realmente precisar.

Nota: isso efetivamente interromperá o preenchimento automático de senhas, porque o FF "salvará" o valor de #prevent_autofill(que está vazio) e tentará preencher todas as senhas salvas lá, pois sempre usa a primeira type="password"entrada encontrada no DOM após o respectivo "nome de usuário" entrada.


Qual é o sentido de impedir que o navegador preencha a senha, mas permita que ela seja armazenada? Isso apenas engana o usuário a pensar que sua senha não é armazenada enquanto está realmente vulnerável.
CodesInChaos 31/07

Dessa forma, ele não armazenará sua senha, porque você digita na outra caixa, que é ignorada pelo FF. Em vez disso, ele armazenará uma string vazia.
venimus 31/07

@CodesInChaos IMHO você deve reconsiderar a sua downvote, porque sua preocupação não é válido
venimus

12

Eu testei que adicionar autocomplete = "off" na tag de formulário em todos os principais navegadores. De fato, a maioria das pessoas nos EUA usa o IE8 até agora.

  1. IE8, IE9, IE10, Firefox, Safari são bons trabalhos.

    O navegador não pede "salvar senha". Além disso, o nome de usuário e a senha salvos anteriormente não são preenchidos.

  2. O Chrome e o IE 11 não oferecem suporte ao recurso autocomplete = "off"
  3. FF suportando o preenchimento automático = "desativado". mas às vezes credenciais salvas existentes são preenchidas.

Atualizado em 11 de junho de 2014

Finalmente, abaixo está uma solução de navegador cruzado usando javascript e está funcionando bem em todos os navegadores.

Precisa remover a tag "form" no formulário de login. Após a validação do lado do cliente, coloque essas credenciais em formato oculto e envie-as.

Além disso, adicione dois métodos. um para a validação "validateLogin ()" e outro para ouvir o evento enter enquanto clica em enter na caixa de texto / senha / botão "checkAndSubmit ()". porque agora o formulário de login não tem uma tag de formulário, digite o evento que não está funcionando aqui.

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

Boa sorte!!!


Embora essa resposta forneça informações úteis, ela realmente não responde à pergunta de como impedir que os navegadores salvem senhas.
JW Lim

@JW Lim, eu atualizei a resposta. Por favor, olhe para ele. Obrigado!
Asik

@Sivakumar, Ok, por favor inclua o SO e a versão do Safari. para que outras pessoas cientes do mesmo. Ele estava trabalhando no meu sistema (Windows 8, Safary 5)
Asik

@Asik Safari 8.0.3 e Mac OS 10.10
Sivakumar,

7

Na verdade, não - a única coisa que você poderia fazer realisticamente é oferecer conselhos no site; talvez, antes da primeira vez em que você faça login, você possa mostrar a eles um formulário com informações indicando que não é recomendado que eles permitam que o navegador armazene a senha.

Em seguida, o usuário seguirá imediatamente o conselho, anote a senha em um post-it e cole-a no monitor.


10
Você deve se lembrar de que este é um site do governo , e essas coisas são politicamente cobradas. Se alguém lá do alto disser "não deve funcionar assim", o que é realista não faz parte da equação. O problema pode ser movido para as notas post-it, mas a política é para um departamento diferente - o problema foi alterado ;-) E estou falando sério.
21712 Jason

6

O que tenho feito é uma combinação de preenchimento automático = "desativado" e limpeza de campos de senha usando um javascript / jQuery.

Exemplo de jQuery:

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

Ao usar, setTimeout()você pode esperar o navegador preencher o campo antes de limpá-lo, caso contrário, o navegador sempre será preenchido automaticamente depois que você limpar o campo.


3

se autocomplete = "off" não estiver funcionando ... remova a tag do formulário e use uma tag div, depois passe os valores do formulário usando jquery para o servidor. Isso funcionou para mim.


3

Como o preenchimento automático = "desativado" não funciona nos campos de senha, é necessário contar com o javascript. Aqui está uma solução simples com base nas respostas encontradas aqui.

Adicione o atributo data-password-autocomplete = "off" ao seu campo de senha:

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

Inclua o seguinte 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');
        });
    });     
});

Esta solução funciona para Chrome e FF.


O Windows Firefox 57.0.2 (64 bits) ainda está sugerindo salvar a senha após a implementação.
Panu Haaramo

2

Para que as pessoas percebam - o atributo 'preenchimento automático' funciona na maioria das vezes, mas os usuários avançados podem contorná-lo usando um bookmarklet.

O fato de o navegador salvar suas senhas aumenta a proteção contra o registro de chaves, portanto, a opção mais segura é salvar senhas no navegador, mas protegê-las com uma senha mestra (pelo menos no Firefox).


2
"mas os usuários avançados podem contornar isso" - isso é aplicável à maioria dos recursos de aplicativos, na web ou não, e não deve ser um motivo para limitar o sistema. As pessoas também podem escrever suas senhas em post-its e colocá-las em seus monitores, você só pode fazer muito por segurança da perspectiva do aplicativo, e fornecer um comportamento padrão significativo (não salvá-lo localmente) é um começo.
Niels Keurentjes

2

Eu tenho uma solução alternativa, que pode ajudar.

Você pode fazer um hack de fonte personalizado. Portanto, crie uma fonte personalizada, com todos os caracteres como um ponto / círculo / estrela, por exemplo. Use isso como uma fonte personalizada para o seu site. Veja como fazer isso no inkscape: como criar sua própria fonte

Em seu formulário de logon, use:

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

Em seguida, adicione seu 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';
}

Compatível com vários navegadores. Eu tentei o IE6 +, FF, Safari e Chrome. Apenas certifique-se de que a fonte oet que você converte não seja corrompida. Espero que ajude?


1
realmente solução elegante houver uma fonte senha aqui
andrew

6
Se você usar essa solução, precisará levar em consideração que os usuários podem copiar livremente o texto digitado nesse campo de senha semelhante. As funções de cópia e corte são desativadas nos campos de senha real.

2

A maneira mais simples de resolver esse problema é colocar os campos INPUT fora da marca FORM e adicionar dois campos ocultos dentro da marca FORM. Em seguida, em um ouvinte de evento de envio antes que os dados do formulário sejam enviados aos valores de cópia do servidor da entrada visível para os invisíveis.

Aqui está um exemplo (você não pode executá-lo aqui, pois a ação do formulário não está definida como um script de login real):

<!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>


O Windows Firefox 57.0.2 (64 bits) ainda está sugerindo salvar a senha após a implementação.
Panu Haaramo

bem, este foi apenas um truque, que pode parar de funcionar a qualquer momento :)
joelho-cola

essa é a melhor opção! basta limpar o campo da senha antes de enviar: $ ('. password'). val ('')
ebelendez

2

Minha solução js (jquery) é alterar o tipo de entrada da senha para o texto no envio do formulário . A senha pode ficar visível por um segundo, então eu também ocultei a entrada antes disso. Prefiro não usar isso para formulários de login , mas é útil (junto com autocomplete = "off"), por exemplo, na parte administrativa do site.

Tente colocar isso dentro de um console (com jquery) antes de enviar o formulário.

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

Testado no Chrome 44.0.2403.157 (64 bits).


1
Isso realmente funciona. Isso impede que o navegador salve a senha. Para impedir a exibição da senha, você pode agrupar o campo de entrada em uma div oculta. E você já pode fazer isso se o DOM estiver carregado, sem precisar esperar até que você envie o formulário.
Ferry Kranenburg

Funciona no IE 11.0.9600.18161!
Lu55

Isso é verdade. Agora eu tentei isso no FF 44.0.2 e esse hack não funciona mais ... que pena. No Chrome, isso ainda funciona.
ovalek

Você pode substituir a entrada [type = submit] ou button [type = submit] por um botão regular [type = button] e fazer isso no manipulador onclick. Se nenhum [type = submit] estiver presente no formulário, também impedirá que o formulário seja enviado com a tecla Enter e o prompt de salvar senha seja exibido.
Steven Don

2

Eu testei muitas soluções. Nome do campo da senha dinâmica, vários campos da senha (invisíveis para os falsos), alterando o tipo de entrada de "texto" para "senha", preenchimento automático = "desativado", preenchimento automático = "nova senha", ... mas nada o resolveu recentemente navegador.

Para se livrar da senha, lembrei-me finalmente de tratá-la como campo de entrada e "desfocar" o texto digitado.

É menos "seguro" que um campo de senha nativa, pois a seleção do texto digitado o mostraria como texto não criptografado, mas a senha não é lembrada. Também depende da ativação do Javascript.

Você estimará o risco de usar a opção abaixo da proposta vs lembrar a senha do navegador.

Embora a lembrança de senha possa ser gerenciada (desequilibrada por site) pelo usuário, ela é adequada para um computador pessoal, não para um computador "público" ou compartilhado.

No meu caso, é para um ERP em execução em computadores compartilhados, então tentarei a minha solução abaixo.

<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">

1

Markus levantou um grande ponto. Decidi procurar o autocompleteatributo e obtive o seguinte:

A única desvantagem de usar esse atributo é que ele não é padrão (funciona nos navegadores IE e Mozilla) e causaria falha na validação XHTML. Eu acho que este é um caso em que é razoável interromper a validação no entanto. ( fonte )

Então, devo dizer que, embora não funcione 100% em geral, ele é tratado nos principais navegadores, por isso é uma ótima solução.


Estou tendo esse problema de validação de acordo com os padrões w3c. O problema é que eu quero essa funcionalidade para um site de mobile banking. Suponho que os navegadores móveis sejam rigorosos o suficiente e, às vezes, atrapalhem o formulário se algum atributo inválido estiver sendo usado. O que você recomenda neste caso?
ASGs

2
Eu acho que esse é um estilo antigo de pensar. Muitos navegadores móveis recentes são criados a partir do WebKit e suportam ou ignoram esse atributo normalmente. Não sei como outros países ou navegadores de telefones celulares antigos lidam com isso, mas lidar com atributos / elementos desconhecidos é fundamental para um bom navegador. Ele "prova o futuro" do navegador para não quebrar à medida que a web evolui. Pode ficar para trás (sem implementar novos recursos), mas não será interrompido. Espero que ajude =)
Joseph Pecoraro

1
Deve ser mais um comentário para a resposta referida do que uma resposta para a pergunta em si.
viam0Zah

1

Eu tentei acima autocomplete="off"e ainda nada de sucesso. se você estiver usando js angulares, minha recomendação é ir com o botão e o ng-clique.

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

Isso já tem uma resposta aceita e estou adicionando isso se alguém não puder resolver o problema com a resposta aceita, ele pode usar o meu mecanismo.

Obrigado pela pergunta e pelas respostas.


obviamente, isso quebra ao pressionar a tecla enterou returnpara enviar um formulário.
8eecf0d2

0

Uma maneira que eu sei é usar (por exemplo) JavaScript para copiar o valor do campo de senha antes de enviar o formulário.

O principal problema disso é que a solução está vinculada ao JavaScript.

Então, novamente, se ele pode ser vinculado ao JavaScript, você também pode fazer o hash da senha no lado do cliente antes de enviar uma solicitação ao servidor.


Hashing no lado do cliente não substitui o hash no lado do servidor. Não tenho certeza se é alguma ajuda (se for feita em adição).
Brilliand

2
Permitir hash no lado do cliente é perigoso, porque significa que um invasor não precisa quebrar a senha do hash, ele pode apenas usá-lo para efetuar login. O hash se torna equivalente à senha.
Rjmunro 11/09/12

Concordo com Brilliand que o hash no cliente é útil apenas se você também tiver um hash no servidor antes de salvar a senha no seu banco de dados. No entanto, ter um hash do lado do cliente pode ajudar uma certa quantidade de problemas com homens no meio. Dito isto, como o código estará disponível (pelo menos em sites públicos) para hackers, provavelmente não é tão útil quanto parece.
Alexis Wilke

0

O problema real é muito mais profundo do que apenas adicionar atributos ao seu HTML - isso é uma preocupação comum de segurança, é por isso que as pessoas inventaram chaves de hardware e outras coisas malucas por segurança.

Imagine que o preenchimento automático = "off" está funcionando perfeitamente em todos os navegadores. Isso ajudaria na segurança? Claro que não. Os usuários anotam suas senhas em livros didáticos, em adesivos anexados ao monitor, onde todos os visitantes do escritório podem vê-las, salvando-as em arquivos de texto na área de trabalho e assim por diante.

Geralmente, o aplicativo da Web e o desenvolvedor da Web não são responsáveis ​​de forma alguma pela segurança do usuário final. Os usuários finais podem se proteger apenas. Idealmente, eles DEVEM manter todas as senhas em suas cabeças e usar a funcionalidade de redefinição de senha (ou entrar em contato com o administrador) caso eles a esqueçam. Caso contrário, sempre haverá o risco de a senha ser vista e roubada de alguma forma.

Portanto, ou você tem uma política de segurança maluca com chaves de hardware (como alguns bancos oferecem para Internet banking, que basicamente emprega autenticação de dois fatores) ou SEM SEGURANÇA, basicamente. Bem, isso é um pouco exagerado, é claro. É importante entender do que você está tentando se proteger:

  1. Acesso não autorizado. O formulário de login mais simples é suficiente, basicamente. Às vezes, são tomadas medidas adicionais, como perguntas aleatórias de segurança, CAPTCHAs, proteção de senha, etc.
  2. Farejador de credenciais. O HTTPS é OBRIGATÓRIO se as pessoas acessarem seu aplicativo da Web a partir de pontos de acesso Wi-Fi públicos, etc. Mencione que, mesmo tendo HTTPS, seus usuários precisam alterar suas senhas regularmente.
  3. Ataque interno. Existem dois exemplos disso: começando pelo simples roubo de suas senhas do navegador ou pelas que você anotou em algum lugar da mesa (não requer nenhuma habilidade de TI) e terminando com o forjamento da sessão e interceptando o tráfego da rede local (mesmo criptografado) e acessar ainda mais o aplicativo da web, como se fosse outro usuário final.

Neste post em particular, vejo requisitos inadequados para o desenvolvedor, que ele nunca poderá resolver devido à natureza do problema - segurança do usuário final. Meu ponto subjetivo é que o desenvolvedor deve basicamente dizer NÃO e apontar para o problema dos requisitos, em vez de perder tempo com essas tarefas, honestamente. Isso não torna absolutamente o seu sistema mais seguro, mas sim os casos com adesivos nos monitores. Infelizmente, alguns chefes ouvem apenas o que querem ouvir. No entanto, se eu fosse você, tentaria explicar de onde vem o problema real e o preenchimento automático = "desativado" não o resolveria, a menos que forçasse os usuários a manter todas as suas senhas exclusivamente na cabeça! O desenvolvedor do seu lado não pode proteger completamente os usuários,


0

Enfrentando o mesmo problema da HIPAA e encontrando uma solução relativamente fácil,

  1. Crie um campo de senha oculta com o nome do campo como uma matriz.

    <input type="password" name="password[]" style="display:none" />
    
  2. Use a mesma matriz para o campo de senha real.

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

O navegador (Chrome) pode solicitar que você "salve a senha", mas, independentemente do usuário selecionar salvar, na próxima vez que efetuar o login, a senha preencherá automaticamente o campo de senha oculta, o slot zero na matriz, deixando o 1º slot em branco.

Eu tentei definir a matriz, como "senha [parte2]", mas ela ainda lembrava. Eu acho que ele joga fora se é uma matriz não indexada, porque não tem escolha a não ser deixá-lo em primeiro lugar.

Então você usa sua linguagem de programação preferida para acessar a matriz, PHP, por exemplo,

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

1
Com isso, você está ocultando um problema de segurança - o hash da senha ainda está sendo armazenado no cache do navegador.
Alexander Burakevych

1
Você poderia por favor esclarecer? A senha seria enviada como texto sem formatação usando POST. Tanto quanto li, as solicitações POST não podem ser armazenadas em cache. Você está dizendo que existe uma alternativa ao uso do POST para enviar dados? Ou você está dizendo que a senha está armazenada no navegador, porque não está armazenando a senha, mas o valor vazio no início da matriz, você testou esse método?
Mike

0

Como a maioria das autocompletesugestões, incluindo a resposta aceita, não funcionam em navegadores web de hoje (gerenciadores de senha ou seja, navegador web ignorar autocomplete), uma solução mais romance é a troca entre passworde texttipos e fazer a cor de fundo combinar com a cor do texto quando o campo é um campo de texto sem formatação, que continua a ocultar a senha enquanto é um campo de senha real quando o usuário (ou um programa como o KeePass) está inserindo uma senha. Os navegadores não pedem para salvar senhas armazenadas em campos de texto sem formatação.

A vantagem dessa abordagem é que ela permite aprimoramento progressivo e, portanto, não requer Javascript para que um campo funcione como um campo de senha normal (você também pode começar com um campo de texto sem formatação e aplicar a mesma abordagem, mas isso não é realmente HIPAA Compatível com PHI / PII). Essa abordagem também não depende de formulários / campos ocultos que podem não ser necessariamente enviados para o servidor (porque estão ocultos) e alguns desses truques também não funcionam em vários navegadores modernos.

plugin jQuery:

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

Código fonte relevante do link acima:

(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

Clique em "Adicionar entrada" no menu e role para a parte inferior da página para "Módulo: Parar o gerenciador de senhas".

Isenção de responsabilidade: Embora essa abordagem funcione para pessoas com visão, pode haver problemas com o software do leitor de tela. Por exemplo, um leitor de tela pode ler a senha do usuário em voz alta porque vê um campo de texto sem formatação. Também pode haver outras consequências imprevistas do uso do plug-in acima. A alteração da funcionalidade interna do navegador da Web deve ser feita com moderação, testando uma ampla variedade de condições e casos extremos.


-1

Existe uma maneira de um site dizer ao navegador para não se lembrar de senhas?

O site informa ao navegador que é uma senha usando <input type="password">. Portanto, se você deve fazer isso da perspectiva de um site, precisará alterar isso. (Obviamente, eu não recomendo isso).

A melhor solução seria fazer com que o usuário configure seu navegador para que não se lembre de senhas.


3
Como é óbvio que você não recomenda alterar um campo de tipo de entrada? Uma elaboração de questões de segurança seria útil.
307 Karl

1
@karl: como ter que digitar a senha ao ar livre permite "navegar no ombro", o processo de digitar uma senha olhando a tela enquanto ela está sendo digitada.
David Schmitt

Não apenas a navegação no ombro humano, mas spywares ou vírus podem assistir à tela e ver o que foi digitado nos campos de texto sem formatação.
Karl

6
@karl: Se você possui spyware / vírus no seu computador, nenhuma proteção com asterisco o salvará. Não é mais difícil para um aplicativo instalado interceptar o que está sendo digitado em um campo 'senha' do que fazer o mesmo em um campo de texto sem formatação.
Markus Olsson

3
Além disso, se o navegador vir uma entrada de texto comum em vez de uma senha, é provável que a senha seja oculta no formulário banco de dados de preenchimento automático em vez do banco de dados de senhas ... e sugira-a ou até a preencha automaticamente em algum site não relacionado! Então você está pior ainda do que quando começou.
Zwol

-1

Se você não quiser confiar no sinalizador de preenchimento automático, verifique se o usuário digita na caixa usando o evento onchange. O código abaixo é um formulário HTML simples. O elemento oculto do formulário password_edit começa definido como 0. Quando o valor da senha é alterado, o JavaScript na parte superior (função pw_edit) altera o valor para 1. Quando o botão é pressionado, ele verifica o código do valueenter aqui antes de enviar o formulário . Dessa forma, mesmo que o navegador o ignore e preencha automaticamente o campo, o usuário não poderá passar pela página de login sem digitar o campo de senha. Além disso, certifique-se de colocar em branco o campo da senha quando o foco estiver definido. Caso contrário, você pode adicionar um personagem no final, depois voltar e removê-lo para enganar o sistema. Eu recomendo adicionar o autocomplete = "off" à senha, mas este exemplo mostra como o código de backup funciona.

<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>

-1

autocomplete = "off" não funciona para desabilitar o gerenciador de senhas no Firefox 31 e provavelmente não em algumas versões anteriores.

Confira a discussão no mozilla sobre este problema: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

Queríamos usar um segundo campo de senha para inserir uma senha descartável gerada por um token. Agora estamos usando uma entrada de texto em vez de uma senha. :-(


-1

Foi-me dada uma tarefa semelhante para desativar o preenchimento automático de nomes e senhas de login pelo navegador, depois de muitas tentativas e erros, achei a solução abaixo a ideal. Basta adicionar os controles abaixo antes dos controles originais.

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

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

Isso está funcionando bem para IE11 e Chrome 44.0.2403.107


-2

autocomplete = "off" funciona para a maioria dos navegadores modernos, mas outro método que usei que funcionou com sucesso com o Epiphany (um navegador do GNOME para WebKit) é armazenar um prefixo gerado aleatoriamente no estado da sessão (ou em um campo oculto). uma variável adequada no estado da sessão) e use-a para alterar o nome dos campos. O Epiphany ainda deseja salvar a senha, mas quando voltar ao formulário, não preencherá os campos.


Isso é ainda pior do que armazená-los da maneira usual, já que agora o usuário não vê que a senha foi salva e não impede que um invasor extraia a senha da loja.
#

-2

Não tive problemas ao usar este método:

Use autocomplete = "off", adicione um campo de senha oculta e depois outro não oculto. O navegador tenta concluir automaticamente o oculto se não respeitar o preenchimento automático = "off"


-2

Outra solução é fazer o POST usando um formulário oculto, onde todas as entradas são do tipo oculto. O formulário visível utilizará a entrada do tipo "senha". O último formulário nunca será enviado e, portanto, o navegador não poderá interceptar toda a operação do login.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.