Jak etycznie podejść do przechowywania hasła użytkownika w celu późniejszego pobrania tekstu jawnego?

Ponieważ nadal buduję coraz więcej witryn i aplikacji internetowych, często jestem proszony o przechowywanie haseł użytkownika w taki sposób, aby można je było odzyskać, jeśli / kiedy użytkownik ma problem (albo w celu wysłania e-maila z zapomnianym hasłem, przejdź przez telefon itp.) Kiedy mogę, zgorzkniałą walczę z tą praktyką i wykonuję wiele „dodatkowych” programów, aby umożliwić resetowanie hasła i pomoc administracyjną bez zapisywania ich rzeczywistego hasła.

Kiedy nie mogę z tym walczyć (lub nie mogę wygrać), zawsze koduję hasło w taki sposób, aby przynajmniej nie było ono przechowywane w bazie danych jako zwykły tekst - choć mam świadomość, że jeśli moja DB zostanie zhakowana łamanie haseł nie wymagałoby wiele od sprawcy, więc czuję się nieswojo.

W idealnym świecie ludzie często aktualizują hasła i nie duplikują ich w wielu różnych witrynach - niestety znam WIELU ludzi, którzy mają to samo hasło do pracy / domu / e-maila / konta bankowego, a nawet dają mi je swobodnie, gdy potrzebują pomocy. Nie chcę być odpowiedzialny za ich śmierć finansową, jeśli moje procedury bezpieczeństwa DB z jakiegoś powodu zawiodą.

Z moralnego i etycznego punktu widzenia czuję się odpowiedzialny za ochronę tego, co może być dla niektórych użytkowników źródłem utrzymania, nawet jeśli traktują to z dużo mniejszym szacunkiem. Jestem pewien, że istnieje wiele sposobów podejścia i argumentów dotyczących solenia skrótów i różnych opcji kodowania, ale czy istnieje jedna „najlepsza praktyka”, kiedy trzeba je przechowywać? W prawie wszystkich przypadkach korzystam z PHP i MySQL, jeśli ma to jakiś wpływ na sposób, w jaki powinienem obsługiwać specyfikę.

Dodatkowe informacje o nagrodę

Chcę wyjaśnić, że wiem, że nie należy tego robić i że w większości przypadków najlepiej jest odmówić. Nie szukam jednak wykładu na temat zalet takiego podejścia. Szukam najlepszych kroków, jeśli podejmiecie takie podejście.

W notatce poniżej wskazałem, że strony internetowe skierowane głównie do osób starszych, upośledzonych umysłowo lub bardzo młodych mogą stać się mylące dla ludzi, gdy zostaną poproszeni o wykonanie bezpiecznej procedury odzyskiwania hasła. Chociaż w tych przypadkach możemy uznać, że jest to proste i przyziemne, niektórzy użytkownicy potrzebują dodatkowej pomocy w postaci pomocy technicznej w systemie lub przesłania ich pocztą elektroniczną / bezpośrednio do nich.

W takich systemach szybkość ścierania z tych danych demograficznych może spowalniać aplikację, jeśli użytkownicy nie otrzymają takiego poziomu pomocy w dostępie, więc proszę o odpowiedź z taką konfiguracją.

Dziękuję wszystkim

To było zabawne pytanie z dużą ilością debat i podobało mi się. Ostatecznie wybrałem odpowiedź, która zachowuje bezpieczeństwo haseł (nie będę musiał przechowywać zwykłego tekstu ani haseł do odzyskania), ale umożliwia także, że określona przeze mnie baza użytkowników zaloguje się do systemu bez poważnych wad, które znalazłem z normalne odzyskiwanie hasła.

Jak zawsze było około 5 odpowiedzi, które chciałbym oznaczyć jako poprawne z różnych powodów, ale musiałem wybrać najlepszą - cała reszta otrzymała +1. Dziękuję wszystkim!

Dziękujemy również wszystkim członkom społeczności Stack, którzy głosowali na to pytanie i / lub oznaczyli je jako ulubione. Uznam trafienie 100 głosów za komplement i mam nadzieję, że ta dyskusja pomogła komuś innemu z tą samą troską, co ja.

Co powiesz na inne podejście lub podejście do tego problemu? Zapytaj, dlaczego hasło musi być w postaci zwykłego tekstu: jeśli jest to po to, aby użytkownik mógł je odzyskać, to mówiąc ściśle, tak naprawdę nie musisz odzyskiwać ustawionego hasła (nie pamiętają, co to jest) muszą być w stanie podać im hasło, którego mogą użyć .

Pomyśl o tym: jeśli użytkownik musi odzyskać hasło, to dlatego, że je zapomniał. W takim przypadku nowe hasło jest tak samo dobre jak stare. Ale jedną z wad popularnych obecnie mechanizmów resetowania haseł jest to, że hasła generowane podczas operacji resetowania to na ogół kilka losowych znaków, więc trudno jest po prostu wpisać poprawnie, chyba że skopiują-n- pasta. Może to stanowić problem dla mniej doświadczonych użytkowników komputerów.

Jednym ze sposobów obejścia tego problemu jest zapewnienie automatycznie generowanych haseł, które są mniej więcej tekstem w języku naturalnym. Chociaż łańcuchy języka naturalnego mogą nie mieć entropii, jaką ma ciąg losowych znaków o tej samej długości, nic nie wskazuje na to, że automatycznie wygenerowane hasło musi mieć tylko 8 (lub 10 lub 12) znaków. Uzyskaj automatycznie wygenerowane hasło o wysokiej entropii, łącząc ze sobą kilka losowych słów (zostaw odstęp między nimi, aby były rozpoznawalne i pisane przez każdego, kto umie czytać). Sześć losowych słów o różnej długości jest prawdopodobnie łatwiejszych do poprawnego wpisywania i pewności niż 10 losowych znaków, a także mogą mieć wyższą entropię. Na przykład entropia 10-znakowego hasła losowo narysowanego wielkimi, małymi literami, cyfry i 10 symboli interpunkcyjnych (w sumie 72 prawidłowe symbole) miałyby entropię 61,7 bitów. Korzystając ze słownika 7776 słów (jak używa Diceware), który można losowo wybrać dla hasła składającego się z sześciu słów, hasło miałoby entropię 77,4 bitów. ZobaczCzęsto zadawane pytania dotyczące Diceware, aby uzyskać więcej informacji.

• hasło z około 77 bitami entropii: „przyznaj ostry styl tabeli rozbłysku prozy”

• hasło z około 74 bitami entropii: „K: & $ R ^ tt ~ qkD”

Wiem, że wolałbym wpisać frazę, a dzięki funkcji kopiuj i wklej fraza jest nie mniej łatwa w użyciu niż hasło, więc nie ma utraty. Oczywiście, jeśli twoja strona internetowa (lub jakikolwiek inny chroniony zasób) nie potrzebuje 77 bitów entropii dla automatycznie wygenerowanego hasła, wygeneruj mniej słów (jestem pewien, że użytkownicy doceniliby).

Rozumiem argumenty, że istnieją zasoby chronione hasłem, które tak naprawdę nie mają wysokiego poziomu wartości, więc naruszenie hasła może nie być końcem świata. Na przykład prawdopodobnie nie obchodzi mnie, czy 80% haseł, które używam na różnych stronach internetowych, zostało naruszonych: wszystko, co może się zdarzyć, to ktoś spamujący lub publikujący pod moim nazwiskiem przez jakiś czas. To nie byłoby wspaniałe, ale to nie tak, że włamali się na moje konto bankowe. Biorąc jednak pod uwagę fakt, że wiele osób używa tego samego hasła do swoich witryn na forach internetowych, jak do swoich kont bankowych (i prawdopodobnie krajowych baz danych bezpieczeństwa), myślę, że najlepiej byłoby obsługiwać nawet te hasła „niskiej wartości” - do odzyskania.

