Wyłącz funkcję „Zapisz hasło” w przeglądarce

423

Jedną z radości związanych z pracą dla rządowej agencji opieki zdrowotnej jest radzenie sobie z całą paranoją związaną z kontaktem z PHI (chronioną informacją zdrowotną). Nie zrozum mnie źle, jestem za tym, aby zrobić wszystko, co możliwe, aby chronić dane osobowe ludzi (zdrowie, finanse, nawyki związane z surfowaniem itp.), Ale czasami ludzie są trochę zbyt podenerwowani.

Przykład: jeden z naszych klientów stanowych niedawno dowiedział się, że przeglądarka zapewnia przydatną funkcję zapisywania hasła. Wszyscy wiemy, że istnieje już od jakiegoś czasu i jest całkowicie opcjonalny i od użytkownika końcowego zależy, czy będzie to mądra decyzja, czy nie. Jednak w tej chwili panuje zamieszanie i jesteśmy zmuszeni znaleźć sposób, aby wyłączyć tę funkcję dla naszej witryny.

Pytanie : Czy istnieje sposób, aby witryna powiedziała przeglądarce, aby nie oferowała zapamiętywania haseł? Zajmuję się tworzeniem stron internetowych od dłuższego czasu, ale nie wiem, czy wcześniej się z tym spotkałem.

Każda pomoc jest mile widziana.

mattsmith321
źródło
6
Powinieneś dostarczyć skrypt „fatmonkey”, aby ludzie mogli go ponownie włączyć. Nie sądzę, że użytkownicy lubią być zmuszani do wpisywania hasła za każdym razem ...
ThiefMaster
14
Pytanie zasługuje na uznanie za użyteczne i jasne. Z drugiej strony nie chcę, aby ludzie znaleźli rozwiązanie tego „problemu”.
Ian Boyd
11
Nie zawsze jest to „problem”. Przybyłem tutaj, ponieważ Firefox wyświetla monit o zapisanie hasła do formularza zawierającego hasło WiFi / SSID, a nie do nazwy użytkownika / hasła do logowania. To bardzo denerwujące i chcę to zatrzymać.
srd
1
Jeśli informacja jest tak ważna, powinna być chroniona nie tylko hasłem.
Sam Watkins,
Jednym ze sposobów, w jaki wydaje się działać, jest nie używanie <form>. Jeśli używasz javascript do wysyłania danych (XHR), nie potrzebujesz go. Chciałem wyłączyć w systemie, który korzysta z uwierzytelniania „hasłem jednorazowym” (bez powodu, aby je przechowywać). W przypadku uwierzytelnienia użytkownika / hasła nie polecam wyłączać tej funkcji.
lepe

Odpowiedzi:

322

Nie jestem pewien, czy to zadziała we wszystkich przeglądarkach, ale powinieneś spróbować ustawić autocomplete = "off" w formularzu.

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

Najłatwiejszym i najprostszym sposobem na wyłączenie monitów o przechowywanie formularzy i haseł oraz zapobieganie buforowaniu danych formularzy w historii sesji jest użycie atrybutu elementu autouzupełniania o wartości „off”.

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

Niektóre drobne badania pokazują, że działa to w IE, ale nie pozostawiam żadnych gwarancji;)

@Joseph : Jeśli jest to ścisły wymóg, aby przejść walidację XHTML z rzeczywistym znacznikiem (nie wiem, dlaczego tak się stanie), możesz teoretycznie dodać ten atrybut za pomocą javascript, ale potem użytkownicy z wyłączoną js (prawdopodobnie pomijalna ilość twojej bazy użytkowników lub zero, jeśli witryna wymaga js) nadal będzie mieć zapisane hasła.

Przykład z jQuery:

$('#loginForm').attr('autocomplete', 'off');
Markus Olsson
źródło
48
Szybki komentarz, ponieważ to się zmienia, HTML5 dodaje atrybut specyfikacji do autouzupełniania, więc jest on teraz aktualny.
Tyler Egeto,
11
Wystarczy FYI, Microsoft zdecydował, że Internet Explorer 11 nie będzie już zaszczyt autocomplete="off"dla input type="password"pól. msdn.microsoft.com/en-us/library/ie/ms533486%28v=vs.85%29.aspx
JW Lim
6
Podobnie jak @JWLim wspomniał, że IE 11 odrzuca obsługę wyłączania funkcji zapisywania hasła, podobnie Firefox. bugzilla.mozilla.org/show_bug.cgi?id=956906
Gregory Cosmo Haun
3
Firefox (niestety) podążył za przykładem Microsoftu i „usunął” także funkcję autouzupełniania. Aby uzyskać szczegółowe informacje, patrz komentarz 100 w następującej dyskusji: bugzilla.mozilla.org/show_bug.cgi?id=956906
Odbijanie bitów
8
Teraz nie działa dla przeglądarki Firefox 38+ mozilla.org/en-US/firefox/38.0/releasenotes
Illuminator
44

Oprócz

autocomplete="off"

Posługiwać się

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

dla wejść, które nie chcą, żeby zapamiętać dane formularza ( username, passwordetc.), jak pokazano poniżej:

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

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

Testowane na najnowszych wersjach przeglądarek głównych tj Google Chrome, Mozilla Firefox, Microsoft Edge, itd. I działa jak czar. Mam nadzieję że to pomoże.

