Jak etycznie podejść do przechowywania haseł użytkowników w celu późniejszego wyszukiwania zwykłego tekstu?

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

Architekt: do budynku tej wielkości i pojemności potrzebne będą wyjścia przeciwpożarowe tutaj, tutaj i tutaj.
Klient: nie, to zbyt skomplikowane i drogie w utrzymaniu, nie chcę żadnych bocznych ani tylnych drzwi.
Architekt: Sir, wyjścia przeciwpożarowe nie są opcjonalne, są wymagane zgodnie z pożarem miasta kod.
Klient: nie płacę ci za kłótnie. Rób, o co prosiłem.

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

W branży budowlanej i inżynieryjnej rozmowa najprawdopodobniej zakończy się tak:

Architekt: ten budynek nie może być zbudowany bez wyjść przeciwpożarowych. Możesz udać się do dowolnego innego licencjonowanego specjalisty, a on powie Ci to samo. Odchodzę, Oddzwoń. kiedy będziesz gotowy do współpracy.

Programowanie komputerowe może nie być licencjonowanym zawodem, ale ludzie często zastanawiają się, dlaczego nasz zawód nie cieszy się takim samym szacunkiem jak Inżynier budownictwa czy mechanik - cóż, nie szukaj dalej. Te zawody, kiedy wręczone śmieci (lub wręcz niebezpieczne) wymagania, po prostu odmówić. Wiedzą, że nie jest to wymówka, aby powiedzieć: "Cóż, zrobiłem, co w mojej mocy, ale on nalegał i muszę zrobić to, co mówi."Mogą stracić licencję na ta wymówka.

Nie wiem, czy ty lub twoi klienci jesteście częścią jakiejkolwiek spółki giełdowej, ale przechowywanie haseł w dowolnej formie, którą można odzyskać, spowodowałoby, że zawiedziesz kilka różnych rodzajów audytów bezpieczeństwa. Problemem nie jest to, jak trudne byłoby dla jakiegoś "hakera", który uzyskał dostęp do twojej bazy danych, aby odzyskać hasła. Zdecydowana większość zagrożeń bezpieczeństwa ma charakter wewnętrzny. to, przed czym musisz się chronić, to jakiś niezadowolony pracownik wychodzący ze wszystkimi hasła i sprzedając je temu, kto da najwięcej. Użycie asymetrycznego szyfrowania i przechowywanie klucza prywatnego w oddzielnej bazie danych nie ma absolutnie nic, aby zapobiec temu scenariuszowi; zawsze znajdzie się ktoś z dostępem do prywatnej bazy danych, a to poważne zagrożenie bezpieczeństwa.

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

Możesz zaszyfrować hasło + sól kluczem publicznym. Dla loginów wystarczy sprawdzić, czy zapisana wartość jest równa wartości obliczonej z wejścia użytkownika + salt. Jeśli nadejdzie 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 dodatkowo może być szyfrowany symetrycznie (co będzie wymagało interakcji człowieka, aby odszyfrować hasło).

Myślę, że to w rzeczywistości jest podobny do sposobu działania Windows Recovery Agent .

• hasła są przechowywane zaszyfrowane
• ludzie mogą się zalogować bez odszyfrowywania do zwykłego tekstu
• hasła można odzyskać za pomocą zwykłego tekstu, 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ć, by przekonać swoich klientów, jest nie do odrzucenia. Jeśli możesz zrekonstruować hasła użytkowników za pomocą dowolnego mechanizmu, dałeś Ich klientom prawny mechanizm nie odrzucania i mogą oni odrzucić każdą transakcję, która zależy od tego hasła, ponieważ nie ma możliwości, aby dostawca udowodnił, że nie zrekonstruował hasła i nie przeprowadził transakcji przez siebie. Jeśli hasła są poprawnie zapisywane jako digesty, a nie zaszyfrowane, to jest to niemożliwe, ergo albo klient końcowy zrealizował transakcję samodzielnie lub naruszył swój obowiązek opieki w. R. T. hasło. W obu przypadkach, to pozostawia odpowiedzialność prosto z nim. Pracowałem nad sprawami, w których kosztowałoby to setki milionów dolarów. Nie chcesz się pomylić.

Nie można etycznie przechowywać haseł do późniejszego wyszukiwania zwykłego tekstu. To takie proste. Nawet Jon Skeet nie może etycznie przechowywać haseł do późniejszego wyszukiwania zwykłego tekstu. Jeśli użytkownicy mogą odzyskać hasła w zwykłym tekście w jakiś sposób lub w inny sposób, potencjalnie również może haker, który znajdzie lukę w zabezpieczeniach w Twoim kodzie. I to nie tylko hasło jednego użytkownika jest zagrożone, ale Wszystkie.