Wyobraź sobie, że ktoś zlecił budowę dużego budynku - powiedzmy, baru - i odbywa się następująca rozmowa:

Architekt: W przypadku budynku o tej wielkości i pojemności potrzebne będą wyjścia przeciwpożarowe tutaj, tutaj i tutaj.
Klient: Nie, to zbyt skomplikowane i kosztowne w utrzymaniu, nie chcę żadnych bocznych ani tylnych drzwi.
Architekt: Sir, wyjścia przeciwpożarowe nie są opcjonalne, są wymagane zgodnie z kodeksem pożarowym miasta.
Klient: Nie płacę za kłótnię. Po prostu zrób to, o co prosiłem.

Czy architekt pyta zatem, jak etycznie zbudować ten budynek bez wyjść przeciwpożarowych?

W branży budowlanej i inżynieryjnej konwersacja najprawdopodobniej zakończy się w następujący sposób:

Architekt: Tego budynku nie można zbudować bez wyjść z ognia. Możesz udać się do dowolnego licencjonowanego specjalisty, który powie ci to samo. Wychodzę teraz; oddzwoń, kiedy będziesz gotowy do współpracy.

Programowanie komputerowe może nie być zawodem licencjonowanym , ale ludzie często zastanawiają się, dlaczego nasz zawód nie cieszy się takim samym szacunkiem jak inżynier cywilny lub mechanik - cóż, nie szukaj dalej. Zawody te, gdy wręczane są śmieci (lub wręcz niebezpieczne) wymagania, po prostu odmawiają. Wiedzą, że nie jest to wymówka, by powiedzieć: „cóż, zrobiłem, co mogłem, ale nalegał i muszę zrobić to, co mówi”. Mogliby stracić licencję na tę wymówkę.

Nie wiem, czy ty lub twoi klienci jesteście częścią spółki giełdowej, ale przechowywanie haseł w jakiejkolwiek możliwej do odzyskania formie spowodowałoby niepowodzenie kilku różnych rodzajów audytów bezpieczeństwa. Problemem nie jest to, jak trudne byłoby dla niektórych „hakerów”, którzy uzyskali dostęp do bazy danych w celu odzyskania haseł. Zdecydowana większość zagrożeń bezpieczeństwa ma charakter wewnętrzny. To, przed czym musisz chronić, to niezadowolony pracownik odchodzący ze wszystkimi hasłami i sprzedający je najlepszemu oferentowi. Korzystanie z szyfrowania asymetrycznego i przechowywanie klucza prywatnego w osobnej bazie danych absolutnie nic nie zapobiega temu scenariuszowi; zawsze będzie ktoś z dostępem do prywatnej bazy danych, a to poważne zagrożenie bezpieczeństwa.

Nie ma etycznego ani odpowiedzialnego sposobu przechowywania haseł w postaci możliwej do odzyskania. Kropka.

Możesz zaszyfrować hasło + sól za pomocą klucza publicznego. W przypadku logowania wystarczy sprawdzić, czy przechowywana wartość jest równa wartości obliczonej na podstawie danych wprowadzonych przez użytkownika + sól. Jeśli przyjdzie czas, kiedy hasło musi zostać przywrócone w postaci zwykłego tekstu, możesz odszyfrować ręcznie lub półautomatycznie za pomocą klucza prywatnego. Klucz prywatny może być przechowywany w innym miejscu i może być dodatkowo szyfrowany symetrycznie (co będzie wymagać interakcji człowieka w celu odszyfrowania hasła).

Myślę, że tak naprawdę jest to trochę podobne do sposobu działania Windows Recovery Agent .

• Hasła są przechowywane w postaci zaszyfrowanej
• Ludzie mogą się logować bez odszyfrowywania do zwykłego tekstu
• Hasła można odzyskać jako zwykły tekst, ale tylko za pomocą klucza prywatnego, który można przechowywać poza systemem (w sejfie bankowym, jeśli chcesz).

Nie poddawaj się Bronią, której możesz użyć, aby przekonać swoich klientów, jest niezaprzeczalność. Jeśli możesz zrekonstruować hasła użytkownika za pomocą dowolnego mechanizmu, dałeś swoim klientom legalny mechanizm niezaprzeczalności i mogą oni odrzucić każdą transakcję zależną od tego hasła, ponieważ nie ma możliwości, aby dostawca udowodnił, że nie zrekonstruował hasła i sfinalizuj transakcję. Jeśli hasła są poprawnie przechowywane jako podsumowania, a nie zaszyfrowane, jest to niemożliwe, ergo albo klient końcowy sam wykonał transakcję, albo naruszył swój obowiązek staranności wpisania hasła. W obu przypadkach odpowiedzialność spoczywa na nim wprost. Pracowałem nad przypadkami, w których wyniosłoby to setki milionów dolarów. Nie coś, co chcesz się pomylić.

Nie można etycznie przechowywać haseł do późniejszego pobrania w postaci zwykłego tekstu. To takie proste. Nawet Jon Skeet nie może etycznie przechowywać haseł do późniejszego pobrania w postaci zwykłego tekstu. Jeśli użytkownicy mogą w jakiś sposób odzyskać hasła w postaci zwykłego tekstu, potencjalnie również haker może znaleźć lukę w zabezpieczeniach w kodzie. I to nie tylko hasło jednego użytkownika jest naruszane, ale wszystkie z nich.

Jeśli Twoi klienci mają z tym problem, powiedz im, że przechowywanie haseł do odzyskania jest niezgodne z prawem. W każdym razie tutaj, w Wielkiej Brytanii, Ustawa o ochronie danych z 1998 r. (W szczególności załącznik nr 1, część II, ust. 9) wymaga od administratorów danych stosowania odpowiednich środków technicznych w celu zapewnienia bezpieczeństwa danych osobowych, biorąc pod uwagę między innymi szkody, które mogą powstać, gdyby dane zostały naruszone - co może być znaczące dla użytkowników, którzy dzielą hasła między witrynami. Jeśli nadal mają problemy z rozwikłaniem faktu, że jest to problem, wskaż im kilka przykładów z prawdziwego świata, takich jak ten .

Najprostszym sposobem, aby umożliwić użytkownikom odzyskanie loginu, jest wysłanie do nich e-mailem jednorazowego linku, który loguje ich automatycznie i prowadzi bezpośrednio do strony, na której mogą wybrać nowe hasło. Stwórz prototyp i pokaż mu w akcji.

Oto kilka postów na blogu, które napisałem na ten temat:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Aktualizacja: zaczynamy teraz widzieć procesy i postępowania sądowe przeciwko firmom, które nie zabezpieczyły odpowiednio hasła swoich użytkowników. Przykład: LinkedIn sprowadził pozew zbiorowy w wysokości 5 milionów dolarów ; Sony ukarało grzywną 250 000 funtów za włamanie do PlayStation . Jeśli dobrze pamiętam, LinkedIn faktycznie szyfrował hasła użytkowników, ale szyfrowanie, którego używał, było zbyt słabe, aby było skuteczne.

Po przeczytaniu tej części:

W notatce poniżej wskazałem, że strony internetowe skierowane głównie do osób starszych, upośledzonych umysłowo lub bardzo młodych mogą stać się mylące dla ludzi, gdy zostaną poproszeni o wykonanie bezpiecznej procedury odzyskiwania hasła. Chociaż w tych przypadkach możemy uznać, że jest to proste i przyziemne, niektórzy użytkownicy potrzebują dodatkowej pomocy w postaci pomocy technicznej w systemie lub przesłania ich pocztą elektroniczną / bezpośrednio do nich.