Murat Yıldız
źródło
2
@Murat Yıldız: Muszę zaimplementować to samo i śledziłem twój kod. Działa to dla mnie we wszystkich przeglądarkach. Dziękuję Ci !
Sree,
1
@Sree Cieszę się, że było to dla ciebie pomocne :)
Murat Yıldız
3
Właśnie przetestowałem Mozillę Firefox 52.0 , Google Chrome 57.0 , Microsoft Edge 38.1 i działa jak urok! ..
Murat Yıldız
1
W Safari Mobile może wystąpić błąd, ponieważ ta odpowiedź naprawia go stackoverflow.com/questions/2530/…
Ferie
1
Windows Firefox 57.0.2 (64-bit) nadal sugeruje zapisanie hasła po tym, jak to zaimplementowałem.
Panu Haaramo,
37

Przez jakiś czas zmagałem się z tym problemem, z unikalnym zwrotem problemu. Użytkownicy uprzywilejowani nie mogli mieć dla nich zapisanych haseł, ale zwykli użytkownicy tego potrzebowali. Oznaczało to, że uprzywilejowani użytkownicy musieli zalogować się dwa razy, po raz drugi nie wymuszając zapisanych haseł.

Przy tym wymaganiu standardowa autocomplete="off"metoda nie działa we wszystkich przeglądarkach, ponieważ hasło mogło zostać zapisane od pierwszego logowania. Kolega znalazł rozwiązanie, aby zastąpić pole hasła, gdy było ono skupione nowym polem hasła, a następnie skupić się na polu nowego hasła (a następnie podłączyć tę samą procedurę obsługi zdarzeń). To działało (poza tym powodowało nieskończoną pętlę w IE6). Może było na to jakieś wyjście, ale to spowodowało migrenę.

Wreszcie próbowałem po prostu podać nazwę użytkownika i hasło poza formularzem. Ku mojemu zaskoczeniu, zadziałało! Działa na IE6 oraz bieżących wersjach Firefox i Chrome na Linux. Nie testowałem go dalej, ale podejrzewam, że działa w większości, jeśli nie we wszystkich przeglądarkach (ale nie zaskoczyłoby mnie, gdyby istniała przeglądarka, która nie dbałaby o to, że nie ma żadnej formy).

Oto przykładowy kod wraz z jQuery, aby go uruchomić:

<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>
Mike Stone
źródło
1
To wygląda na dobre rozwiązanie. Ma to sens, ponieważ formularz, który wysyłasz, sam nie zawiera hasła. Przypuszczam, że mogę mieć dwie formy, pierwsza tylko po to, aby nazwa użytkownika i hasło były widoczne we wszystkich przeglądarkach.
Alexis Wilke,
3
podoba mi się twoje rozwiązanie i zaimplementowałem podobny na mojej stronie, to śmieszne, że w dzisiejszych czasach przeglądarki nie oferują prostego sposobu na rozwiązanie tego.
AgelessEssence
Nie jestem pewien, czy to dlatego, że utknąłem przy użyciu jquery 1.6, ale powyższa jquery działała tylko po zawinięciu wewnątrz $ (dokumentu) .ready (function () {});
rgbflawed
Jedyną poprawną cechą jest to, że niektóre przeglądarki nie akceptują autocomplete = "off"!
Abadis
1
Właśnie wypróbowałem tę metodę na Chrome, Opera i Internet Explorerze i wydaje się, że działa, ale nie działa niepoprawnie z Firefoksem
chenks
29

Cóż, jest to bardzo stary post, ale nadal podam moje rozwiązanie, które mój zespół starał się osiągnąć od dawna. Właśnie dodaliśmy nowe pole wejściowe = "hasło" w formularzu i zawinęliśmy je w div i ukryliśmy div. Upewnij się, że div znajduje się przed rzeczywistym wprowadzeniem hasła. To działało dla nas i nie dawało żadnej opcji Zapisz hasło

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;}
dlaczegoAto8
źródło
1
Jedną z zalet tego sposobu vs tych, którzy używają ukrytych wejść w ten sposób jest to, że hasło nie jest przechowywane w polu zwykłego tekstu
pvgoddijn
@ dlaczegoAto8 To nie działało dla mnie w Chrome 47.0.2526.111 ... sztuczka, aby to zadziałało, to dodać kolejny tekst pola w ukrytym div. Przeglądarka prosi o zapisanie hasła, ALE mówi: „Czy na pewno chcesz zapisać te pliki?” a następnie pokazuje pustą nazwę użytkownika i puste hasło. To zadziałało.
David Bélanger
1
dlaczego rozwiązanieAto8 wraz z komentarzem @Davida Bélangera działało dla mnie (żadne inne rozwiązanie nie zadziałało). Powinienem również wspomnieć, że dodałem dwa puste ukryte pola PRZED tymi, które faktycznie były używane do wprowadzania danych, a zduplikowane (ukryte) pola miały te same nazwy. W ten sposób Chrome (48.0.2564.103) nawet nie zapytał, czy jakieś hasło powinno zostać zapisane.
Vadim,
Żadna kombinacja tego nie działa w Chrome 48.0.2564.116. Nawet w połączeniu z komentarzem DavidBelanger wyskakujące okienko Chrome z prośbą o zapisanie hasła nadal buforuje hasło, jeśli klikniesz OK
ChrisO
Świetna odpowiedź. Czy mógłbyś mi powiedzieć, dlaczego powiedziałeś „Upewnij się, że div jest przed wprowadzeniem hasła” ? I umieścić ten div po tej rzeczywistej wejścia hasło i nadal działa .. Więc dlaczego wspomnieć, że?
Martin AJ,
16