Jeśli twoi klienci mają z tym problem, powiedz im, że przechowywanie odzyskiwanie haseł jest niezgodne z prawem. W każdym razie w Wielkiej Brytanii Ustawa o ochronie danych z 1998 r. (w szczególności Załącznik 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ą być spowodowane w przypadku naruszenia danych-co może być znaczne dla użytkowników, którzy dzielą hasła między stronami. Jeśli nadal mają problem z wyjaśnieniem, że to problem, wskaż im do niektórych przykładów z prawdziwego świata, takich jak Ten.

Najprostszym sposobem, aby umożliwić użytkownikom odzyskanie loginu, jest wysłanie e-maila z jednorazowym linkiem, który automatycznie loguje je i przenosi bezpośrednio na stronę, na której mogą wybrać nowe hasło. Stwórz prototyp i pokaż mu go w akcji.

Oto kilka wpisów na blogu, które napisałem na 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ć pozwy sądowe i oskarżenia przeciwko firmom, które nie zabezpieczają poprawnie haseł swoich użytkowników. Przykład: LinkedIn; Sony grzywna £250,000 za włamanie do danych PlayStation . Jeśli dobrze pamiętam, LinkedIn faktycznie szyfrował hasła swoich użytkowników, ale szyfrowanie, którego używał, było zbyt słabe, aby było skuteczne.

Po przeczytaniu tej części:

W notce poniżej zaznaczam, że strony internetowe nastawione głównie na osoby w podeszłym wieku, upośledzone umysłowo lub bardzo młodzi mogą stać się zagmatwani dla ludzi gdy zostaną poproszeni o wykonanie procedura bezpiecznego odzyskiwania hasła. Choć możemy uznać to za proste i przyziemne w takich przypadkach niektórzy użytkownicy potrzebują dodatkowa pomoc albo o technik serwisowy pomaga im w system lub jego wysłanie/wyświetlenie bezpośrednio do nich.

W takich systemach współczynnik ścierania z tych danych demograficznych można aplikacji, jeśli użytkownicy nie byli biorąc pod uwagę ten poziom pomocy w dostępie, więc proszę o odpowiedź z takim ustawieniem w umysł.

Zastanawiam się, czy którekolwiek z tych wymagań wymaga systemu odzyskiwania haseł. Na przykład: Ciocia Mabel dzwoni i mówi: "Twój program internetowy nie działa, nie znam swojego hasła". "OK" mówi Drone obsługi klienta " pozwól mi sprawdzić kilka szczegółów, a następnie będę podaj nowe hasło. Podczas następnego logowania zapyta cię, czy chcesz zachować to hasło lub zmienić je na coś, co możesz łatwiej zapamiętać."

Następnie system jest skonfigurowany tak, aby wiedzieć, kiedy nastąpiło Resetowanie 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 PC, niż powiedzenie im starego hasła? I podczas gdy osoba obsługująca klienta może dojść do zgorszenia, baza danych sama w sobie jest znacznie bezpieczniejsza w przypadku jej naruszenia.

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

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

1. Zaszyfruj hasło za pomocą cudzy klucz publiczny - jakiś zewnętrzny autorytet. W ten sposób nie można go zrekonstruować osobiście, a użytkownik będzie musiał udać się do tego zewnętrznego organu i poprosić o odzyskanie hasła.
2. Zaszyfruj hasło za pomocą wygenerowanego klucza z drugiego hasła. Wykonaj to szyfrowanie po stronie klienta i nigdy nie przesyłaj go na serwer. Następnie, aby odzyskać, wykonaj ponownie odszyfrowywanie po stronie klienta, ponownie generując klucz z ich wejścia. Co prawda, w tym podejściu zasadniczo używa się drugiego hasła, ale zawsze możesz powiedzieć im, aby je zapisali, lub użyć starego podejścia do pytań bezpieczeństwa.

Myślę, że 1. jest lepszym wyborem, ponieważ pozwala wyznaczyć kogoś w firmie klienta do posiadania klucz prywatny. Upewnij się, że sami wygenerują klucz i przechowają go wraz z instrukcjami w sejfie itp. Możesz nawet dodać bezpieczeństwo, wybierając tylko szyfrowanie i dostarczanie pewnych znaków z hasła wewnętrznej stronie trzeciej, aby musieli złamać hasło, aby je odgadnąć. Dostarczając te znaki użytkownikowi, prawdopodobnie będą pamiętać, co to było!

W odpowiedzi na to pytanie było wiele dyskusji na temat bezpieczeństwa użytkownika, ale chciałbym dodać wzmiankę o korzyściach. Do tej pory nie widziałem ani jednej uzasadnionej korzyści , o której mowa w przypadku przechowywania hasła do odzyskania w systemie. Rozważ to:

• czy użytkownik korzysta z przesłania mu hasła pocztą elektroniczną? Nie. Zyskują więcej korzyści dzięki jednorazowemu linkowi do resetowania hasła, który, miejmy nadzieję, pozwoli im wybrać hasło oni będą pamiętać.
• czy użytkownik korzysta z wyświetlenia 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 obsługująca mówi do użytkownika hasło? Nie; ponownie, jeśli osoba obsługująca uzna żądanie użytkownika o jego hasło za prawidłowo uwierzytelnione, bardziej korzystne dla użytkownika jest nadanie nowego hasła i możliwość jego zmiany. Dodatkowo obsługa telefoniczna jest bardziej kosztowne niż automatyczne resetowanie haseł, więc firma również nie korzysta.

Wydaje się, że jedynymi, które mogą skorzystać z odzyskiwalnych haseł, są osoby o złośliwych intencjach lub zwolennicy słabych interfejsów API, które wymagają wymiany haseł przez osoby trzecie(proszę nie używać tych interfejsów nigdy!). Być może możesz wygrać swój argument, twierdząc szczerze swoim klientom, że firma nie zyskuje żadnych korzyści, a jedynie zobowiązania, przechowując odzyskiwalne hasła.

Czytanie między wierszami tego typu zapytań zobaczysz, że twoi klienci prawdopodobnie nie rozumieją, a nawet w ogóle nie dbają o to, jak zarządzane są hasła. Tak naprawdę chcą systemu uwierzytelniania , który nie jest tak trudny dla ich użytkowników. Więc oprócz mówienia im, że tak naprawdę nie chcą odzyskać haseł, powinieneś zaoferować im sposoby, aby proces uwierzytelniania był mniej bolesny, zwłaszcza jeśli nie potrzebujesz wysokiego poziomu bezpieczeństwa, powiedzmy, a bank:

• Pozwól użytkownikowi używać swojego adresu e-mail do nazwy użytkownika. Widziałem niezliczone przypadki, w których użytkownik zapomina swoją nazwę użytkownika, ale niewielu zapomina swojego adresu e-mail.
• zaoferuj OpenID i pozwól osobie trzeciej zapłacić za koszty zapomnienia użytkownika.
• Ogranicz ograniczenia haseł. Jestem pewien, że wszyscy byliśmy bardzo zirytowani, gdy jakaś strona internetowa nie zezwala na preferowane hasło z powodu bezużytecznych wymagań, takich jak "nie można używać znaków specjalnych" lub "Twoje hasło jest za długie" lub " Twoje hasło musi zaczynać się od litery."Ponadto, jeśli łatwość użycia jest większym problemem niż Siła hasła, możesz rozluźnić nawet nie głupie wymagania, zezwalając na krótsze hasła lub nie wymagając mieszanki klas znaków. Z poluzowanymi ograniczeniami użytkownicy będą częściej używać hasła, którego nie zapomną.
• nie wygasaj haseł.
• pozwala użytkownikowi na ponowne użycie starego hasła.
• pozwala użytkownikowi wybrać własne hasło zresetuj pytanie.

Ale jeśli z jakiegoś powodu (i podaj nam powód) naprawdę, naprawdę, naprawdę musisz mieć odzyskiwalne hasło, możesz uchronić użytkownika przed potencjalnym narażeniem innych kont online, dając mu System Uwierzytelniania bez hasła. Ponieważ ludzie są już zaznajomieni z systemami nazwy użytkownika/hasła i są dobrze wyćwiczonym rozwiązaniem, byłoby to ostateczność, ale na pewno jest wiele kreatywnych alternatywy dla haseł:

• Pozwól użytkownikowi wybrać numeryczny pin, najlepiej nie 4-cyfrowy i najlepiej tylko wtedy, gdy próby brute-force są chronione przed.
• niech użytkownik wybierze pytanie z krótką odpowiedzią, na które tylko On zna odpowiedź, nigdy się nie zmieni, zawsze będzie pamiętał i nie będzie miał nic przeciwko temu, aby inni się dowiedzieli.
• wprowadź nazwę Użytkownika, a następnie narysuj łatwy do zapamiętania kształt z wystarczającą liczbą permutacji, aby zabezpieczyć się przed zgadywaniem (zobacz to sprytne zdjęcie Jak G1 robi to, aby odblokować telefon).
• W przypadku strony internetowej dla dzieci, możesz automatycznie wygenerować rozmyte stworzenie na podstawie nazwy użytkownika (coś w rodzaju identyfikatora) i poprosić Użytkownika o nadanie stworowi tajnej nazwy. Następnie mogą zostać poproszeni o podanie tajnej nazwy stworzenia, aby się zalogować.

Na podstawie mojego komentarza do pytania:
Jeden ważny punkt został bardzo poruszony przez prawie wszystkich... Moja początkowa reakcja była bardzo podobna do @ Michael Brooks, dopóki nie zdałem sobie sprawy, jak @ stefanw ,że problem tutaj jest uszkodzony wymagania, ale są to, co są.
Ale potem okazało się, że to może nawet nie być przypadek! Brakującym punktem jest niewypowiedziana wartość aktywów aplikacji. Mówiąc najprościej, dla systemu o niskiej wartości, w pełni mechanizm bezpiecznego uwierzytelniania, z całym procesem zaangażowanym, byłby przesadą, a wybór niewłaściwy bezpieczeństwa.
Oczywiście dla banku "najlepsze praktyki" są koniecznością i nie ma sposobu, aby etycznie naruszyć CWE-257. Ale łatwo jest myśleć o systemach o niskiej wartości, w których po prostu nie warto (ale proste hasło jest nadal wymagane).

Ważne jest, aby pamiętać, że prawdziwe doświadczenie w zakresie bezpieczeństwa polega na znalezieniu odpowiednich kompromisów, a nie na dogmatycznym wypowiadaniu " najlepszych Praktyki", które każdy może przeczytać w Internecie.

Jako takie proponuję inne rozwiązanie:
W zależności od wartości systemu, i tylko wtedy, gdy system jest odpowiednio niska wartość bez "drogich" aktywów (tożsamość, w tym), i istnieją ważne wymagania biznesowe, które sprawiają, że właściwy proces niemożliwe (lub wystarczająco trudne / drogie), i klient jest świadomy wszystkich zastrzeżeń...
Wtedy może być właściwe, aby po prostu pozwolić odwracalne szyfrowanie, bez specjalnych obręczy do przeskoczenia.
Zatrzymuję się po prostu mówiąc, aby w ogóle nie przejmować się szyfrowaniem, ponieważ jest to bardzo proste/tanie w implementacji (nawet biorąc pod uwagę zarządzanie kluczami passible) i zapewnia pewną ochronę (więcej niż koszt wdrożenia). Ponadto warto przyjrzeć się, jak podać użytkownikowi oryginalne hasło, czy to poprzez e-mail, wyświetlanie na ekranie, itp.
Ponieważ założenie tutaj jest takie, że wartość skradzionego hasło (nawet zbiorcze) jest dość niskie, każde z tych rozwiązań może być poprawne.

Ponieważ toczy się ożywiona dyskusja, właściwie kilka ożywionych dyskusji, w różnych postach i osobnych wątkach komentarzy, dodam kilka wyjaśnień i odpowiem na niektóre z bardzo dobrych punktów, które zostały podniesione gdzie indziej tutaj.

Na początek myślę, że dla wszystkich jest jasne, że umożliwienie odzyskania oryginalnego hasła użytkownika jest złą praktyką i ogólnie To Nie Jest Dobry Pomysł. To nie jest w ogóle przedmiotem sporu...
Co więcej, podkreślę, że w wielu, nie większości, sytuacjach - to naprawdę złe, nawet obrzydliwe, paskudne i brzydkie .

Jednak sedno pytania jest wokół Zasady, czy jest jakaś sytuacja, w której zabranianie tego może nie być konieczne, a jeśli tak, to jak to zrobić w sposób najbardziej odpowiedni do sytuacji .

Teraz, jako @ Thomas, @ sfussenegger i kilka innych jedynym właściwym sposobem na odpowiedź na to pytanie jest przeprowadzenie dokładnej analizy ryzyka danej (lub hipotetycznej) sytuacji, aby zrozumieć, jaka jest stawka, ile warto chronić i jakie inne ograniczenia są w grze, aby sobie na nią pozwolić.
Nie, to nie jest hasło, jest to jedno z podstawowych, najważniejszych narzędzi dla profesjonalisty ds. bezpieczeństwa na żywo. Najlepsze praktyki są dobre do pewnego momentu (zwykle jako wytyczne dla niedoświadczonych i hakerów), po tym punktowa analiza ryzyka przejmuje kontrolę.

No wiesz, to zabawne - zawsze uważałem się za jednego z fanatyków bezpieczeństwa i jakoś jestem po przeciwnej stronie tych tak zwanych "ekspertów od bezpieczeństwa"... Cóż, prawda jest taka-ponieważ jestem fanatykiem i prawdziwym ekspertem od bezpieczeństwa-nie wierzę w głoszenie dogmatów "najlepszych praktyk" (lub CWEs) bez tej najważniejszej analizy ryzyka {4]}.
"Uważaj na fanatyka bezpieczeństwa, który szybko stosuje wszystko, co znajduje się w pasie narzędziowym nie wiedząc, przed czym się bronią. Większe bezpieczeństwo niekoniecznie oznacza dobre bezpieczeństwo."
Analiza ryzyka i prawdziwi fanatycy bezpieczeństwa wskazywałyby na mądrzejszy kompromis oparty na wartości/ryzyku, oparty na ryzyku, potencjalnych stratach, możliwych zagrożeniach, uzupełniających ograniczeniach itp. Każdy "ekspert ds. bezpieczeństwa", który nie może wskazywać na solidną analizę ryzyka jako podstawę swoich zaleceń lub popierać logicznych kompromisów, zamiast tego wolałby wylewać dogmaty i CWEs nawet nie rozumiejąc, jak przeprowadzić analizę ryzyka, są niczym innym jak włamaniami do zabezpieczeń, a ich wiedza nie jest warta papieru toaletowego, na którym ją wydrukowali.

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