W takich systemach szybkość ścierania z tych danych demograficznych może spowalniać aplikację, jeśli użytkownicy nie otrzymają takiego poziomu pomocy w dostępie, więc proszę o odpowiedź z taką konfiguracją.

Zastanawiam się, czy którekolwiek z tych wymagań wymagają systemu haseł, który można odzyskać. Na przykład: Ciocia Mabel dzwoni i mówi „Twój program internetowy nie działa, nie znam swojego hasła”. „OK” mówi dron obsługi klienta „pozwól mi sprawdzić kilka szczegółów, a następnie dam ci nowe hasło . Kiedy się zalogujesz, zapyta, czy chcesz zachować to hasło, czy zmienić je na coś, co możesz zapamiętać łatwiejsze."

Następnie system jest skonfigurowany tak, aby wiedział, kiedy nastąpiło zresetowanie hasła i wyświetla komunikat „czy chcesz zachować nowe hasło lub wybrać nowe”.

Jak to jest gorsze dla osób mniej znających się na komputerach niż mówienie o swoim starym haśle? I chociaż pracownik obsługi klienta może popełnić błąd, sama baza danych jest znacznie bezpieczniejsza na wypadek jego naruszenia.

Skomentuj, co jest złe w mojej sugestii, a ja zasugeruję rozwiązanie, które faktycznie robi to, czego początkowo chciałeś.

Michael Brooks wypowiedział się głośno o CWE-257 - o tym, że niezależnie od metody, której użyjesz, Ty (administrator) nadal możesz odzyskać hasło. A co z tymi opcjami:

1. Zaszyfruj hasło za pomocą klucza publicznego innej osoby - jakiegoś organu zewnętrznego. W ten sposób nie możesz go odtworzyć osobiście, a użytkownik będzie musiał udać się do tego organu zewnętrznego i poprosić o odzyskanie hasła.
2. Zaszyfruj hasło za pomocą klucza wygenerowanego z drugiego hasła. Wykonaj to szyfrowanie po stronie klienta i nigdy nie przesyłaj go w sposób jawny do serwera. Następnie, aby odzyskać, ponownie odszyfruj po stronie klienta, ponownie generując klucz z ich danych wejściowych. Wprawdzie w tym podejściu używa się w zasadzie drugiego hasła, ale zawsze możesz im powiedzieć, aby je zapisał lub użyć starego podejścia do pytań zabezpieczających.

Myślę, że 1. jest lepszym wyborem, ponieważ umożliwia wyznaczenie osoby w firmie klienta do przechowywania klucza prywatnego. Upewnij się, że sami wygenerują klucz i przechowują go wraz z instrukcjami w sejfie itp. Możesz nawet zwiększyć bezpieczeństwo, wybierając tylko szyfrowanie i dostarczanie określonych znaków z hasła do wewnętrznej strony trzeciej, aby musieli złamać hasło, aby zgadnąć to. Dostarczając te znaki użytkownikowi, prawdopodobnie będą pamiętać, co to było!

W odpowiedzi na to pytanie dużo dyskutowano na temat obaw związanych z bezpieczeństwem, ale chciałbym dodać wzmiankę o korzyściach. Do tej pory nie widziałem żadnej uzasadnionej korzyści z posiadania w systemie hasła do odzyskania. Rozważ to:

• Czy użytkownik korzysta z przesłania hasła w wiadomości e-mail? Nie. Otrzymują więcej korzyści z jednorazowego linku do resetowania hasła, który, mam nadzieję, pozwoli im wybrać hasło, które zapamięta.
• Czy użytkownik korzysta z wyświetlania hasła na ekranie? Nie, z tego samego powodu, co powyżej; powinni wybrać nowe hasło.
• Czy użytkownik korzysta z tego, że osoba udzielająca pomocy wymówi hasło do użytkownika? Nie; ponownie, jeśli osoba obsługująca uzna prośbę użytkownika o podanie hasła za poprawnie uwierzytelnioną, korzyścią dla użytkownika będzie otrzymanie nowego hasła i możliwość jego zmiany. Ponadto wsparcie telefoniczne jest droższe niż automatyczne resetowanie hasła, więc firma również nie korzysta.

Wydaje się, że jedynymi, które mogą skorzystać z haseł, które można odzyskać, są hasła o złośliwych zamiarach lub osoby obsługujące słabe interfejsy API, które wymagają wymiany haseł stron trzecich (proszę nigdy nie używać tych interfejsów API!). Być może możesz wygrać swój argument, mówiąc zgodnie z prawdą swoim klientom, że firma nie zyskuje żadnych korzyści, a jedynie zobowiązania, przechowując hasła do odzyskania .

Czytając między wierszami tego rodzaju żądań, zobaczysz, że Twoi klienci prawdopodobnie nie rozumieją, a nawet w ogóle nie dbają o zarządzanie hasłami. To, czego naprawdę chcą, to system uwierzytelniania, który nie jest taki trudny dla ich użytkowników. Oprócz powiedzenia im, że tak naprawdę nie chcą haseł do odzyskania, powinieneś zaoferować im sposoby, aby proces uwierzytelniania był mniej bolesny, szczególnie jeśli nie potrzebujesz wysokiego poziomu bezpieczeństwa, powiedzmy, banku:

• Pozwól użytkownikowi użyć swojego adresu e-mail jako nazwy użytkownika. Widziałem niezliczone przypadki, w których użytkownik zapomina swoją nazwę użytkownika, ale niewielu zapomina swój adres e-mail.
• Zaoferuj OpenID i pozwól osobie trzeciej opłacić koszty zapomnienia użytkownika.
• Złagodź ograniczenia hasła. Jestem pewien, że wszyscy byliśmy niesamowicie zirytowani, gdy jakaś strona internetowa nie pozwala na twoje preferowane hasło z powodu bezużytecznych wymagań, takich jak „nie możesz używać znaków specjalnych” lub „twoje hasło jest za długie” lub „twoje hasło musi się zacząć z listem. ” Ponadto, jeśli łatwość użycia jest ważniejsza niż siła hasła, możesz poluzować nawet nie głupie wymagania, dopuszczając krótsze hasła lub nie wymagając mieszania klas znaków. Dzięki złagodzonym ograniczeniom użytkownicy będą częściej używać hasła, którego nie zapomną.
• Nie wygasaj haseł.
• Zezwól użytkownikowi na ponowne użycie starego hasła.
• Pozwól użytkownikowi wybrać własne pytanie dotyczące resetowania hasła.

Ale jeśli z jakiegoś powodu (i powiedz nam powód) naprawdę, naprawdę, naprawdę musisz mieć możliwość odzyskania hasła, możesz uchronić użytkownika przed potencjalnym naruszeniem jego innych kont internetowych, podając mu hasło inne niż hasło - oparty na systemie uwierzytelniania. Ponieważ ludzie znają już systemy nazw użytkowników i haseł i są dobrze sprawdzonym rozwiązaniem, byłoby to ostatecznością, ale z pewnością istnieje wiele kreatywnych alternatyw dla haseł:

• Pozwól użytkownikowi wybrać PIN numeryczny, najlepiej nie 4-cyfrowy, a najlepiej tylko wtedy, gdy chronione są próby użycia siły.
• Poproś użytkownika o wybranie pytania z krótką odpowiedzią, na którą tylko on zna odpowiedź, nigdy się nie zmieni, zawsze będzie pamiętać i nie przeszkadza innym.
• Niech użytkownik wprowadzi nazwę użytkownika, a następnie narysuje łatwy do zapamiętania kształt z wystarczającymi kombinacjami, aby zabezpieczyć się przed zgadywaniem (zobacz to fajne zdjęcie, w jaki sposób G1 robi to, aby odblokować telefon).
• W przypadku witryny internetowej dla dzieci można automatycznie wygenerować rozmyte stworzenie na podstawie nazwy użytkownika (coś w rodzaju identyfikatora) i poprosić użytkownika o nadanie stworzeniu tajnej nazwy. Następnie mogą zostać poproszeni o podanie tajnej nazwy stworzenia w celu zalogowania się.