Możesz uniemożliwić przeglądarce dopasowanie formularzy przez losowe użycie nazwy pola hasła w każdym programie. Następnie przeglądarka widzi hasło do tego samego adresu URL, ale nie może być pewna, że ​​to to samo hasło . Może kontroluje coś innego.

Aktualizacja: należy pamiętać, że powinno to być uzupełnienie korzystania z autouzupełniania lub innych taktyk, a nie zastępowania ich, z powodów wskazanych przez innych.

Pamiętaj też, że uniemożliwi to automatyczne uzupełnianie hasła przez przeglądarkę. Nie zapobiegnie to przechowywaniu hasła na dowolnym poziomie bezpieczeństwa, który wybierze przeglądarka.

Joel Coehoorn
źródło
5
[@Joel] (# 32409), który może uniemożliwić automatyczne wypełnianie formularza, ale czy uniemożliwiłby przeglądarce zapisanie hasła do tego domniemanego nowego formularza?
Joseph Pecoraro
3
Nie wierzę, że to zadziała teraz. W FF 13 mam formularz z kilkoma polami haseł, wszystkie o różnych nazwach. FF, po zapisaniu hasła dla tej strony, umieszcza zapisane hasło we WSZYSTKICH polach hasła. Nie ma znaczenia, jakie są nazwy pól (mam na przykład „nowe_hasło” i „stare_hasło”, a zapisane hasło zostaje zrzucone do obu z nich). W tej konkretnej formie nie mam nazwy użytkownika, na której można zapisać hasło - tylko dwa pola hasła, na wypadek, gdyby to miało znaczenie.
Jason
1
Nods @Jason, nadając polu hasła nowy identyfikator UUID dla nazwy za każdym razem, nie zrobił nic, aby pokonać próby wypełnienia go przez przeglądarkę.
FP Freely
14

Użyj prawdziwego uwierzytelniania dwuskładnikowego, aby uniknąć jedynej zależności od haseł, które mogą być przechowywane w znacznie większej liczbie miejsc niż pamięć podręczna przeglądarki użytkownika.

David Schmitt
źródło
2
przy okazji to uwierzytelnianie, a nie uwierzytelnianie
Jonathan.
26
@Jonathan Pity, wolę uwierzytelnianie
Ian Boyd
Innym rozwiązaniem może być implementacja JavaScript, który wymusza zamknięcie przeglądarki po wylogowaniu użytkownika z aplikacji. Spowoduje to opróżnienie całej pamięci przeglądarki, a zatem nie można pobrać danych z pamięci przeglądarki.
Ajay Takur
13

Najczystszym sposobem jest użycie autocomplete="off"atrybutu tag, ale Firefox nie przestrzega go poprawnie po zmianie pól za pomocą Tab.

Jedynym sposobem, aby to zatrzymać, jest dodanie fałszywego pola ukrytego hasła, które nakłania przeglądarkę do wypełnienia hasła.

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

Jest to brzydki hack, ponieważ zmieniasz zachowanie przeglądarki, co należy uznać za złą praktykę. Używaj go tylko wtedy, gdy naprawdę go potrzebujesz.

Uwaga: to skutecznie zatrzyma autouzupełnianie hasła, ponieważ FF „zapisze” wartość #prevent_autofill(która jest pusta) i spróbuje wypełnić tam zapisane hasła, ponieważ zawsze używa pierwszego type="password"wejścia znalezionego w DOM po odpowiedniej „nazwie użytkownika” Wejście.

venimus
źródło
Po co zapobiegać wpisywaniu hasła w przeglądarce, ale zezwalając na jego przechowywanie? To tylko powoduje, że użytkownik myśli, że jego hasło nie jest przechowywane, podczas gdy jest on podatny na ataki.
CodesInChaos
W ten sposób nie będzie przechowywać Twojego hasła, ponieważ wpisujesz w drugim polu, które jest ignorowane przez FF. Zamiast tego zapisze pusty ciąg.
venimus
@CodesInChaos IMHO powinieneś ponownie rozważyć swoją opinię, ponieważ twoje obawy są nieważne
venimus
12

Przetestowałem to dodawanie autocomplete = "off" w znaczniku formularza we wszystkich głównych przeglądarkach. W rzeczywistości większość ludzi w USA używa IE8 do tej pory.

  1. IE8, IE9, IE10, Firefox, Safari działają dobrze.

    Przeglądarka nie pyta „zapisz hasło”. Ponadto poprzednio zapisana nazwa użytkownika i hasło nie są wypełnione.

  2. Chrome i IE 11 nie obsługują funkcji autouzupełniania = „wyłączone”
  3. FF obsługujący autouzupełnianie = „wyłączony”. ale czasami istniejące zapisane poświadczenia są zapełniane.

Zaktualizowano 11 czerwca 2014 r

Wreszcie, poniżej znajduje się rozwiązanie dla wielu przeglądarek wykorzystujące javascript i działa dobrze we wszystkich przeglądarkach.

Musisz usunąć tag „form” w formularzu logowania. Po sprawdzeniu poprawności po stronie klienta umieść te poświadczenia w ukrytej formie i prześlij je.

Dodaj także dwie metody. jeden do sprawdzania poprawności „validateLogin ()”, a drugi do nasłuchiwania wprowadź zdarzenie, a następnie kliknij enter w polu tekstowym / haśle / przycisku „checkAndSubmit ()”. ponieważ teraz formularz logowania nie ma znacznika formularza, więc wprowadź zdarzenie, które tutaj nie działa.

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

Powodzenia!!!

Asik
źródło
Chociaż ta odpowiedź dostarcza użytecznych informacji, tak naprawdę nie odpowiada na pytanie, jak powstrzymać przeglądarki przed zapisywaniem haseł.
JW Lim
@JW Lim, zaktualizowałem odpowiedź. Proszę spojrzeć na to. Dzięki!
Asik
@Sivakumar, Ok, proszę dołączyć system operacyjny i wersję Safari. aby inni ludzie wiedzieli o tym samym. działało w moim systemie (Windows 8, Safary 5)
Asik
@Asik Safari 8.0.3 i Mac OS 10.10
Sivakumar
7

Niezupełnie - jedyne, co możesz realistycznie zrobić, to doradztwo na stronie; być może przed pierwszym zalogowaniem możesz wyświetlić formularz zawierający informacje wskazujące, że nie jest zalecane, aby zezwalały przeglądarce na przechowywanie hasła.

Następnie użytkownik natychmiast zastosuje się do porady, zapisze hasło na kartce samoprzylepnej i przyklei taśmą do swojego monitora.

Jason Bunting
źródło
10
Musisz pamiętać, że jest to strona rządowa , a takie rzeczy są obciążone politycznie. Jeśli ktoś z góry powie: „nie może tak działać”, to, co jest realistyczne, nie jest częścią równania. Problem może zostać przeniesiony do notatek Post-It, ale zasady na nich obowiązują inny dział - problem został przeniesiony ;-) A tak naprawdę mówię poważnie.
Jason
6