Ale zanim porozmawiamy o odpowiednich kompromisach do dokonania w tej sytuacji, przyjrzyjmy się pozornemu ryzyku (pozornemu, ponieważ nie mamy wszystkich podstawowych informacji na temat tej sytuacji, wszyscy stawiamy hipotezę-ponieważ pytanie, jaka może być hipotetyczna sytuacja...)
Załóżmy, że system o niskiej wartości, ale nie tak trival, że jest to publiczny dostęp - właściciel systemu chce zapobiec przypadkowemu podszywaniu się, jednak "wysokie" bezpieczeństwo nie jest tak najważniejsze, jak łatwość obsługi. (Tak, jest to uzasadniony kompromis zaakceptować ryzyko, że każdy biegły skrypt-kiddie może zhakować stronę... Czekaj, to nie jest teraz modne...?)
Na przykład, powiedzmy, że organizuję prostą stronę dla dużego spotkania rodzinnego, pozwalając wszyscy do burzy mózgów na temat tego, gdzie chcemy pojechać na nasz camping w tym roku. Mniej martwi mnie jakiś anonimowy haker, a nawet kuzyn Fred wciskający powtarzające się sugestie, aby wrócić do jeziora Wantanamanabikiliki, ponieważ chodzi mi o to, że ciocia Erma nie może się zalogować, kiedy musi. Ciocia Erma, jako fizyk jądrowy, nie jest zbyt dobra w zapamiętywaniu haseł, ani w ogóle w używaniu komputerów... Więc chcę usunąć wszelkie możliwe dla niej tarcia. Ponownie, nie martwię się o hacki, I po prostu nie chcę głupich błędów błędnego logowania-chcę wiedzieć, kto nadchodzi, i co chcą.