Zgodnie z komentarzem, który wypowiedziałem na temat tego pytania:
Prawie wszyscy bardzo pochylili się nad jedną ważną kwestią ... Moja początkowa reakcja była bardzo podobna do @Michaela Brooksa, dopóki nie zdałam sobie sprawy, jak @stefanw, że problem jest zepsuty , ale takie są.
Ale potem przyszło mi do głowy, że może tak nie być! Brakującym punktem tutaj jest niewypowiedziana wartość zasobów aplikacji. Mówiąc wprost, w przypadku systemu o niskiej wartości, w pełni bezpieczny mechanizm uwierzytelniania, z całym procesem, byłby nadmierną umiejętnością i niewłaściwym wyborem bezpieczeństwa.
Oczywiście dla banku „najlepsze praktyki” są koniecznością i nie ma sposobu, aby etycznie naruszać CWE-257. Łatwo jednak pomyśleć o systemach o niskiej wartości, w których po prostu nie warto (ale wciąż wymagane jest proste hasło).

Ważne jest, aby pamiętać, że prawdziwa wiedza na temat bezpieczeństwa polega na znajdowaniu odpowiednich kompromisów, a NIE na dogmatycznym wypowiadaniu „najlepszych praktyk”, które każdy może przeczytać online.

Jako takie sugeruję inne rozwiązanie: w
zależności od wartości systemu i TYLKO JEŚLI system ma odpowiednio niską wartość bez „drogich” aktywów (sama tożsamość, w tym), ORAZ istnieją ważne wymagania biznesowe, które wymagają właściwego procesu niemożliwe (lub wystarczająco trudne / drogie), ORAZ klient jest informowany o wszystkich zastrzeżeniach ...
W takim przypadku właściwe byłoby po prostu zezwolenie na odwracalne szyfrowanie, bez specjalnych przeszkód.
Przestaję mówić, żeby w ogóle nie zawracać sobie głowy szyfrowaniem, ponieważ jest bardzo prosty / tani w implementacji (nawet biorąc pod uwagę zarządzanie kluczami pasywnymi), i zapewnia NIEKTÓRE zabezpieczenie (więcej niż koszt jego wdrożenia). Warto również zastanowić się, jak podać użytkownikowi oryginalne hasło, czy to przez e-mail, wyświetlane na ekranie itp.
Ponieważ zakłada się tutaj, że wartość skradzionego hasła (nawet zbiorczo) jest dość niska, rozwiązania te mogą być ważne.

Ponieważ toczy się ożywiona dyskusja, w rzeczywistości KILKA ożywionych dyskusji, w różnych postach i osobnych wątkach komentujących, dodam kilka wyjaśnień i odpowiem na niektóre z bardzo dobrych kwestii, które zostały poruszone gdzie indziej tutaj.

Na początek myślę, że dla wszystkich jest jasne, że zezwolenie na odzyskanie oryginalnego hasła użytkownika jest złą praktyką i ogólnie nie jest dobrym pomysłem. To wcale nie jest kwestionowane ...
Co więcej, podkreślę, że w wielu, nie NAJBARDZIEJ, sytuacjach - to naprawdę źle, nawet ohydnie, paskudnie i brzydko .

Jednak sedno pytania dotyczy zasady: czy istnieje sytuacja, w której może to nie być konieczne , a jeśli tak, to w jaki sposób zrobić to w jak najbardziej właściwy sposób .

Teraz, jak wspomniano @ Thomas, @sfussenegger i kilka innych, jedynym właściwym sposobem odpowiedzi na to pytanie jest dokładna analiza ryzyka każdej (lub hipotetycznej) sytuacji, aby zrozumieć, o co toczy się gra , ile warto chronić i jakie inne środki łagodzące są w grze, aby zapewnić tę ochronę.
Nie, to NIE jest modne hasło, jest to jedno z podstawowych, najważniejszych narzędzi dla prawdziwego specjalisty ds. Bezpieczeństwa. Najlepsze praktyki są do pewnego stopnia dobre (zwykle jako wytyczne dla niedoświadczonych i hacków), po tym momencie zaczyna się przemyślana analiza ryzyka.

Wiesz, to zabawne - zawsze uważałem się za jednego z fanatyków bezpieczeństwa i jakoś jestem po przeciwnej stronie tak zwanych „ekspertów bezpieczeństwa” ... Cóż, prawda jest taka - ponieważ jestem fanatykiem, i prawdziwym ekspertem w dziedzinie bezpieczeństwa - nie wierzę w wypowiadanie dogmatów „najlepszych praktyk” (CWE) BEZ tej najważniejszej analizy ryzyka .
„Strzeż się fanatyków bezpieczeństwa, którzy szybko nakładają wszystko na pasek narzędzi, nie wiedząc, przed czym się bronią. Większe bezpieczeństwo niekoniecznie oznacza dobre bezpieczeństwo”.
Analiza ryzyka i prawdziwi fanatycy bezpieczeństwa wskazywaliby na mądrzejszy kompromis oparty na wartości / ryzyku, oparty na ryzyku, potencjalnej stracie, możliwych zagrożeniach, uzupełniających ograniczeniach itp. Każdy „ekspert ds. Bezpieczeństwa”, który nie może wskazać solidnej analizy ryzyka jako podstawą dla ich rekomendacji lub wspierać logiczne kompromisy, ale zamiast tego woleliby wypowiadać dogmaty i CWE, nawet nie rozumiejąc, jak przeprowadzić analizę ryzyka, są niczym innym, jak hackami bezpieczeństwa, a ich wiedza nie jest warta papieru toaletowego, na którym wydrukowali.

Rzeczywiście, w ten sposób uzyskujemy absurdalność, jaką jest ochrona lotniska.

Zanim jednak porozmawiamy o odpowiednich kompromisach w NINIEJSZEJ SYTUACJI, rzućmy okiem na pozorne ryzyko (oczywiste, ponieważ nie mamy wszystkich podstawowych informacji na temat tej sytuacji, wszyscy hipotezujemy - ponieważ pytanie brzmi, co hipotetyczne może się zdarzyć ...)
Załóżmy, że system NISKIEJ WARTOŚCI nie jest tak trywialny, że ma publiczny dostęp - właściciel systemu chce zapobiec przypadkowemu podszywaniu się, ale „wysokie” bezpieczeństwo nie jest tak ważne, jak łatwość użycia. (Tak, uzasadnionym kompromisem jest AKCEPTACJA ryzyka, że ​​każdy biegły dzieciak-skrypt może zhakować witrynę ... Czekaj, czy APT nie jest teraz w modzie ...?)
Na przykład załóżmy, że organizuję prostą stronę na spotkanie dużej rodziny, pozwalając wszystkim na burzę mózgów na temat tego, gdzie chcemy wybrać się w tym roku na kemping. Mniej martwię się o jakiegoś anonimowego hakera, a nawet kuzyna Freda, wciskającego powtarzające się sugestie powrotu do jeziora Wantanamanabikiliki, ponieważ jestem o tym, że ciocia Erma nie może się zalogować, kiedy musi. A teraz ciocia Erma, fizyk nuklearny, nie jest zbyt dobra w zapamiętywaniu haseł, a nawet w ogóle przy użyciu komputerów ... Chcę więc usunąć wszelkie możliwe dla niej tarcia. Ponownie, NIE martwię się o hacki, po prostu nie chcę głupich błędów złego logowania - chcę wiedzieć, kto nadchodzi i czego chcą.