To, co robiłem, to połączenie autocomplete = "off" i czyszczenie pól haseł za pomocą javascript / jQuery.

Przykład jQuery:

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

Korzystając z tej opcji setTimeout(), możesz poczekać, aż przeglądarka wypełni pole, zanim je wyczyścisz, w przeciwnym razie przeglądarka zawsze będzie się automatycznie uzupełniać po wyczyszczeniu pola.

Howard Young
źródło
3

jeśli autocomplete = „off” nie działa ... usuń znacznik formularza i użyj zamiast niego znacznika div, a następnie przekaż wartości formularza za pomocą jquery na serwer. To zadziałało dla mnie.

Nikhil Dinesh
źródło
3

Ponieważ autocomplete = "off" nie działa w przypadku pól haseł, należy polegać na javascript. Oto proste rozwiązanie oparte na znalezionych tutaj odpowiedziach.

Dodaj atrybut data-password-autocomplete = "off" do pola hasła:

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

Uwzględnij następujące 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');
        });
    });     
});

To rozwiązanie działa zarówno w Chrome, jak i FF.

Mernernes
źródło
Windows Firefox 57.0.2 (64-bit) nadal sugeruje zapisanie hasła po tym, jak to zaimplementowałem.
Panu Haaramo,
2

Ludzie sobie sprawę - atrybut „autouzupełniania” działa przez większość czasu, ale użytkownicy zaawansowani mogą obejść go za pomocą bookmarkletu.

Posiadanie przez przeglądarkę haseł faktycznie zwiększa ochronę przed keyloggingiem, więc być może najbezpieczniejszą opcją jest zapisanie haseł w przeglądarce, ale ochrona ich hasłem głównym (przynajmniej w przeglądarce Firefox).

Thrawn
źródło
2
„ale zaawansowani użytkownicy mogą sobie z tym poradzić” - dotyczy to większości funkcji aplikacji, internetowych lub nie, i nie powinno być powodem do ograniczenia systemu. Ludzie mogą również zapisywać swoje hasła na post-it i umieścić je na monitorze, możesz zrobić tylko tyle dla bezpieczeństwa z perspektywy aplikacji, a zapewnienie znaczącego domyślnego zachowania (nie zapisywanie go lokalnie) to początek.
Niels Keurentjes
2

Mam pracę, która może pomóc.

Możesz zrobić niestandardowy włamanie czcionek. Stwórz niestandardową czcionkę ze wszystkimi znakami, na przykład kropką / okręgiem / gwiazdką. Użyj tego jako niestandardowej czcionki dla swojej witryny. Sprawdź, jak to zrobić w Inkscape: jak stworzyć własną czcionkę

Następnie w formularzu logowania użyj:

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

Następnie dodaj swój 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';
}

Dość kompatybilny z wieloma przeglądarkami. Wypróbowałem IE6 +, FF, Safari i Chrome. Upewnij się tylko, że konwertowana czcionka oet nie zostanie uszkodzona. Mam nadzieję, że to pomoże?