W każdym razie.
Jakie są więc nasze główne zagrożenia, jeśli symetrycznie szyfrujemy hasła,zamiast używać jednokierunkowego skrótu?

• Podszywanie się pod użytkowników? Nie, już zaakceptowałem to ryzyko, Nie interesujące.
Zły administrator? Może... Ale znowu, nie obchodzi mnie, czy ktoś może podszywać się pod innego użytkownika, wewnętrznego lub nie... i tak złośliwy admin dostanie Twoje hasło bez względu na to co - Jeśli twój admin się zepsuł, i tak się skończy.
• Kolejną kwestią, która została podniesiona, jest to, że tożsamość jest faktycznie dzielona między kilka systemów. Ah! Jest to bardzo interesujące ryzyko, które wymaga bliższego przyjrzenia się.
  Pozwól, że zacznę od stwierdzenia, że nie jest to prawdziwa tożsamość , która jest wspólna, a raczej dowód , lub poświadczenie uwierzytelnienia. Dobrze, ponieważ współdzielone hasło pozwoli mi skutecznie wejść do innego systemu (powiedzmy, moje konto bankowe lub gmail), to faktycznie ta sama tożsamość, więc to tylko semantyka... Poza tym, że to nie . Tożsamość jest zarządzana oddzielnie przez każdy system, w tym scenariuszu (choć mogą istnieć systemy identyfikacyjne osób trzecich, takie jak OAuth-nadal, jego oddzielny 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 (to samo) hasło do kilku różnych systemów - a teraz ja (administrator) lub jakikolwiek inny haker z mojej strony będzie miał dostęp do haseł cioci Ermy do strony z pociskami nuklearnymi.

Hmmm.

Czy coś tu wydaje ci się dziwne?

Powinno.

Zacznijmy od tego, że ochrona systemu rakiet nuklearnych nie jest moją odpowiedzialnością, po prostu buduję miejsce wycieczek dla rodziny (dla mojej rodziny). Więc czyja to odpowiedzialność? Umm... A co z systemem rakiet nuklearnych? Duh.
Po drugie, gdybym chciał ukraść czyjeś hasło (ktoś, kto jest znany z wielokrotnego używania tego samego hasła między bezpiecznymi witrynami, a nie tak bezpiecznymi)-dlaczego miałbym zawracać sobie głowę hakowaniem Twojej witryny? Czy zmagasz się z szyfrowaniem symetrycznym? Goshdarnitall, mogę po prostu umieścić moja własna prosta strona , aby użytkownicy zarejestrowali się, aby otrzymywać bardzo ważne wiadomości o czym chcą... Puffo Presto, ukradłem im hasła.

Yes, user education always come back to bite us in the Henie, NO nie?
Oraz nic na to nie poradzisz... Nawet jeśli miałbyś hashować ich hasła w swojej witrynie i robić wszystko inne, co może wymyślić TSA, dodałeś ochronę do ich hasła , a nie jeden odrobinkę, jeśli mają zamiar rozwiązująco trzymać swoje hasła w każdej witrynie, na którą wpadną. Nawet nie próbuj.

Ująć inaczej, nie posiadasz ich haseł, więc przestań się tak zachowywać.

Więc, moi drodzy eksperci od bezpieczeństwa, jako stary pani pytała Wendy: "gdzie jest ryzyko?"

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

CWE nie jest ani prawem, ani rozporządzeniem, ani nawet standardem. Jest to zbiór wspólnych słabości , czyli odwrotność "najlepszych praktyk".
• kwestia wspólnej tożsamości jest faktycznym problemem, ale niezrozumianym (lub błędnie przedstawianym) przez przeciwnych tutaj. Jest to kwestia dzielenia się tożsamością samą w sobie(!), Nie o łamaniu hasła w systemach o niskiej wartości. Jeśli udostępniasz hasło między systemem o niskiej wartości a systemem o wysokiej wartości, problem już istnieje!
• By The by, poprzedni punkt faktycznie wskazuje przeciwko za pomocą OAuth i tym podobne zarówno dla tych systemów o niskiej wartości, jak i systemów bankowych o wysokiej wartości.
Wiem, że to był tylko przykład, ale (niestety) systemy FBI nie są tak naprawdę najlepiej zabezpieczone. Nie całkiem jak serwery twojego Kociego bloga, ale nie przewyższają one niektórych bezpieczniejsze banki.
• Dzielona wiedza, lub podwójna kontrola, kluczy szyfrujących nie dzieje się tylko w wojsku, w rzeczywistości PCI-DSS teraz wymaga {[6] } to od praktycznie wszystkich sprzedawców, więc tak naprawdę nie jest już tak daleko (jeśli wartość go uzasadnia).
• do wszystkich tych, którzy narzekają, że takie pytania sprawiają, że zawód programisty wygląda tak źle: to odpowiedzi takie, które sprawiają, że zawód bezpieczeństwa wygląda jeszcze gorzej. Ponownie, skoncentrowany na biznesie analiza ryzyka jest tym, co jest wymagane, w przeciwnym razie robisz się bezużyteczny. Poza tym, że się mylę.
• myślę, że to dlatego nie jest dobrym pomysłem, aby po prostu wziąć zwykłego dewelopera 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 - ale więcej szkolenia jest w porządku.

Uff. Co za długi post...
Ale odpowiadając na twoje oryginalne pytanie, @ Shane:

• wyjaśnij klientowi, jak należy postępować.
Jeśli nadal nalega, wyjaśnij coś więcej, nalegaj, argumentuj. W razie potrzeby złościć się. Wyjaśnij mu ryzyko biznesowe. Szczegóły są dobre, liczby są lepsze, demo na żywo jest zwykle najlepsze.
• jeśli nadal upiera się i przedstawia ważne powody biznesowe - nadszedł czas, aby wykonać wyrok:
  Czy ta strona jest niskowartościowa? Czy to naprawdę ważny przypadek biznesowy? Wystarczy Ci? Są nie ma innych zagrożeń, które można rozważyć, które przeważają ważnych powodów biznesowych? (I oczywiście, czy klient nie jest złośliwa strona, ale to duh).
  Jeśli tak, to śmiało. Nie warto wysiłku, tarcia i utraconego użycia (w tej hipotetycznej sytuacji), aby wprowadzić niezbędny proces. Każda inna decyzja (ponownie, w tej sytuacji) jest złym wyborem.

Więc, podsumowując, i rzeczywista odpowiedź-Zaszyfruj ją prostym algorytmem symetrycznym, Chroń klucz szyfrujący z silnymi ACLs i najlepiej DPAPI lub tym podobne, udokumentuj go i poproś klienta (kogoś na tyle starszego, aby podjął tę decyzję), aby się na nim podpisał.

A co powiesz na ośrodek wczasowy?

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

Zamiast resetowania haseł, Pozwól na wysłanie hasła jednorazowego (które musi zostać zmienione zaraz po pierwszym zalogowaniu). Pozwól użytkownikowi zmienić na dowolne hasło, które chce (poprzednie, jeśli wybierze).

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

Jedynym sposobem, aby umożliwić użytkownikowi odzyskanie oryginalnego hasła, jest zaszyfrowanie go za pomocą własnego klucza publicznego użytkownika. tylko ten użytkownik może odszyfrować swoje hasło.

Więc kroki będą:

1. Użytkownik rejestruje się na twojej stronie (oczywiście przez SSL) bez ustawiania hasła. Zaloguj się automatycznie lub podaj tymczasowe hasło.
2. oferujesz przechowywanie ich publicznego klucza PGP do przyszłego wyszukiwania haseł.
3. wgrywają swoje publiczne PGP klucz.
4. prosisz ich o ustawienie nowego hasła.
Zgłaszają swoje hasło.
5. hashujesz hasło za pomocą najlepszego dostępnego algorytmu hashowania haseł (np. bcrypt). Użyj tego podczas sprawdzania następnego logowania.
Zaszyfrowujesz hasło kluczem publicznym i przechowujesz je osobno.

Jeśli użytkownik poprosi o swoje hasło, odpowiadasz zaszyfrowanym (nie zahaszowanym) hasłem. Jeżeli użytkownik nie chce odzyskać swojego hasła w przyszłości (będą mogli go tylko zresetować do wygenerowanej usługi), kroki 3 i 7 można pominąć.

Myślę, że prawdziwym pytaniem, które powinieneś sobie zadać, jest: "jak Mogę być lepszy w przekonywaniu ludzi?'

Mam ten sam problem. I w ten sam sposób zawsze myślę, że ktoś włamać mój system to nie jest kwestia "czy", ale "kiedy".

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

• encrypt with: openssl_encrypt (string $data, string $metoda, string $hasło)
  • Instrukcja PHP .
• data arg :
  • the informacje wrażliwe (np. hasło użytkownika)
  • serializuj w razie potrzeby, np. jeśli informacja jest tablicą danych, takich jak wiele poufnych informacji
• password arg : Użyj informacji, które tylko użytkownik zna jak:
  • Tablica rejestracyjna Użytkownika
  • numer ubezpieczenia społecznego
  • numer telefonu użytkownika
  • Nazwa użytkownika
  • losowy ciąg wysyłany e-mailem i/lub sms-em przy rejestracji CZAS
• metoda arg :
  • Wybierz jedną metodę szyfrowania, jak "aes-256-cbc"
• nigdy nie przechowuj informacji użytych w argumencie "password" w bazie danych (lub w dowolnym miejscu w systemie)

Jeśli jest to konieczne, aby pobrać te dane, po prostu użyj funkcji" openssl_decrypt () " i poproś 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 chcesz 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 znać kogoś spoza rodziny.

PS 2: W przypadku informacji o karcie kredytowej, takich jak "one click buying", używam hasła logowania. To hasło jest hashowane w bazie danych (sha1, md5, etc), ale podczas logowania zapisuję hasło w sesji lub w trwałe (np. w pamięci) bezpieczne pliki cookie. To proste hasło nigdy nie pozostaje w bazie danych, w rzeczywistości zawsze pozostaje w pamięci, zniszczone na końcu sekcji. Po kliknięciu przez użytkownika przycisku "one click buying" system używa tego hasła. Facebook, Facebook, twitter, itp., a następnie monit hasło ponownie w czasie zakupu (ok, to nie jest w pełni "na kliknięcie") lub następnie użyć niektórych danych z usługi, że użytkownik używany do logowania (jak facebook id).

Zabezpieczenie poświadczeń nie jest operacją binarną: secure/not secure. Bezpieczeństwo polega na ocenie ryzyka i jest mierzone w kontinuum. Fanatycy bezpieczeństwa nie lubią myśleć w ten sposób, ale Brzydka prawda jest taka, że nic nie jest idealnie bezpieczne. Hashowane hasła o rygorystycznych wymaganiach dotyczących haseł, próbki DNA i skany siatkówki są bezpieczniejsze, ale kosztem rozwoju i doświadczenia użytkownika. Hasła tekstowe są znacznie mniej bezpieczne, ale są tańsze w implementacji (ale należy ich unikać). Na końcu dzień, sprowadza się do analizy kosztów / korzyści naruszenia. Wdrażasz zabezpieczenia w oparciu o wartość zabezpieczanych danych i ich wartość czasową.

Jaki jest koszt wydostania się czyjegoś hasła na wolność? Jaki jest koszt podszywania się pod dany system? Dla komputerów FBI koszt może być ogromny. Do jednorazowej pięciostronicowej strony internetowej Boba koszt może być znikomy. Profesjonalista zapewnia swoim klientom opcje, a jeśli chodzi o bezpieczeństwo, określa korzyści i zagrożenia związane z każdym wdrożeniem. Jest to podwójnie więc, jeśli klient żąda czegoś, co mogłoby narazić go na ryzyko z powodu nieprzestrzegania standardów branżowych. Jeśli Klient wyraźnie żąda dwukierunkowego szyfrowania, upewnię się, że udokumentujesz swoje zastrzeżenia, ale to nie powinno powstrzymać cię od wdrożenia w najlepszy znany sposób. W końcu to pieniądze klienta. Tak, należy naciskać na używanie jednokierunkowych hashów, ale powiedzieć, że jest to absolutnie jedyny wybór i cokolwiek inaczej jest nieetyczne to zupełny nonsens.

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

Nie ma prawa (ani ustawy o ochronie danych w Wielkiej Brytanii), z których jestem świadomy, że wyraźnie stwierdza, że hasła muszą być przechowywane za pomocą jednokierunkowych skrótów. Jedynym wymogiem w którymkolwiek z tych ustaw jest po prostu to, że rozsądne podejmowane są kroki w celu zapewnienia bezpieczeństwa. Jeśli dostęp do bazy danych jest ograniczony, nawet hasła ze zwykłym tekstem mogą być prawnie objęte takim ograniczeniem.

To jednak ujawnia jeszcze jeden aspekt: precedens prawny. Jeśli precedens prawny sugeruje, że musisz używać jednokierunkowych skrótów, biorąc pod uwagę branżę w którym budowany jest Twój system, to jest zupełnie inaczej. To amunicja, której używasz, by przekonać klienta. Poza tym, najlepsza sugestia, aby zapewnić rozsądną ocenę ryzyka, udokumentować swoje zastrzeżenia i wdrożyć system w najbardziej bezpieczny sposób można biorąc pod uwagę wymagania klienta.

Niech odpowiedź na pytanie zabezpieczające użytkownika będzie częścią klucza szyfrowania i nie przechowuj odpowiedzi na pytanie zabezpieczające jako zwykły tekst (hash that)

Na co dzień wdrażam systemy uwierzytelniania wieloczynnikowego, więc dla mnie naturalne jest myślenie, że można zresetować lub zrekonstruować hasło, tymczasowo używając jednego czynnika mniej do uwierzytelnienia użytkownika tylko dla obiegu pracy zresetowania/rekreacji. W szczególności wykorzystanie OTP (haseł jednorazowych) jako niektórych dodatkowych czynników zmniejsza duże ryzyko, jeśli okno czasowe jest krótkie dla sugerowanego przepływu pracy. Wdrożyliśmy oprogramowanie generatorów OTP dla smartfonów (które większość użytkowników nosi już ze sobą cały dzień) z wielkim sukcesem. Zanim pojawią się skargi na komercyjną wtyczkę, mówię, że możemy obniżyć ryzyko związane z utrzymywaniem haseł łatwo odzyskiwalnych lub resetowalnych, gdy nie są one jedynym czynnikiem używanym do uwierzytelniania użytkownika. Przyznaję, że w przypadku ponownego użycia hasła wśród scenariuszy witryn sytuacja nadal nie jest ładna, ponieważ użytkownik będzie nalegał, aby mieć oryginalne hasło, ponieważ chce otworzyć inne strony, ale ty może próbować dostarczyć zrekonstruowane hasło w możliwie najbezpieczniejszy sposób (htpps i dyskretny wygląd w html).

Przykro mi, ale dopóki masz jakiś sposób na odszyfrowanie ich hasła, nie ma możliwości, aby było bezpieczne. Walcz z tym gorzko, a jeśli przegrasz, CYA.

Właśnie natknąłem się na tę ciekawą i gorącą dyskusję. Najbardziej zaskoczyło mnie jednak to, jak mało uwagi poświęcono Następującemu zasadniczemu pytaniu: {]}