Tak czy siak.
Więc jakie są nasze główne zagrożenia tutaj, jeśli symetrycznie szyfrujemy hasła zamiast korzystania z jednokierunkowego skrótu?

• Podszywać się pod użytkowników? Nie, już zaakceptowałem to ryzyko, nie jest interesujące.
• Zły administrator? Cóż, może ... Ale znowu, nie dbam o to, czy ktoś może podszyć się pod innego użytkownika, WEWNĘTRZNY lub nie ... i tak czy inaczej złośliwy administrator dostanie twoje hasło bez względu na wszystko - jeśli twój administrator się zepsuje, jego gra i tak się skończy.
• Kolejnym poruszonym zagadnieniem jest to, że tożsamość jest faktycznie współdzielona przez kilka systemów. Ach! To bardzo interesujące ryzyko, które wymaga dokładniejszego przyjrzenia się.
  Zacznę od stwierdzenia, że ​​nie chodzi o wspólną tożsamość , ale o dowód lub poświadczenie uwierzytelnienia. Ok, ponieważ wspólne hasło skutecznie pozwoli mi wejść do innego systemu (powiedzmy, moje konto bankowe lub Gmail), jest to w rzeczywistości ta sama tożsamość, więc jest to tylko semantyka ... Tyle że nie . W tym scenariuszu tożsamość jest zarządzana osobno przez każdy system (chociaż mogą istnieć systemy identyfikatorów stron trzecich, takie jak OAuth - wciąż oddzielone od tożsamości w tym systemie - więcej na ten temat później).
  W związku z tym głównym punktem ryzyka jest to, że użytkownik chętnie wprowadzi swoje (takie samo) hasło w kilku różnych systemach - a teraz ja (administrator) lub inny haker mojej witryny będzie miał dostęp do haseł cioci Ermy w celu miejsce rakiet nuklearnych.

Hmmm.

Czy coś Ci się wydaje?

Powinno.

Zacznijmy od tego, że ochrona systemu pocisków nuklearnych nie jest moją odpowiedzialnością , buduję po prostu frakkinowe rodzinne wyjście (dla MOJEJ rodziny). Więc czyja to odpowiedzialność? Umm ... A może system rakiet nuklearnych? Duh.
Po drugie, jeśli chciałbym ukraść czyjeś hasło (ktoś, kto jest znany z tego, że wielokrotnie używa tego samego hasła między stronami bezpiecznymi i niezbyt bezpiecznymi) - dlaczego miałbym zawracać sobie głowę hackowaniem Twojej witryny? A może masz problem z szyfrowaniem symetrycznym? Goshdarnitall, mogę po prostu założyć własną prostą stronę internetową , aby użytkownicy zarejestrowali się, aby otrzymywać BARDZO WAŻNE WIADOMOŚCI o wszystkim, czego chcą ... Puffo Presto, „ukradłem” ich hasła.

Tak, edukacja użytkowników zawsze wraca do gryzienia nas, prawda?
I nic nie możesz na to poradzić ... Nawet jeśli MASZ hashować ich hasła na swojej stronie i robić wszystko inne, o czym TSA może pomyśleć, dodałeś ochronę do ich hasła NIE JEDEN BIAŁY , jeśli zamierzają zachować obiecująco umieszczając swoje hasła w każdej witrynie, na którą wpadają. Nawet nie kłopocz się próbowaniem.

Innymi słowy, nie posiadasz ich haseł , więc przestań próbować zachowywać się tak jak ty.

Tak więc, moi drodzy eksperci od bezpieczeństwa, jak stara dama pytała Wendy: „GDZIE jest ryzyko?”

Kolejne kilka punktów w odpowiedzi na niektóre poruszone powyżej kwestie:

• CWE nie jest prawem ani regulacją, ani nawet standardem. Jest to zbiór typowych słabości , tj. Odwrotność „najlepszych praktyk”.
• Kwestia wspólnej tożsamości jest faktycznym problemem, ale źle zrozumianym (lub fałszywie przedstawionym) przez naysayers tutaj. Jest to kwestia wspólnego dzielenia się tożsamością (!), A NIE łamania haseł w systemach o niskiej wartości. Jeśli dzielisz hasło między systemem o niskiej i wysokiej wartości, problem już istnieje!
• Do tego czasu poprzedni punkt faktycznie wskazywałby ZNOWU użycie OAuth i tym podobnych zarówno dla tych systemów o niskiej wartości, jak i systemów bankowych o wysokiej wartości.
• Wiem, że to tylko przykład, ale (niestety) systemy FBI nie są tak naprawdę najlepiej zabezpieczone. Nie tak jak serwery twojego kota, ale nie przewyższają też niektórych bezpieczniejszych banków.
• Podział wiedzy lub podwójna kontrola kluczy szyfrujących NIE dzieje się tylko w wojsku, w rzeczywistości PCI-DSS wymaga tego od praktycznie wszystkich sprzedawców, więc nie jest tak daleko na zewnątrz (JEŻELI wartość to uzasadnia).
• Wszystkim tym, którzy narzekają, że takie pytania sprawiają, że zawód programisty wygląda tak źle: to takie odpowiedzi sprawiają, że zawód bezpieczeństwa wygląda jeszcze gorzej. Ponownie, wymagana jest analiza ryzyka zorientowana na biznes, w przeciwnym razie staniesz się bezużyteczny. Oprócz tego, że się mylisz.
• Wydaje mi się, że właśnie dlatego nie jest dobrym pomysłem, aby wziąć zwykłego programistę i zrzucić na niego więcej obowiązków związanych z bezpieczeństwem, bez szkolenia, aby myśleć inaczej i szukać właściwych kompromisów. Bez obrazy dla tych z was, jestem za tym - ale więcej szkoleń jest w porządku.

Uff Co za długi post ...
Ale żeby odpowiedzieć na twoje oryginalne pytanie, @Shane:

• Wyjaśnij klientowi właściwy sposób robienia rzeczy.
• Jeśli nadal nalega, wyjaśnij coś więcej, nalegaj, kłóć się. W razie potrzeby rzuć napad złości.
• Wyjaśnij mu RYZYKO BIZNESOWE. Szczegóły są dobre, liczby lepsze, demo na żywo jest zwykle najlepsze.
• JEŻELI ON NALEŻY nalegać, I podaje ważne powody biznesowe - nadszedł czas, abyś zadzwonił do sądu:
  Czy ta strona ma niską wartość? Czy to naprawdę uzasadniona sprawa biznesowa? Czy to ci wystarczy? Czy nie można brać pod uwagę innych zagrożeń, które przewyższałyby uzasadnione powody biznesowe? (I oczywiście klient nie jest złośliwą witryną, ale to duh).
  Jeśli tak, to idź dalej. Nie jest wart wysiłku, tarcia i utraconego użycia (w tej hipotetycznej sytuacji), aby wprowadzić niezbędny proces. Każda inna decyzja (znowu w tej sytuacji) jest złym kompromisem.

Podsumowując, i faktyczna odpowiedź - zaszyfruj go za pomocą prostego algorytmu symetrycznego, chroń klucz szyfrowania za pomocą silnych list ACL i najlepiej DPAPI itp., Udokumentuj go i poproś klienta (kogoś wystarczająco starszego, aby podjął decyzję) podpisania się to.

Co powiesz na dom w połowie drogi?

Przechowuj hasła z silnym szyfrowaniem i nie włączaj resetowania.

Zamiast resetować hasła, zezwól na wysłanie hasła jednorazowego (które należy zmienić zaraz po pierwszym logowaniu). Pozwól, aby użytkownik zmienił hasło na dowolne (poprzednie, jeśli sobie życzy).

Możesz to „sprzedać” jako bezpieczny mechanizm resetowania haseł.