Dai Bok
źródło
1
naprawdę miłe rozwiązanie nie jest czcionka hasło tutaj
Andrew
6
Jeśli korzystasz z takiego rozwiązania, musisz wziąć pod uwagę, że użytkownicy mogą swobodnie kopiować tekst wprowadzony w tym przypominającym hasło polu. Funkcje kopiowania i wycinania są wyłączone w polach rzeczywistych haseł.
2

Najprostszym sposobem rozwiązania tego problemu jest umieszczenie pól INPUT poza znacznikiem FORM i dodanie dwóch ukrytych pól wewnątrz znacznika FORM. Następnie w detektorze zdarzeń wysyłania, zanim dane formularza zostaną przesłane do serwera, skopiuj wartości z widocznych danych wejściowych do niewidzialnych.

Oto przykład (nie można go tutaj uruchomić, ponieważ akcja formularza nie jest ustawiona na prawdziwy skrypt logowania):

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

kolano
źródło
Windows Firefox 57.0.2 (64-bit) nadal sugeruje zapisanie hasła po tym, jak to zaimplementowałem.
Panu Haaramo,
cóż, to był tylko hack, który może przestać działać w dowolnym momencie :)
knee-cola
to najlepsza opcja! po prostu wyczyść pole hasła przed przesłaniem: $ ('. hasło'). val ('')
ebelendez
2

Moim obejściem js (jquery) jest zmiana typu wprowadzania hasła na tekst po przesłaniu formularza . Hasło może stać się widoczne przez sekundę, więc również przed tym chowam dane wejściowe. Wolałbym tego nie używać do formularzy logowania , ale jest to przydatne (wraz z autocomplete = „off”) na przykład w części administracyjnej strony.

Spróbuj umieścić to w konsoli (z jquery), zanim prześlesz formularz.

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

Testowane na Chrome 44.0.2403.157 (64-bit).

ovalek
źródło
1
To faktycznie działa. Zapobiega to zapisaniu hasła przez przeglądarkę. Aby zapobiec wyświetlaniu hasła, możesz owinąć pole wejściowe ukrytym div. Możesz to zrobić już po załadowaniu DOM, nie musisz czekać, aż prześlesz formularz.
Prom Kranenburg,
Działa na IE 11.0.9600.18161!
Lu55
To prawda. Teraz próbowałem tego w FF 44.0.2 i ten hack już nie działa ... szkoda. W Chrome to nadal działa.
owalek
Możesz zastąpić dane wejściowe [typ = przesłanie] lub przycisk [typ = przesłanie] zwykłym przyciskiem [typ = przycisk] i zrobić to w module obsługi onclick. Jeśli w formularzu nie ma [typ = prześlij], uniemożliwi to przesłanie formularza za pomocą klawisza Enter i monitu o zapisanie hasła.
Steven Don
2

Testowałem wiele rozwiązań. Dynamiczna nazwa pola hasła, wiele pól hasła (niewidoczne dla fałszywych), zmiana typu wprowadzania z „tekst” na „hasło”, autouzupełnianie = „wyłączone”, autouzupełnianie = „nowe hasło”, ... ale nic nie rozwiązało przeglądarka.

Aby pozbyć się hasła pamiętaj, w końcu potraktowałem hasło jako pole wejściowe i „rozmazałem” wpisany tekst.

Jest mniej „bezpieczny” niż pole hasła natywnego, ponieważ wybranie wpisanego tekstu spowoduje wyświetlenie go jako zwykłego tekstu, ale hasło nie zostanie zapamiętane. Zależy to również od aktywacji Javascript.

Będziesz oszacować ryzyko użycia poniższej propozycji vs opcji zapamiętywania hasła z nawigatora.

Zapamiętywanie hasła może być zarządzane przez użytkownika (wyłączone dla każdej witryny), ale w przypadku komputera osobistego jest ono w porządku, a nie dla komputera „publicznego” lub współdzielonego.

W moim przypadku chodzi o ERP działający na współużytkowanych komputerach, dlatego wypróbuję poniższe rozwiązanie.

<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">
Cedric Simon
źródło
1

Markus podniósł świetny punkt. Postanowiłem poszukać autocompleteatrybutu i uzyskałem następujące informacje:

Jedynym minusem korzystania z tego atrybutu jest to, że nie jest on standardowy (działa w przeglądarkach IE i Mozilla) i spowodowałby niepowodzenie sprawdzania poprawności XHTML. Myślę, że jest to przypadek, w którym uzasadnione jest przerwanie sprawdzania poprawności. ( źródło )

Muszę więc powiedzieć, że chociaż nie działa w 100% na wszystkich platformach, jest obsługiwany w głównych przeglądarkach, więc jest to świetne rozwiązanie.