• Q1. Jakie są rzeczywiste powody, dla których użytkownik nalega na dostęp do zwykłego hasła tekstowego? Dlaczego ma taką wartość?

Informacja, że użytkownicy są starsi lub młodsi, tak naprawdę nie odpowiada na to pytanie. Ale jak można podjąć decyzję biznesową bez właściwego zrozumienia klienta troska?

Dlaczego to ma znaczenie? Bo jeśli prawdziwą przyczyną żądania klientów jest system, który jest boleśnie trudny w użyciu, To może rozwiązanie dokładnej przyczyny 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 jakie widziałem:

• Q2. Jeśli użytkownik nie pamięta hasła w pierwszej kolejności, dlaczego stare hasło Materia?

I tu jest możliwa odpowiedź. Jeśli masz kota o imieniu "miaumiau" i użyłeś jej imienia jako hasła, ale zapomniałeś, że to zrobiłeś, czy wolisz, aby przypominano ci, co to było, czy raczej wysyłano coś w stylu "#zy*RW(ew"?

Innym możliwym powodem jest to, że użytkownik uważa, że wymyślenie nowego hasła to ciężka praca! Więc odesłanie starego hasła daje iluzję uratowania jej od tej bolesnej pracy.

Próbuję zrozumieć powód. Ale bez względu na powód, to jest powód, a nie przyczyna, którą należy się zająć.

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