Jedynym sposobem, aby umożliwić użytkownikowi odzyskanie oryginalnego hasła, jest zaszyfrowanie go własnym kluczem publicznym. Tylko ten użytkownik może następnie odszyfrować swoje hasło.

Tak więc kroki byłyby następujące:

1. Użytkownik rejestruje się w Twojej witrynie (oczywiście za pośrednictwem protokołu SSL) bez ustawiania hasła. Zaloguj się automatycznie lub podaj tymczasowe hasło.
2. Oferujesz przechowywanie ich publicznego klucza PGP do przyszłego wyszukiwania hasła.
3. Przesyłają swój publiczny klucz PGP.
4. Poprosisz ich o ustawienie nowego hasła.
5. Podają swoje hasło.
6. Hashujesz hasło przy użyciu najlepszego dostępnego algorytmu skrótu (np. Bcrypt). Użyj tego podczas sprawdzania poprawności następnego logowania.
7. Szyfrujesz hasło za pomocą klucza publicznego i przechowujesz je osobno.

Jeśli użytkownik poprosi o podanie hasła, użytkownik odpowiada zaszyfrowanym (nie zaszyfrowanym) hasłem. Jeśli użytkownik nie będzie chciał odzyskać swojego hasła w przyszłości (będzie mógł zresetować je tylko do hasła generowanego przez usługę), kroki 3 i 7 można pominąć.

Myślę, że prawdziwym pytaniem, które powinieneś sobie zadać, jest: „Jak mogę lepiej przekonać ludzi?”.

Mam ten sam problem. I w ten sam sposób zawsze myślę, że ktoś włamuje się do mojego systemu, to nie jest kwestia „kiedy”, ale „kiedy”.

Więc kiedy muszę zrobić stronę internetową, która musi przechowywać poufne informacje, które można odzyskać, takie jak karta kredytowa lub hasło, robię to:

• szyfruj za pomocą: openssl_encrypt (string $ data, string $ method, string $ password)
  • Podręcznik PHP .
• Argument danych :
  • poufne informacje (np. hasło użytkownika)
  • w razie potrzeby serializuj, np. jeśli informacje są tablicą danych, takich jak wiele poufnych informacji
• hasło arg : użyj informacji, którą zna tylko użytkownik, takich jak:
  • tablica rejestracyjna użytkownika
  • numer ubezpieczenia społecznego
  • numer telefonu użytkownika
  • nazwa matki użytkownika
  • losowy ciąg wysłany pocztą elektroniczną i / lub sms w momencie rejestracji
• metoda arg :
  • wybierz jedną metodę szyfrowania, np. „aes-256-cbc”
• NIGDY nie przechowuj informacji użytych w argumencie „hasło” w bazie danych (lub w dowolnym innym miejscu w systemie)

Jeśli konieczne jest odzyskanie tych danych, wystarczy użyć funkcji „openssl_decrypt ()” i poprosić użytkownika o odpowiedź. Np .: „Aby otrzymać hasło, odpowiedz na pytanie: Jaki jest twój numer telefonu komórkowego?”

PS 1 : nigdy nie używaj jako hasła danych przechowywanych w bazie danych. Jeśli musisz zapisać numer telefonu komórkowego użytkownika, nigdy nie używaj tych informacji do kodowania danych. Zawsze używaj informacji, które zna tylko użytkownik lub że trudno jest je komuś poznać.

PS 2 : w przypadku informacji o karcie kredytowej, takich jak „kupowanie jednym kliknięciem”, używam hasła logowania. To hasło jest zakodowane w bazie danych (sha1, md5 itp.), Ale podczas logowania przechowuję hasło w postaci zwykłego tekstu w sesji lub w nietrwałym (tj. W pamięci) bezpiecznym pliku cookie. To proste hasło nigdy nie pozostaje w bazie danych, w rzeczywistości zawsze pozostaje w pamięci, zniszczone na końcu sekcji. Gdy użytkownik kliknie przycisk „Kupowanie jednym kliknięciem”, system użyje tego hasła. Jeśli użytkownik był zalogowany za pomocą usługi, takiej jak Facebook, Twitter itp., Wtedy ponownie pytam o hasło przy zakupie (ok, to nie jest w pełni „po kliknięciu”), a następnie korzystam z niektórych danych usługi, z której użytkownik się zalogował. (jak identyfikator Facebooka).

Zabezpieczanie poświadczeń nie jest operacją binarną: bezpieczna / niezabezpieczona. Bezpieczeństwo polega na ocenie ryzyka i jest mierzone w sposób ciągły. Fanatycy bezpieczeństwa nie lubią myśleć w ten sposób, ale brzydka prawda jest taka, że ​​nic nie jest całkowicie bezpieczne. Hasła z rygorystycznymi wymaganiami dotyczącymi haseł, próbek DNA i skanów siatkówki są bezpieczniejsze, ale kosztem rozwoju i doświadczenia użytkownika. Hasła w postaci zwykłego tekstu są znacznie mniej bezpieczne, ale ich wdrożenie jest tańsze (ale należy tego unikać). Na koniec sprowadza się do analizy kosztów i korzyści naruszenia. Wdrażasz zabezpieczenia na podstawie wartości zabezpieczanych danych i ich wartości czasowej.

Ile kosztuje komuś hasło wydostające się na wolność? Jaki jest koszt personifikacji w danym systemie? Dla komputerów FBI koszt może być ogromny. W przypadku jednorazowej pięciostronicowej witryny Boba koszt może być znikomy. Specjalista zapewnia opcje dla swoich klientów, a jeśli chodzi o bezpieczeństwo, określa zalety i ryzyko związane z każdym wdrożeniem. Dzieje się tak podwójnie, jeśli klient żąda czegoś, co mogłoby narazić go na ryzyko z powodu nieprzestrzegania standardów branżowych. Jeśli klient specjalnie zażąda dwukierunkowego szyfrowania, upewnię się, że udokumentujesz swoje zastrzeżenia, ale nie powinno to powstrzymać Cię przed wdrożeniem w najlepszy znany Ci sposób. Ostatecznie są to pieniądze klienta. Tak,

Jeśli przechowujesz hasła z dwustronnym szyfrowaniem, bezpieczeństwo sprowadza się do zarządzania kluczami. System Windows zapewnia mechanizmy ograniczające dostęp do certyfikatów kluczy prywatnych do kont administracyjnych i haseł. Jeśli prowadzisz hosting na innych platformach, musisz sprawdzić, jakie opcje są dostępne na tych platformach. Jak sugerują inni, możesz użyć szyfrowania asymetrycznego.

Nie ma żadnego prawa (ani ustawy o ochronie danych w Wielkiej Brytanii), o której wiem, że wyraźnie stwierdza, że ​​hasła muszą być przechowywane przy użyciu skrótów jednokierunkowych. Jedynym wymaganiem w każdym z tych przepisów jest po prostu podjęcie rozsądnych kroków w celu zapewnienia bezpieczeństwa. Jeśli dostęp do bazy danych jest ograniczony, nawet hasła w postaci zwykłego tekstu mogą kwalifikować się zgodnie z takim ograniczeniem.

Ujawnia to jednak jeszcze jeden aspekt: ​​pierwszeństwo prawne. Jeśli pierwszeństwo prawne sugeruje, że musisz używać skrótów jednokierunkowych, biorąc pod uwagę branżę, w której budowany jest twój system, to jest zupełnie inaczej. To amunicja, której używasz, aby przekonać swojego klienta. Pomijając to, najlepsza sugestia, aby zapewnić rozsądną ocenę ryzyka, udokumentować swoje zastrzeżenia i wdrożyć system w najbezpieczniejszy sposób, w jaki można spełnić wymagania klienta.