Joseph Pecoraro
źródło
Mam problem z sprawdzaniem poprawności zgodnie ze standardami W3C. Chodzi o to, że chcę tę funkcjonalność dla witryny bankowości mobilnej. Zakładam, że przeglądarki mobilne są wystarczająco rygorystyczne i mogą czasami zepsuć formularz, jeśli użyty zostanie jakiś nieprawidłowy atrybut. Co polecasz w tym przypadku?
asgs
2
Myślę, że to stary styl myślenia. Wiele najnowszych przeglądarek mobilnych zbudowanych jest z WebKit i obsługuje albo z wdziękiem ignoruje ten atrybut. Nie wiem, jak inne kraje lub przeglądarki w starszych telefonach komórkowych radzą sobie z tym, ale wdzięczna obsługa nieznanych atrybutów / elementów ma fundamentalne znaczenie dla dobrej przeglądarki. „Potwierdza to w przyszłości”, że przeglądarka nie pęka w miarę ewolucji sieci. Może pozostać w tyle (nie wdrażając nowych funkcji), ale się nie zepsuje. Mam nadzieję, że to pomoże =)
Joseph Pecoraro,
1
Powinien być raczej komentarzem do podanej odpowiedzi niż odpowiedzią na samo pytanie.
viam0Zah
1

Próbowałem powyżej, autocomplete="off"a jednak wszystko udane. jeśli używasz kątowego js, ​​zalecam użycie przycisku i kliknięcia ng.

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

To już ma zaakceptowaną odpowiedź. Dodam to, jeśli ktoś nie może rozwiązać problemu z zaakceptowaną odpowiedzią, może przejść z moim mechanizmem.

Dzięki za pytanie i odpowiedzi.

Lasitha Benaragama
źródło
to oczywiście łamie naciskanie klawisza enterlub return, aby przesłać formularz.
8eecf0d2
0

Jednym ze znanych mi sposobów jest użycie (na przykład) JavaScript do skopiowania wartości z pola hasła przed przesłaniem formularza.

Głównym problemem jest to, że rozwiązanie jest powiązane z JavaScript.

Z drugiej strony, jeśli można go powiązać z JavaScriptem, równie dobrze możesz przesłać hasło po stronie klienta przed wysłaniem żądania do serwera.

Huppie
źródło
Hashowanie po stronie klienta nie zastępuje haszowania po stronie serwera. Nie jestem pewien, czy jest to jakakolwiek pomoc (jeśli zostanie to zrobione dodatkowo).
Brilli i
2
Zezwolenie na haszowanie po stronie klienta jest niebezpieczne, ponieważ oznacza, że ​​osoba atakująca nie musi łamać hasła z skrótu, może po prostu użyć skrótu do zalogowania się. Skrót staje się równoważny z hasłem.
rjmunro,
Zgadzam się z Brilliand, że skrót na kliencie jest użyteczny tylko wtedy, gdy masz również skrót na serwerze przed zapisaniem hasła w bazie danych. Jednak posiadanie skrótu po stronie klienta może pomóc w pewnej ilości problemów z mężczyznami w środku. Biorąc to pod uwagę, ponieważ kod będzie dostępny (przynajmniej na stronach publicznych) dla hakerów, prawdopodobnie nie jest tak użyteczny, jak mogłoby się wydawać.
Alexis Wilke,
0

Prawdziwy problem jest znacznie głębszy niż tylko dodawanie atrybutów do kodu HTML - jest to powszechna obawa dotycząca bezpieczeństwa, dlatego ludzie wymyślali klucze sprzętowe i inne szalone rzeczy dla bezpieczeństwa.

Wyobraź sobie, że autocomplete = „off” doskonale działa we wszystkich przeglądarkach. Czy pomogłoby to w bezpieczeństwie? Oczywiście że nie. Użytkownicy zapisują swoje hasła w podręcznikach, na naklejkach przymocowanych do monitora, na których każdy odwiedzający je może je zobaczyć, zapisują je w plikach tekstowych na pulpicie i tak dalej.

Zasadniczo aplikacja internetowa i programista nie ponoszą żadnej odpowiedzialności za bezpieczeństwo użytkowników końcowych. Użytkownicy końcowi mogą się tylko chronić. Idealnie MUSZĄ trzymać wszystkie hasła w głowie i korzystać z funkcji resetowania hasła (lub skontaktować się z administratorem) na wypadek, gdyby zapomnieli. W przeciwnym razie zawsze będzie ryzyko, że hasło będzie w jakiś sposób widoczne i skradzione.

Więc albo masz jakąś szaloną politykę bezpieczeństwa z kluczami sprzętowymi (np. Niektóre banki oferują bankowość internetową, która zasadniczo wykorzystuje uwierzytelnianie dwuskładnikowe) lub BEZ BEZPIECZEŃSTWA w zasadzie. Oczywiście jest to nieco przesadzone. Ważne jest, aby zrozumieć, przed czym próbujesz chronić:

  1. Nieautoryzowany dostęp. Najprostszy formularz logowania wystarczy. Czasami podejmowane są dodatkowe środki, takie jak losowe pytania bezpieczeństwa, CAPTCHA, utrwalanie haseł itp.
  2. Wąchanie poświadczeń. HTTPS jest konieczny, jeśli ludzie uzyskują dostęp do Twojej aplikacji internetowej z publicznych hotspotów Wi-Fi itp. Wspomnij, że nawet mając HTTPS, użytkownicy muszą regularnie zmieniać hasła.
  3. Atak z wewnątrz. Istnieją dwa przykłady takich przypadków, począwszy od prostego kradzieży haseł z przeglądarki lub tych, które zapisałeś gdzieś na biurku (nie wymaga żadnych umiejętności informatycznych), a skończywszy na fałszowaniu sesji i przechwytywaniu lokalnego ruchu sieciowego (nawet szyfrowanego) i dalszy dostęp do aplikacji internetowej, tak jak to był inny użytkownik końcowy.