Jeśli loguję się do serwisu informacyjnego, aby czytać gazety, chcę wpisać 1111 jako hasło i być przez!!!

Wiem, że to niebezpieczne, ale co mnie obchodzi, że ktoś dostanie dostęp do mojego "konta"? Tak, on też może czytać wiadomości!

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

Jest to tylko po to, aby zademonstrować stosunek użytkownika do problemu.

Podsumowując, nie uważam, że jest to problem, jak "bezpiecznie" przechowywać hasła tekstowe (co, jak wiemy, jest niemożliwe), ale raczej jak odpowiedzieć na rzeczywiste obawy klientów.

Obsługa utraconych/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 GUID w tabeli użytkowników i wyślij wiadomość e-mail zawierającą link zawierający guid jako parametr na adres e-mail użytkownika.

Strona za linkiem sprawdza, czy parametr guid naprawdę istnieje (prawdopodobnie z logiką timeout) i prosi użytkownika o nowe hasło.

Jeśli chcesz mieć użytkowników pomocy infolinii, dodaj kilka ról do swojego modelu grantów i pozwól roli infolinii tymczasowo zalogować się jako zidentyfikowany użytkownik. Zaloguj się na wszystkie takie infolinie. Na przykład, Bugzilla oferuje taką funkcję podszywania się administratorom.