Uczyń odpowiedź na pytanie bezpieczeństwa użytkownika częścią klucza szyfrującego i nie przechowuj odpowiedzi na pytanie bezpieczeństwa jako zwykłego tekstu (zamiast tego hash)

Wdrożyłem systemy uwierzytelniania wieloskładnikowego dla życia, więc dla mnie naturalne jest myślenie, że możesz zresetować lub zrekonstruować hasło, jednocześnie tymczasowo używając jednego mniej czynnika do uwierzytelnienia użytkownika tylko dla przepływu pracy resetowania / odtwarzania. W szczególności zastosowanie OTP (haseł jednorazowych) jako niektórych dodatkowych czynników zmniejsza duże ryzyko, jeśli okno czasowe jest krótkie na sugerowany przepływ pracy. Wdrożyliśmy programowe generatory OTP dla smartfonów (które większość użytkowników nosi już przy sobie przez cały dzień) z wielkim sukcesem. Zanim pojawią się skargi na wtyczkę komercyjną, mówię o tym, że możemy zmniejszyć ryzyko związane z utrzymywaniem haseł w łatwy sposób do odzyskania lub zresetowania, gdy nie są one jedynym czynnikiem służącym do uwierzytelnienia użytkownika.

Przepraszamy, ale dopóki masz sposób na zdekodowanie hasła, nie ma mowy, aby było bezpieczne. Walcz gorzko, a jeśli przegrasz, CYA.

Właśnie natknąłem się na tę interesującą i gorącą dyskusję. Najbardziej zaskoczyło mnie jednak to, jak mało uwagi poświęcono następującemu podstawowemu pytaniu:

• Pytanie 1 Jakie są rzeczywiste powody, dla których użytkownik nalega na dostęp do hasła przechowywanego w postaci zwykłego tekstu? Dlaczego ma tak dużą wartość?

Informacja, że ​​użytkownicy są starsi lub młodzi, tak naprawdę nie odpowiada na to pytanie. Ale w jaki sposób można podjąć decyzję biznesową bez właściwego zrozumienia obaw klienta?

Dlaczego to ma znaczenie? Ponieważ jeśli prawdziwą przyczyną żądań klientów jest system, który jest boleśnie trudny w użyciu, to może zajęcie się dokładną przyczyną rozwiązałoby rzeczywisty problem?

Ponieważ nie mam tych informacji i nie mogę rozmawiać z tymi klientami, mogę tylko zgadywać: Chodzi o użyteczność, patrz wyżej.

Kolejne pytanie, które widziałem, zadało:

• Q2 Jeśli użytkownik nie pamięta hasła, dlaczego stare hasło ma znaczenie?

I oto możliwa odpowiedź. Jeśli masz kota o imieniu „miaumiau” i użyłeś jej imienia jako hasła, ale zapomniałeś, że tak, czy wolałbyś, aby przypominano mu o tym, czy raczej wysłano mu coś w rodzaju „# zy * RW (ew”?

Innym możliwym powodem jest to, że użytkownik uważa, że ​​wymyślenie nowego hasła jest ciężką pracą! Odesłanie starego hasła daje złudzenie, że ocali ją od tej bolesnej pracy.

Próbuję tylko zrozumieć przyczynę. Ale bez względu na przyczynę, należy zająć się przyczyną, a nie przyczyną.

Jako użytkownik chcę rzeczy proste! Nie chcę ciężko pracować!

Jeśli loguję się na stronie z wiadomościami, aby czytać gazety, chcę wpisać 1111 jako hasło i gotowe !!!

Wiem, że jest to niebezpieczne, ale co mnie obchodzi, czy ktoś uzyska dostęp do mojego „konta”? Tak, on też może przeczytać wiadomości!

Czy strona przechowuje moje „prywatne” informacje? Wiadomości, które dziś czytam? Więc to jest problem strony, nie moja! Czy strona wyświetla prywatne informacje uwierzytelnionemu użytkownikowi? Więc nie pokazuj tego na pierwszym miejscu!

Ma to na celu jedynie wykazanie stosunku użytkownika do problemu.

Podsumowując, nie wydaje mi się, aby problemem było „bezpieczne” przechowywanie haseł w postaci zwykłego tekstu (co, jak wiemy, jest niemożliwe), ale raczej sposób rozwiązania rzeczywistych obaw klientów.

Obsługa zgubionych / zapomnianych haseł:

Nikt nigdy nie powinien być w stanie odzyskać haseł.

Jeśli użytkownicy zapomnieli hasła, muszą przynajmniej znać swoje nazwy użytkowników lub adresy e-mail. Na żądanie wygeneruj identyfikator GUID w tabeli Użytkownicy i wyślij wiadomość e-mail zawierającą link zawierający identyfikator jako parametr na adres e-mail użytkownika.

Strona za linkiem weryfikuje, czy parametr guid naprawdę istnieje (prawdopodobnie z pewną logiką przekroczenia limitu czasu) i prosi użytkownika o nowe hasło.

Jeśli potrzebujesz pomocy dla użytkowników infolinii, dodaj niektóre role do swojego modelu grantu i pozwól roli infolinii tymczasowo zalogować się jako zidentyfikowany użytkownik. Zaloguj wszystkie takie loginy na infolinię. Na przykład Bugzilla oferuje administratorom taką funkcję personifikacji.

Co powiesz na przesłanie hasła w postaci zwykłego tekstu przy rejestracji, zanim zostanie ono zaszyfrowane i utracone? Widziałem, jak robi to wiele stron internetowych, a uzyskiwanie tego hasła z wiadomości e-mail użytkownika jest bezpieczniejsze niż pozostawienie go na serwerze / komputerze.

Jeśli nie możesz po prostu odrzucić wymogu przechowywania haseł do odzyskania, to co powiesz na ten argument jako swój argument.

Możemy odpowiednio zakodować hasła i zbudować mechanizm resetowania dla użytkowników, lub możemy usunąć wszystkie dane osobowe z systemu. Możesz użyć adresu e-mail, aby skonfigurować preferencje użytkownika, ale to wszystko. Użyj pliku cookie, aby automatycznie pobrać preferencje podczas przyszłych wizyt i wyrzucić dane po rozsądnym czasie.

Jedną z opcji często pomijanych w polityce haseł jest to, czy hasło jest naprawdę potrzebne. Jeśli jedyne, co robi polityka haseł, powoduje wywołania obsługi klienta, być może możesz się jej pozbyć.

Czy użytkownicy naprawdę muszą odzyskać (np. Powiedzieć im) hasło, które zapomnieli, czy po prostu muszą mieć dostęp do systemu? Jeśli naprawdę chcą hasła do zalogowania się, dlaczego nie skorzystać z procedury, która po prostu zmienia stare hasło (cokolwiek to jest) na nowe hasło, które osoba udzielająca wsparcia może przekazać osobie, która straciła hasło?

Pracowałem z systemami, które właśnie to robią. Pracownik pomocy technicznej nie ma możliwości dowiedzenia się, jakie jest bieżące hasło, ale może je zresetować do nowej wartości. Oczywiście wszystkie takie resetowania powinny być gdzieś zarejestrowane, a dobrą praktyką byłoby wygenerowanie wiadomości e-mail do użytkownika z informacją, że hasło zostało zresetowane.

Inną możliwością jest posiadanie dwóch równoczesnych haseł umożliwiających dostęp do konta. Jednym z nich jest „normalne” hasło, którym zarządza użytkownik, a drugie jest jak szkielet / klucz główny znany tylko pracownikom pomocy technicznej i taki sam dla wszystkich użytkowników. W ten sposób, gdy użytkownik ma problem, osoba wsparcia może zalogować się do konta za pomocą klucza głównego i pomóc użytkownikowi zmienić hasło na cokolwiek. Nie trzeba dodawać, że wszystkie logowania za pomocą klucza głównego również powinny być rejestrowane przez system. Jako dodatkowy środek, za każdym razem, gdy używany jest klucz główny, można również zweryfikować dane uwierzytelniające osób wspierających.