W tym konkretnym poście widzę niewystarczające wymagania wobec programisty, których nigdy nie będzie w stanie rozwiązać ze względu na charakter problemu - bezpieczeństwo użytkownika końcowego. Moim subiektywnym punktem jest to, że deweloper powinien zasadniczo powiedzieć NIE i zwracać uwagę na problem z wymaganiami, zamiast marnować czas na takie zadania. Nie oznacza to absolutnie większego bezpieczeństwa systemu, a raczej prowadzi do skrzynek z naklejkami na monitorach. Niestety, niektórzy szefowie słyszą tylko to, co chcą usłyszeć. Jednak gdybym był tobą, spróbowałbym wyjaśnić, skąd bierze się faktyczny problem, a to autouzupełnianie = „wyłączone” nie rozwiązałoby go, chyba że zmusi użytkowników do zachowania wszystkich haseł wyłącznie w ich głowie! Jego twórca nie może całkowicie chronić użytkowników,

ruruskyi
źródło
0

W obliczu tego samego problemu HIPAA i znalezienia stosunkowo łatwego rozwiązania,

  1. Utwórz ukryte pole hasła z nazwą pola jako tablicą.

    <input type="password" name="password[]" style="display:none" />
    
  2. Użyj tej samej tablicy dla rzeczywistego pola hasła.

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

Przeglądarka (Chrome) może wyświetlić monit o „Zapisz hasło”, ale bez względu na to, czy użytkownik wybierze opcję Zapisz, następnym razem, gdy się zaloguje, hasło automatycznie wypełni pole ukrytego hasła, czyli zerowe miejsce w tablicy, pozostawiając pierwsze miejsce puste.

Próbowałem zdefiniować tablicę, na przykład „hasło [część 2]”, ale wciąż ją pamiętam. Myślę, że wyrzuca to, jeśli jest to nieindeksowana tablica, ponieważ nie ma innego wyjścia, jak upuścić ją na pierwszym miejscu.

Następnie używasz wybranego języka programowania, aby uzyskać dostęp do tablicy, na przykład PHP,

echo $_POST['password'][1];
Mikrofon
źródło
1
Dzięki temu ukrywasz problem z bezpieczeństwem - skrót hasła jest nadal przechowywany w pamięci podręcznej przeglądarki.
Alexander Burakevych
1
Czy mógłbyś wyjaśnić? Hasło zostanie wysłane jako zwykły tekst przy użyciu POST. O ile przeczytałem, żądania POST nie mogą być buforowane. Czy twierdzisz, że istnieje alternatywa dla używania POST do wysyłania danych? A może mówisz, że hasło jest przechowywane w przeglądarce, ponieważ nie przechowuje hasła, ale pustą wartość na początku tablicy, czy przetestowałeś tę metodę?
Mike
0

Ponieważ większość autocompletesugestii, w tym zaakceptowana odpowiedź, nie działa w dzisiejszych przeglądarkach internetowych (tzn. Ignorują menedżer haseł przeglądarki internetowej autocomplete), nowszym rozwiązaniem jest zamiana między passworditext typów i sprawiają, że kolor tła dopasować kolor tekstu, gdy pole to zwykłe pole tekstowe, które nadal ukrywa hasło, będąc prawdziwym polem hasła, gdy użytkownik (lub program taki jak KeePass) wprowadza hasło. Przeglądarki nie proszą o zapisanie haseł przechowywanych w zwykłych polach tekstowych.

Zaletą tego podejścia jest to, że umożliwia stopniowe ulepszanie i dlatego nie wymaga Javascript, aby pole działało jak normalne pole hasła (możesz również zacząć od zwykłego pola tekstowego i zastosować to samo podejście, ale tak naprawdę nie jest to HIPAA Zgodny z PHI / PII). To podejście nie zależy również od ukrytych formularzy / pól, które niekoniecznie muszą być wysłane na serwer (ponieważ są ukryte), a niektóre z tych sztuczek również nie działają w kilku nowoczesnych przeglądarkach.

Wtyczka jQuery:

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

Odpowiedni kod źródłowy z powyższego linku:

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

Próbny:

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

Kliknij „Dodaj wpis” w menu, a następnie przewiń w dół strony do „Moduł: Zatrzymaj Menedżera haseł”.

Oświadczenie: Chociaż takie podejście działa dla osób widzących, mogą występować problemy z oprogramowaniem do odczytu ekranu. Na przykład czytnik ekranu może odczytać hasło użytkownika na głos, ponieważ widzi zwykłe pole tekstowe. Mogą również wystąpić inne nieprzewidziane konsekwencje korzystania z powyższej wtyczki. Zmiana wbudowanej funkcji przeglądarki internetowej powinna być wykonywana oszczędnie poprzez testowanie szerokiej gamy warunków i przypadków brzegowych.

CubicleSoft
źródło
-1

Czy istnieje sposób, aby witryna powiedziała przeglądarce, aby nie oferowała zapamiętywania haseł?