A co z wysłaniem hasła ze zwykłym tekstem po rejestracji, zanim zostanie zaszyfrowane i utracone? Widziałem wiele stron internetowych to robi, i uzyskanie tego hasła z wiadomości e-mail użytkownika jest bezpieczniejsze niż pozostawienie go na serwerze/komp.

Jeśli nie możesz po prostu odrzucić wymogu przechowywania odzyskiwalnych haseł, to może to być twój kontrargument.

Możemy albo poprawnie hashować hasła i zbudować mechanizm resetowania dla użytkowników, albo 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 dotyczące przyszłych wizyt i wyrzucić dane po rozsądnym okresie.

The jedną z opcji, która jest często pomijana w Polityce haseł, jest to, czy hasło jest naprawdę potrzebne. Jeśli jedyną rzeczą, którą robi twoja polityka haseł, jest spowodowanie połączeń z obsługą klienta, być może możesz się jej pozbyć.

Czy użytkownicy Naprawdę muszą odzyskać (np. zostać poinformowani) jakie hasło zapomnieli, czy po prostu muszą być w stanie dostać się do systemu? Jeśli tak naprawdę chcą hasła do logowania, dlaczego nie mieć procedury, która po prostu zmienia stare hasło (cokolwiek to jest) na nowe hasło, które osoba wspierająca może dać osobie, która zgubiła hasło?

Pracowałem z systemami, które robią dokładnie to. Osoba wspierająca nie ma możliwości poznania, co obecnie hasło jest, ale można go zresetować do nowej wartości. Oczywiście wszystkie takie resety powinny być gdzieś zalogowane i dobrą praktyką byłoby wygenerowanie e-maila do użytkownika z informacją, że hasło zostało zresetowane.

Inną możliwością jest posiadanie dwóch jednoczesnych haseł umożliwiających dostęp do konta. Jednym z nich jest "normalne" hasło, którym zarządza użytkownik, a drugi jest jak szkielet / klucz główny, który jest znany tylko przez personel pomocniczy i jest taki sam dla wszystkich użytkowników. W ten sposób, gdy użytkownik ma problem osoba obsługująca może zalogować się na konto 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 powinny być również rejestrowane przez system. Jako dodatkowy środek, za każdym razem, gdy używany jest klucz główny, możesz również zweryfikować poświadczenia osób wspierających.

- EDIT-w odpowiedzi na komentarze o braku klucza głównego: zgadzam się, że jest źle, tak jak uważam, że jest źle, aby ktokolwiek inny niż użytkownik miał dostęp do konta użytkownika. Jeśli spojrzeć na pytanie, Cała przesłanka jest taka, że klient zlecił wysoce zagrożone środowisko bezpieczeństwa.