-EDIT- W odpowiedzi na komentarze o braku klucza głównego: Zgadzam się, że jest zły, tak jak uważam, że złym jest zezwolenie na dostęp do konta użytkownika każdemu innemu niż użytkownik. Jeśli spojrzysz na to pytanie, cała przesłanka jest taka, że ​​klient nakazał wysoce skompromitowane środowisko bezpieczeństwa.

Klucz główny nie musi być tak zły, jak mogłoby się wydawać. Kiedyś pracowałem w zakładzie obronnym, gdzie dostrzegali potrzebę, aby operator komputera mainframe miał przy niektórych okazjach „specjalny dostęp”. Po prostu włożyli specjalne hasło do zapieczętowanej koperty i przykleili je do pulpitu operatora. Aby użyć hasła (którego operator nie znał) musiał otworzyć kopertę. Przy każdej zmianie zmiany jednym z zadań kierownika zmiany było sprawdzenie, czy koperta została otwarta, a jeśli tak, to natychmiast zmień hasło (przez inny dział), a nowe hasło zostało umieszczone w nowej kopercie i proces rozpoczął się wszystkie jeszcze raz. Operator zostanie zapytany, dlaczego go otworzył, a incydent zostanie udokumentowany na potrzeby protokołu.

Chociaż nie jest to procedura, którą bym zaprojektował, zadziałała i zapewniła doskonałą rozliczalność. Wszystko zostało zarejestrowane i sprawdzone, a wszyscy operatorzy mieli tajne poświadczenia DOD i nigdy nie mieliśmy żadnych nadużyć.

Ze względu na przegląd i nadzór wszyscy operatorzy wiedzieli, że jeśli nadużyją przywileju otwierania koperty, zostaną natychmiast zwolnieni z pracy i możliwe postępowanie karne.

Sądzę więc, że prawdziwą odpowiedzią jest to, że jeśli chcemy robić dobrze, zatrudniamy ludzi, którym można zaufać, sprawdzają przeszłość i sprawują odpowiedni nadzór i odpowiedzialność kierownictwa.

Ale z drugiej strony, gdyby klient tego biednego faceta miał dobre zarządzanie, nie prosiliby o takie kompromisowe rozwiązanie bezpieczeństwa, prawda?

Z tego, co rozumiem na ten temat, uważam, że jeśli budujesz stronę internetową z loginem / hasłem, to w ogóle nie powinieneś widzieć hasła w postaci zwykłego tekstu na swoim serwerze. Hasło powinno zostać zaszyfrowane i prawdopodobnie solone, zanim jeszcze opuści klienta.

Jeśli nigdy nie widzisz hasła w postaci zwykłego tekstu, nie pojawia się pytanie o jego odzyskanie.

Ponadto zbieram (z sieci), że (rzekomo) niektóre algorytmy, takie jak MD5, nie są już uważane za bezpieczne. Nie jestem w stanie sam tego osądzić, ale warto o tym pomyśleć.

otwórz bazę danych na autonomicznym serwerze i zaszyfruj zdalne połączenie z każdym serwerem WWW, który wymaga tej funkcji.
nie musi to być relacyjna baza danych, może to być system plików z dostępem FTP, wykorzystujący foldery i pliki zamiast tabel i wierszy.
daj serwerom internetowym uprawnienia tylko do zapisu, jeśli możesz.

Przechowuj nieodzyskiwalne szyfrowanie hasła w bazie danych witryny (nazwijmy to „pass-a”), jak robią to zwykli ludzie :)
na każdym nowym użytkowniku (lub zmianie hasła) przechowuj zwykłą kopię hasła w zdalnej bazie danych. użyj identyfikatora serwera, identyfikatora użytkownika i „pass-a” jako klucza złożonego dla tego hasła. możesz nawet użyć dwukierunkowego szyfrowania hasła, aby lepiej spać w nocy.

teraz, aby ktoś mógł uzyskać zarówno hasło, jak i kontekst (identyfikator witryny + identyfikator użytkownika + „pass-a”), musi:

1. zhakuj bazę danych witryny, aby uzyskać parę („pass-a”, identyfikator użytkownika).
2. pobierz identyfikator strony z jakiegoś pliku konfiguracyjnego
3. znajdź i włam się do bazy zdalnych haseł DB.

możesz kontrolować dostępność usługi odzyskiwania haseł (udostępniaj ją tylko jako bezpieczną usługę internetową, zezwalaj tylko na określoną liczbę wyszukiwań haseł dziennie, rób to ręcznie itp.), a nawet naliczaj dodatkowe opłaty za to „specjalne uzgodnienie bezpieczeństwa”.
Serwer DB pobierania haseł jest dość ukryty, ponieważ nie spełnia wielu funkcji i można go lepiej zabezpieczyć (możesz ściśle dostosować uprawnienia, procesy i usługi).

Podsumowując, utrudniasz hakerowi pracę. szansa na naruszenie bezpieczeństwa na dowolnym pojedynczym serwerze jest nadal taka sama, ale znaczące dane (dopasowanie konta i hasła) będą trudne do zebrania.

Inną opcją, której mogłeś nie brać pod uwagę, jest umożliwienie działań za pośrednictwem poczty e-mail. Jest to trochę kłopotliwe, ale zaimplementowałem to dla klienta, który potrzebował użytkowników „poza” swoim systemem, aby zobaczyć (tylko do odczytu) niektóre części systemu. Na przykład:

1. Po zarejestrowaniu użytkownik ma pełny dostęp (jak zwykła strona internetowa). Rejestracja musi zawierać wiadomość e-mail.
2. Jeśli potrzebne są dane lub akcja, a użytkownik nie pamięta hasła, może wykonać tę czynność, klikając specjalny przycisk „ wyślij mi e-mailem o pozwolenie ”, tuż obok zwykłego przycisku „ prześlij ”.
3. Żądanie jest następnie wysyłane na adres e-mail z hiperłączem z pytaniem, czy chcą, aby akcja została wykonana. Jest to podobne do linku e-mail umożliwiającego zresetowanie hasła, ale zamiast resetowania hasła wykonuje jednorazową akcję .
4. Następnie użytkownik klika „Tak” i potwierdza, że ​​dane powinny zostać pokazane lub akcja powinna zostać wykonana, dane ujawnione itp.

Jak wspomniałeś w komentarzach, nie zadziała to, jeśli wiadomość e-mail zostanie naruszona, ale adresuje komentarz @joachim o tym, że nie chcesz resetować hasła. W końcu musieliby zresetować hasło, ale mogliby to zrobić w dogodniejszym czasie lub w razie potrzeby z pomocą administratora lub przyjaciela.

Zaletą tego rozwiązania byłoby wysłanie żądania działania do zaufanego administratora strony trzeciej. Najlepiej działałoby to w przypadku starszych, niepełnosprawnych umysłowo, bardzo młodych lub w inny sposób zdezorientowanych użytkowników. Oczywiście wymaga to zaufanego administratora, aby osoby te wspierały swoje działania.

Sól i hash hasło użytkownika jak zwykle. Podczas logowania użytkownika należy zezwolić zarówno na hasło użytkownika (po zasoleniu / haszowaniu), ale także na to, co wpisał użytkownik.

Pozwala to użytkownikowi na wprowadzenie swojego tajnego hasła, ale także pozwala mu wprowadzić wersję hasła w wersji solonej / zaszyfrowanej, którą ktoś odczyta z bazy danych.

Zasadniczo uczyń hasło solone / haszowane również hasłem „zwykłego tekstu”.