Witryna informuje przeglądarkę, że jest to hasło za pomocą <input type="password">. Więc jeśli ty trzeba to zrobić z perspektywy strony wtedy trzeba by zmienić. (Oczywiście nie polecam tego).

Najlepszym rozwiązaniem byłoby skonfigurowanie przeglądarki przez użytkownika, aby nie zapamiętywała haseł.

Joseph Pecoraro
źródło
3
Jak to oczywiste, że nie zaleca się zmiany pola typu danych wejściowych? Pomocne byłoby opracowanie kwestii bezpieczeństwa.
Karl
1
@karl: ponieważ konieczność wpisania hasła w otwartym polu pozwala na „surfowanie po ramieniu”, proces zbierania hasła poprzez patrzenie na ekran podczas pisania.
David Schmitt
Nie tylko surfowanie po barkach ludzi, ale oprogramowanie szpiegujące lub wirusy mogą oglądać Twój ekran i sprawdzać, co wpisano w polach tekstu jawnego.
Karl
6
@karl: Jeśli masz na swoim komputerze oprogramowanie szpiegujące / wirusy, ochrona przed gwiazdką nie uratuje Cię. Zainstalowana aplikacja nie jest trudniejsza do przechwycenia tego, co wpisywane jest w polu „hasło”, niż robi to samo w przypadku pola zwykłego tekstu.
Markus Olsson
3
Ponadto, jeśli przeglądarka widzi zwykłe wprowadzanie tekstu zamiast hasła, prawdopodobnie ukryje hasło w bazie danych autouzupełniania zamiast bazy danych haseł ... a następnie zasugeruje je lub nawet automatycznie wypełni na niepowiązanej stronie! Tak naprawdę jesteś w jeszcze gorszej sytuacji niż na początku.
zwolnienie
-1

Jeśli nie chcesz ufać flagom autouzupełniania, możesz upewnić się, że użytkownik wpisze w polu przy użyciu zdarzenia onchange. Poniższy kod jest prostym formularzem HTML. Ukryty element formularza password_edited zaczyna się od zera. Po zmianie wartości hasła JavaScript u góry (funkcja pw_edited) zmienia wartość na 1. Po naciśnięciu przycisku sprawdza on tutaj kod centrum wartości przed przesłaniem formularza . W ten sposób, nawet jeśli przeglądarka ignoruje cię i automatycznie wypełnia pole, użytkownik nie może przejść do strony logowania bez wpisania pola hasła. Upewnij się również, że pole hasła jest puste, gdy ustawiony jest fokus. W przeciwnym razie możesz dodać postać na końcu, a następnie wrócić i usunąć ją, aby oszukać system. Zalecam dodatkowo dodanie do hasła autocomplete = "off", ale ten przykład pokazuje, jak działa kod zapasowy.

<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>
Tomek
źródło
-1

autocomplete = „off” nie działa w celu wyłączenia menedżera haseł w Firefoksie 31 i najprawdopodobniej nie w niektórych wcześniejszych wersjach.

Zapoznaj się z dyskusją na ten temat w Mozilli: https://bugzilla.mozilla.org/show_bug.cgi?id=956906

Chcieliśmy użyć drugiego pola hasła, aby wprowadzić hasło jednorazowe wygenerowane przez token. Teraz używamy wprowadzania tekstu zamiast hasła. :-(

Andreas Stankewitz
źródło
-1

Otrzymałem podobne zadanie, aby wyłączyć automatyczne uzupełnianie nazwy logowania i haseł przez przeglądarkę, po wielu próbach i błędach uznałem poniższe rozwiązanie za optymalne. Po prostu dodaj poniższe elementy sterujące przed oryginalnymi elementami sterującymi.

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

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

Działa to dobrze dla IE11 i Chrome 44.0.2403.107

Szejk
źródło
-2

autocomplete = „off” działa w przypadku większości nowoczesnych przeglądarek, ale inną metodą, którą zastosowałem, która z powodzeniem działała z Epiphany (przeglądarką wspieraną przez WebKit dla GNOME) jest przechowywanie losowo generowanego prefiksu w stanie sesji (lub ukrytego pola, zdarzyło mi się mieć odpowiednia zmienna już w stanie sesji) i użyj jej do zmiany nazw pól. Święto Trzech Króli wciąż chce zapisać hasło, ale wracając do formularza, nie wypełni pól.

Peter Nelson
źródło
Jest to nawet gorsze niż przechowywanie ich w zwykły sposób, ponieważ teraz użytkownik nie widzi, że hasło zostało zapisane, nie uniemożliwiając atakującemu wyodrębnienia hasła ze sklepu.
CodesInChaos
-2

Nie miałem żadnych problemów z użyciem tej metody:

Użyj autocomplete = "off", dodaj ukryte pole hasła, a następnie kolejne nie ukryte. Przeglądarka próbuje automatycznie uzupełnić ukryty, jeśli nie przestrzega autouzupełniania = "wyłączony"

Spechal
źródło
-2

Innym rozwiązaniem jest uczynienie POST przy użyciu ukrytej formy, w której wszystkie dane wejściowe są ukryte. Widoczny formularz użyje wprowadzania typu „hasło”. Ten ostatni formularz nigdy nie zostanie przesłany, więc przeglądarka nie może przechwytywać operacji logowania.

Lord of the Goo
źródło