Klucz główny nie musi być tak zły, jak mogłoby się początkowo wydawać. Kiedyś pracowałem w zakładzie obronnym, gdzie dostrzegali potrzebę, aby operator komputera mainframe miał" specjalny dostęp " przy pewnych okazjach. Po prostu włożyli specjalne hasło do zapieczętowanej koperty i przykleili je do biurka operatora. Aby użyć hasła (które operator nie wiedział) musiał otworzyć kopertę. Przy każdej zmianie zmiany jednym z zadań przełożonego zmiany było sprawdzenie, czy koperta została otwarta, a jeśli tak, natychmiast zmieniono hasło (przez inny dział), a nowe hasło zostało umieszczone w nowej kopercie i proces rozpoczął się od nowa. Operator będzie przesłuchiwany, dlaczego go otworzył, a incydent zostanie udokumentowany.

Chociaż nie jest to procedura, którą bym zaprojektowała, zadziałała i zapewnia doskonałą odpowiedzialność. Wszystko było rejestrowane i sprawdzane, Plus wszyscy operatorzy mieli tajne zezwolenia DOD i nigdy nie mieliśmy żadnych nadużyć.

Ze względu na kontrolę i nadzór, wszyscy operatorzy wiedzieli, że jeśli nadużywają przywileju otwarcia koperty, podlegają natychmiastowemu zwolnieniu i ewentualnemu ściganiu karnemu.

Więc myślę, że prawdziwa odpowiedź jest taka, że jeśli ktoś chce zrobić wszystko dobrze, zatrudnia ludzi, którym można zaufać, sprawdza przeszłość i sprawowanie właściwego nadzoru i odpowiedzialności za zarządzanie.

Ale z drugiej strony, gdyby klient tego biedaka miał dobre zarządzanie, nie prosiliby o takie rozwiązanie, prawda?

Z tego, co rozumiem na ten temat, uważam, że jeśli budujesz stronę internetową z sygnałem/hasłem, to nawet nie powinieneś widzieć hasła ze zwykłym tekstem na swoim serwerze. Hasło powinno zostać zahaszowane i prawdopodobnie zasolone, zanim w ogóle opuści klienta.

Jeśli nigdy nie widzisz hasła ze zwykłym tekstem, nie pojawia się kwestia pobierania.

Również wnioskuję (z sieci), że (rzekomo) niektóre algorytmy takie jak MD5 nie są już uważane za bezpieczne. Nie mam sposobu, aby to ocenić, ale jest to coś do rozważenia.

Otwórz DB na samodzielnym serwerze i daj zaszyfrowane zdalne połączenie z każdym serwerem internetowym, który wymaga tej funkcji.
nie musi to być relacyjny DB, 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 nieusuwalne szyfrowanie hasła w DB strony (nazwijmy to "pass-a"), jak robią to normalni ludzie:)
na każdego nowego Użytkownika (lub hasło Zmień) przechowuj zwykłą kopię hasła w zdalnym DB. użyj ID serwera, ID 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ś dostał zarówno hasło, jak i kontekst (site id + user id + "pass-a"), musi:

1. zhakuj dB strony, aby uzyskać ("pass-a", user id ) parę lub pary.
2. Pobierz identyfikator strony z jakiegoś config plik
3. znajdź i zhakuj zdalne hasła DB.

Możesz kontrolować dostępność usługi wyszukiwania haseł (wystawiać ją tylko jako zabezpieczoną usługę internetową, zezwalać tylko na pewną ilość haseł dziennie, robić to ręcznie itp.), a nawet dodatkowe opłaty za ten "specjalny układ bezpieczeństwa".
Serwer DB odzyskiwania haseł jest dość Ukryty, ponieważ nie spełnia wielu funkcji i może być lepiej zabezpieczony (można dostosować uprawnienia, procesy i usług).

W sumie, utrudniasz pracę hakerowi. szansa na naruszenie bezpieczeństwa na jednym serwerze jest nadal taka sama, ale istotne dane (dopasowanie konta i hasła) będą trudne do zebrania.

Inną opcją, której możesz nie brać pod uwagę, jest zezwalanie na działania 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 przeglądać (tylko do odczytu) pewne części systemu. Na przykład:

1. Po zarejestrowaniu się użytkownik ma pełny dostęp (jak zwykły strona internetowa). Rejestracja musi zawierać e-mail.
2. Jeśli potrzebne są dane lub akcja, a użytkownik nie zapamiętać swoje hasło, nadal mogą wykonać akcję przez kliknięcie specjalnego przycisku" napisz do mnie o pozwolenie ", tuż obok zwykłego przycisku" submit ".
3. żądanie jest następnie wysyłane na e-mail z hiperłączem z pytaniem, czy dana akcja ma zostać wykonana. Jest to podobne do linku resetowania hasła, ale zamiast resetowania hasła wykonuje jednorazową akcję .
4. Użytkownik następnie kliknie "tak" i potwierdza, że dane powinny być wyświetlane, lub akcja powinna być wykonana, dane ujawnione, itp.

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

Zwrotem w tym rozwiązaniu byłoby wysłanie żądania akcji do zaufanego administratora strony trzeciej. To najlepiej sprawdzi się w przypadki z osobami starszymi, upośledzonymi umysłowo, bardzo młodymi lub w inny sposób zdezorientowanymi użytkownikami. Oczywiście wymaga to zaufanego administratora, aby te osoby wspierały swoje działania.

Solić i hashować hasło użytkownika jak zwykle. Podczas logowania użytkownika, Zezwalaj zarówno na hasło użytkownika (po zasoleniu/hashowaniu), ale także Zezwalaj na to, co użytkownik dosłownie wprowadził, aby również pasowało.

To pozwala użytkownikowi wprowadzić swoje tajne hasło, ale także pozwala mu wprowadzić soloną / zahaszowaną wersję swojego hasła, czyli to, co ktoś odczytałby z bazy danych.

Zasadniczo, aby hasło solone/hashowane było również hasłem "zwykłym tekstem".