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

1344

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.

Shane
źródło
155
Myślę, że on wie, że to nie jest dobre. Wciąż szuka najlepszego rozwiązania zgodnie z podanymi wymaganiami.
stefanw
33
Pod koniec dnia wszystko, co będziesz robić, to dokładnie wdrożyć lukę, której można uniknąć.
wieża
20
@Michael Brooks - Chcę, żebyś wiedział, że całkowicie zgadzam się z CWE-257 i chciałbym po prostu zacytować to dosłownie za każdym razem, gdy poproszę cię o odzyskanie haseł w postaci zwykłego tekstu. Jednak w rzeczywistości klienci i użytkownicy rzadko są zainteresowani przepisami NIST i po prostu chcą, żebym to zrobił. W 90% przypadków mogę ich przekonać inaczej, ale w tym 10% przypadków, gdy nie mogę, staram się ustalić najlepszy sposób działania - w takich przypadkach CWE-257 jest popiołem w mojej ręce (niestety).
Shane
81
@AviD: „Niska wartość” systemu absolutnie nie ma wpływu na ten problem, ponieważ ludzie ponownie używają swoich haseł . Dlaczego ludzie nie mogą zrozumieć tego prostego faktu? Jeśli złamiesz hasła w niektórych systemach o „niskiej wartości”, prawdopodobnie będziesz mieć kilka poprawnych haseł w innych systemach o „wysokiej wartości”.
Aaronaught
20
Przeanalizowano także inną kwestię, o której wspomniałem w strumieniu komentarzy do mojej odpowiedzi: Skąd wiesz, że osoba, która prosi o te wymagania, jest godna zaufania? Co jeśli wymówka „użyteczności” jest tylko fasadą maskującą prawdziwy zamiar kradzieży haseł w pewnym momencie w przyszłości? Twoja naiwność może kosztować miliony klientów i akcjonariuszy. Ile razy eksperci ds. Bezpieczeństwa muszą to powtarzać, zanim w końcu się zanurzy: Najczęstsze i najpoważniejsze zagrożenia bezpieczeństwa są zawsze WEWNĘTRZNE.
Aaronaught

Odpowiedzi:

1037

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.

Michael Burr
źródło
93
+1 dla haseł, które obecnie wydają się oferować najlepszą równowagę siły hasła i przywołania użytkownika.
Aaronaught
197
Możesz także zrobić pełne zdanie, np. <przymiotnik> <rzeczownik> to <przysłów> <przysłówek>. Zielony kot skacze dziko. mają listy dla kategorii. z 1024 wyborami dla każdego masz 40 bitów entropii.
Dominik Weber,
28
+1 za uznanie ponownego użycia hasła za kluczowy problem pozwalający go uniknąć
lurscher 13.10.10
57
„Pomyśl o tym - jeśli użytkownik musi odzyskać hasło, to dlatego, że je zapomniał” - niekoniecznie prawda! Często chcę dostać hasło, ponieważ jestem na laptopie i WIEM, że moje urządzenie w domu ma moje hasło zapisane lub jest zapisane w bezpiecznym miejscu i nie chcę tego łamać, otrzymując nowe .
joachim
5
Pytanie o najwyższym wyniku w nowej witrynie IT Security SE dotyczy ważności tego obliczenia entropii. (Cóż, technicznie rzecz biorąc, zajmuje się xkcd, który łączy @Pieter.)
Pops
592

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.

Aaronaught
źródło
124
@Aaronaught - Myślę, że to uczciwa i słuszna kwestia, ale pozwólcie, że zwrócę na was uwagę. Pracujesz nad projektem dla firmy jako pracownik, a twój szef mówi „to wymóg naszego systemu” (z dowolnego powodu). Czy odchodzisz z pracy pełnej prawego oburzenia? Wiem, że kiedy mam pełną kontrolę, istnieje obowiązek bycia odpowiedzialnym - ale jeśli firma zdecyduje się zaryzykować niepowodzenie audytu lub odpowiedzialność, to moim obowiązkiem jest poświęcenie mojej pracy, aby udowodnić swoją rację, czy też szukam NAJLEPSZEGO i BEZPIECZNY sposób na robienie tego, co mówią? Po prostu gra adwokata diabła ...
Shane
44
Nie jestem prawnikiem, ale zastanów się nad tym. Jeśli twój przełożony nakazuje ci zrobić coś wbrew interesom firmy, na przykład narażając je na łatwą do uniknięcia odpowiedzialność, czy Twoim zadaniem jest być posłusznym, czy grzecznie odmówić? Tak, są twoim szefem, ale mają własnego szefa, nawet jeśli to inwestorzy. Jeśli nie przejdziesz nad ich głowami, czyja głowa będzie się toczyć, gdy zostanie wykorzystana twoja dziura w zabezpieczeniach? Tylko coś do rozważenia.
Steven Sudit
68
Deweloperzy zawsze próbują powiedzieć, że nasze zadania są o wiele trudniejsze niż inne, ponieważ ciągle zmieniają się wymagania dotyczące śmieci. Cóż, to doskonały przykład dlaczego; nasz zawód rozpaczliwie potrzebuje kręgosłupa. Nasz zawód desperacko musi umieć powiedzieć „nie, to nie jest akceptowalny wymóg, nie jest to coś, co mogę rozwinąć w dobrej wierze, możesz być moim klientem / pracodawcą, ale mam obowiązki zawodowe wobec twoich klientów i społeczeństwa, a jeśli chcesz to zrobić, musisz szukać gdzie indziej. ”
Aaronaught
36
@sfussenegger: Nie musisz znać tła. To niedopuszczalne. Zakładasz, że klient jest w 100% godny zaufania - co zrobić, jeśli poprosi o ten wymóg, aby później mógł skorzystać z haseł? Bezpieczeństwo jest jednym z niewielu przedmiotów w fazie rozwoju, które wyryte w kamieniu. Jest kilka rzeczy, których po prostu nie robisz, a przechowywanie haseł, które można odzyskać, to dziesięć z nich.
Aaronaught
37
OK, zróbmy ocenę ryzyka, tu i teraz. „Jeśli przechowujesz hasła w formie umożliwiającej odzyskanie, stwarzasz niebanalne ryzyko kradzieży haseł. Jest również prawdopodobne, że przynajmniej niektórzy użytkownicy będą używać tych samych haseł do swoich kont e-mail i kont bankowych. W przypadku kradzieży haseł a konta bankowe są wyczerpane, prawdopodobnie pojawią się w nagłówkach, nikt już nigdy nie będzie z tobą współpracował i prawdopodobnie zostaniesz pozwany o nieistnienie ”. Czy możemy teraz wyciąć gówno? Fakt, że wprowadziłeś w to słowo „naziści”, wyraźnie pokazuje, że nie masz poczucia rozsądku.
Aaronaught
206

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).
Stefan
źródło
34
-1 hasła nigdy nie powinny być „szyfrowane” Jest to naruszenie CWE-257 cwe.mitre.org/data/definitions/257.html
wieża
100
1. Pytanie brzmiało, że hasło powinno być możliwe do odzyskania w postaci zwykłego tekstu, więc jest to wymóg. 2. Używam tutaj szyfrowania asymetrycznego, a nie szyfrowania symetrycznego. Klucz do odszyfrowania nie jest konieczny do codziennych operacji i można go przechowywać w sejfie bankowym. Argumentacja w łączu jest prawidłowa, ale nie dotyczy tej sytuacji.
stefanw
57
To prawda, ale czy mógłbyś się zgodzić, że biorąc pod uwagę wymagania, jest to najbardziej odpowiedzialny sposób? Możesz uderzać mnie cały dzień za pomocą CWE-257, nie zmieni to interesującego problemu bezpiecznego przechowywania i pracy z danymi uwierzytelniającymi oraz możliwości odzyskania ich do pierwotnej postaci, jeśli zajdzie taka potrzeba.
stefanw
10
Windows Recovery Agent jest również kiepskim przykładem, ponieważ dotyczy faktycznego szyfrowania, a nie zarządzania hasłami. Klucz szyfrowania to nie to samo co hasło; zasady i praktyki wokół nich są zupełnie inne. Szyfrowanie i uwierzytelnianie to nie to samo. Szyfrowanie służy ochronie prywatności - klucz służy do ochrony danych . Uwierzytelnianie dotyczy tożsamości , gdzie kluczem są dane (jest to jeden z czynników w procesie uwierzytelniania). Powtarzam więc, szyfrowanie i uwierzytelnianie to nie to samo. Nie możesz w sposób prawidłowy stosować zasad jednego do drugiego.
Aaronaught
16
+1 Po co obsesyjnie nalegać na CWE-257? To słabość (CWE), a nie podatność (CVE). Porównanie haseł do odzyskania z przepełnieniem bufora polega na porównaniu jabłek i pomarańczy. Po prostu upewnij się, że klient rozumie problem (pozwól mu podpisać coś, co tak mówi - w przeciwnym razie może nic nie zapamiętać) i kontynuuj. Ponadto wymagane środki bezpieczeństwa zależą od wartości systemu i potencjalnego ryzyka ataku. Jeśli skuteczny atakujący może anulować tylko niektóre subskrypcje biuletynu, nie ma powodu, aby kłócić się o jakiekolwiek problemy.
sfussenegger
133

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

użytkownik207421
źródło
2
Dzienniki serwera WWW nie liczą się w sądzie? Czy w tym przypadku będą również uważani za fałszywych?
Vinko Vrsalovic
10
@ Vinko Vrsalovic, dzienniki serwera WWW NIE POWINNY liczyć się w sądzie, aby to zrobić, musisz udowodnić niezaprzeczalność, dowód autentyczności, łańcuch dowodów itp., Których dzienniki serwera WWW wyraźnie nie są.
AviD
7
Dokładnie. Dostawca musi udowodnić, że tylko klient mógł dokonać tej transakcji. Dziennik serwera WWW tego nie robi.
user207421,
Można powiedzieć, że nie wszystkie hasła są faktycznie potrzebne do „transakcji”. Załóżmy, że witryna służy do opracowania listy zakładek na stronie. W takim przypadku limit odpowiedzialności (który jest zwykle określany w OWH podczas rejestracji na stronie internetowej) wynosi zero, ponieważ nie ma transakcji finansowej. Jeśli w witrynie nie ma żadnych działań wpływających na innych, dane zostają utracone przez zhakowanego użytkownika. Firma jest chroniona przez OWU.
Sablefoste,
1
@Sablefoste Na tej stronie internetowej. Jeśli użytkownik użyje tego samego hasła w innym miejscu, istnieje ryzyko wycieku jego prywatnych danych uwierzytelniających. Jeśli nigdy nie zaangażujesz się w praktykę, nie możesz spowodować problemu.
user207421,
94

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:

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.

jammycakes
źródło
8
@jimmycakes - Dobrze jest to zrobić w systemie o niskim poziomie bezpieczeństwa, ale jeśli przechowujesz jakiekolwiek dane o wysokiej wartości, musisz założyć, że e-mail osób jest już zagrożony i że wysłanie im bezpośredniego linku logowania zagraża Twojemu systemowi. +1 za odpowiedź na moje pytanie z wykonalną alternatywą, ale wskazując wadę logiki jako całości. Nie chcę, aby Payppal wysyłał bezpośredni link do logowania NIGDY. Może to zabrzmieć paranoicznie, ale zawsze zakładam, że moje konto e-mail jest uszkodzone - to zapewnia mi uczciwość. ;)
Shane
Oczywiście - oczekiwałbym, że mój bank przynajmniej zadzwoni i zweryfikuje moją tożsamość, zanim pozwolę zresetować ( nie odzyskać) hasła. To, co tu nakreśliłem, to absolutny minimalny standard bezpieczeństwa hasła, którego oczekiwałbym od dowolnej witryny internetowej, gdziekolwiek.
jammycakes
1
Ignorowanie banku lub paypal, którzy i tak nie mieliby ograniczeń, które nałożyłeś; Jeśli uważasz, że ich e-mail jest zagrożony, w jaki sposób możliwa jest jakakolwiek metoda online? Jeśli prześlesz wygenerowane hasło w wiadomości e-mail, czy jest to bardziej bezpieczne?
Peter Coulton,
Nie mówię o uzyskaniu hasła pojedynczej osoby, mówię o uzyskaniu wielu haseł z bazy danych. Jeśli system przechowuje hasła do odzyskania jako zwykły tekst, haker może potencjalnie napisać skrypt, aby wyodrębnić wszystkie hasła z bazy danych.
jammycakes
Zastanawiam się nad wysłaniem linku / hasła w wiadomości e-mail, przejściu przez sieć w postaci zwykłej przez nieznane węzły sieciowe ...
Jakub
55

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

Mr. Boy
źródło
4
@ john - Myślę, że jest to całkowicie realne rozwiązanie. Przygotuj się jednak na rozpalenie wewnętrznych zagrożeń! Wiesz, jeśli miałbym to zrobić z pośrednim resetowaniem hasła (technika ustawia hasło ręcznie jako tymczasowy komunikat i mówi Mabel, aby wpisała 1234 jako hasło), to prawdopodobnie działałoby to dobrze w systemie niezawierającym ważnych danych. Gdyby było to środowisko o wysokim poziomie bezpieczeństwa, mamy problem z tym, że obsługa klienta może ustawić hasło CEO na 1234 i zalogować się bezpośrednio. Nie ma idealnego rozwiązania, ale to działa w wielu przypadkach. (+1)
Shane
5
Właśnie zauważyłem tę odpowiedź. @Shane, nie rozumiem, dlaczego przewidywałeś płonące „wewnętrzne zagrożenia”. Możliwość zmiany hasła nie jest zauważalną słabością; Problemem jest możliwość znalezienia hasła, które prawdopodobnie będzie używane w innych usługach - w jej e-mailu, banku i witrynach sklepów internetowych, w których przechowywane są informacje CC. Ta słabość nie objawia się tutaj; jeśli Bob zresetuje hasło Mabel i przekaże jej to przez telefon, nie da mu to dostępu do żadnego z jej innych kont. Chciałbym jednak wymusić zamiast „sugerować” resetowanie hasła przy logowaniu.
Aaronaught
@Aaronaught - Rozumiem twój punkt widzenia, ale myślę o czasach, w których nawet pracownicy obsługi klienta są zablokowani w niektórych obszarach systemu (takich jak listy płac, księgowość itp.), A umożliwienie im bezpośredniego ustawienia hasła to kwestia bezpieczeństwa sama w sobie. Rozumiem jednak, że rodzaj systemu, o który zadałem to pytanie, różni się w dużej mierze od wewnętrznego systemu rachunkowości. Prawdopodobnie moglibyśmy przeprowadzić zupełnie inną dyskusję na temat zastrzeżonych systemów wewnętrznych i bezpieczeństwa haseł.
Shane
1
@Shane: Zatem pytanie ma jeszcze mniej sensu. Zakładałem, że chcesz, aby ktoś odczytał im hasło przez telefon. Jeśli chcesz przesłać użytkownikom hasła za pośrednictwem automatycznego systemu samoobsługowego, równie dobrze możesz zrezygnować z hasła, ponieważ jest ono „chronione” czymś znacznie słabszym. Być może musisz sprecyzować dokładnie, jakie scenariusze użyteczności próbujesz wesprzeć. Być może ta analiza pokaże następnie, że hasła, które można odzyskać, nie są nawet konieczne.
Aaronaught
4
Kod podany przez osobę obsługującą nie musi być dosłownie nowym hasłem. Może to być tylko jednorazowy kod, który odblokowuje funkcję resetowania hasła.
kgilpin 18.09.13
42

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!

Phil H.
źródło
8
I oczywiście możesz użyć dowolnej techniki podziału tajemnic, aby wymagać od kogoś wielu osób do odszyfrowania. Ale żadna z tych rzeczy nie spełnia pierwotnych wymagań, aby móc wysłać użytkownikowi hasło, lub poprowadzić go przez poplecznika pierwszego poziomu, który poprowadzi go przez logowanie.
Christopher Creutzig
27

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ę.
Jakub
źródło
Odpowiedziałem na komentarze tutaj, w mojej odpowiedzi, ponieważ były one dość długie - myślę, że ważne jest, aby przeanalizować analizę i dyskusję na poruszone kwestie. stackoverflow.com/questions/2283937/…
AviD
Czy użytkownik korzysta z wyświetlania hasła na ekranie? Moim zdaniem - zdecydowanie tak! Za każdym razem, gdy dostaję niejasne hasło z Internetu, dziękuję Apple, że mogę je pokazać, aby nie musieć wpisywać go 100 razy z bólu. Mogę sobie wyobrazić, jak czułaby się osoba niepełnosprawna.
Dmitri Zaitsev
1
Dlaczego wyświetlanie niejasnego hasła jest lepsze niż wybór nowego hasła, które możesz zapamiętać?
Jacob
@Jacob: Więcej entropii?
Alexander Shcheblikin
25

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.

Zachłanny
źródło
5
Hasła dzielone między Twoją witryną o niskiej wartości bez „drogich” aktywów a Facebook / GMail / twoim bankiem drogim zasobem, nawet w witrynach o niskiej wartości.
jammycakes
3
Myślę, że problem polega na tym, że wyżej wymienione grupy użytkowników używają tego samego hasła do wszystkich aplikacji z wielu różnych poziomów bezpieczeństwa (od bankowości po blogi z przepisami). Pytanie zatem brzmi, czy to na deweloperze spoczywa obowiązek ochrony użytkowników nawet przed sobą. Zdecydowanie powiedziałbym: tak!
ercan
7
Przykro mi, ale sama tożsamość jest zasobem o wysokiej wartości, kropką. Bez wyjątków, bez wymówek. Bez względu na to, jak niewielka i nieistotna jest Twoja witryna. Wspólne hasło to tożsamość, jeśli pozwala hakerowi na konta użytkowników na Facebooku, konta Gmail, konta bankowe itp. Nie ma to nic wspólnego z semantyką, ale wszystko ma związek z konsekwencjami. Zapytaj każdego, kto został dotknięty atakiem hakera, takiego jak ten: theregister.co.uk/2009/08/24/4chan_pwns_christians
jammycakes
2
@Jacob, w jakim świecie zostałby pozwany Twój klient, ponieważ konta Ermy w innych systemach zostały przejęte? Nawet biorąc pod uwagę rażące zaniedbanie ze strony klienta (które NIE jest oczywiste, jak to rozwinąłem), I PODKREŚLA fakt, że NIE MA ŻADNEGO sposobu udowodnienia, że ​​inny system został naruszony z powodu twojego, nie ma żadnej możliwości prawnej zgłaszać roszczenia odszkodowawcze z jednego systemu w drugim systemie. Zostałby wyrzucony z sądu z uprzedzeniem, a powód uznałby go za pogardę. Erma może jednak ponosić winę za naruszenie licznych warunków świadczenia usług ...
AviD
5
@Jacob, to bardzo źle. Tylko dlatego, że hasło jest takie samo (co w oczywisty sposób naruszyłoby Twoje Warunki świadczenia usług i ich zasady bezpieczeństwa), ich legitymacja nie ma mocy prawnej, by je skorelować. UWAŻA nawet, że DOWODZENIE byłoby prawie niemożliwe. Na marginesie podkreślę również, że NIE MA PRAWA, które wymagałoby, aby przypadkowa firma nie stosowała luźnych praktyk bezpieczeństwa, chyba że istotne są określone przepisy. Co więcej, hasła SĄ szyfrowane (!), Więc luźność daleka jest od zapomnienia.
AviD,
21

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

Oded
źródło
Wiesz, użyłem tego w kilku sytuacjach (zwykle jest to mój środek), ale kazałem ludziom powiedzieć, że użytkownik końcowy po prostu nie uzyska interakcji i że wsparcie musi być w stanie „powiedzieć im hasło „z powodu okoliczności w tym modelu biznesowym”. Zgadzam się jednak, że w miarę możliwości jest to lepsze.
Shane
Zawsze możesz opowiedzieć swojemu klientowi o ryzyku, że jego DB wpadnie w złe ręce i zdobędzie rozgłos skradzionych haseł ... Istnieje wiele przykładów.
Oded
6
Poproś ich o podpisanie się pod „projektem” z dodatkową klauzulą, że nie mogą cię pozwać, jeśli to, o czym ich ostrzegałeś, rzeczywiście się wydarzy ... Przynajmniej wtedy się okryjesz.
Oded
4
-1 hasła nigdy nie powinny być „szyfrowane” Jest to naruszenie CWE-257 cwe.mitre.org/data/definitions/257.html
wieża
34
@Michael Brooks: Nie ma potrzeby, aby głosować i kopiować i wklejać ten sam komentarz w kółko; wszyscy wiemy, że to zła praktyka. Shane stwierdził, że brakuje mu jednak dźwigni w tej sprawie, dlatego proponowane są kolejne najlepsze rzeczy.
Johannes Gorset
13

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ąć.

Nicholas Shanks
źródło
5
Większość użytkowników nie ma klucza PGP (nadal go nie mam; po 20 latach w branży nigdy nie czułem takiej potrzeby) i uzyskanie go nie jest bezproblemowe. Ponadto klucz prywatny jest tak naprawdę tylko proxy rzeczywistego hasła. Innymi słowy, jest to hasło do hasła; żółwie do samego końca.
Robert Harvey
1
@RobertHarvey Celem jest umożliwienie użytkownikowi odzyskania hasła bez umożliwienia dostępu do niego pracownikom witryny lub hakerom. Wymagając, aby proces pobierania miał miejsce na komputerze użytkownika, wymuszasz to. Mogą istnieć alternatywy dla PGP, które mogłyby osiągnąć to samo. Żółwie mogą być w dół (być może niektóre słonie po drodze), ale nie widzę innego wyjścia. Dla ogólnej populacji (która prawdopodobnie nie będzie celem indywidualnym) posiadanie haseł na kawałku papieru i niemożność odzyskania ich z usługi byłoby bezpieczniejsze niż obecnie
Nicholas Shanks,
Podoba mi się, ponieważ zmusza wszystkich do posiadania klucza publicznego PGP, co, co dziwne, jest bardzo etyczne.
Lodewijk,
możesz po prostu wygenerować jeden i przekazać go użytkownikowi.
My1
@RobertHarvey Być może masz rację, że nie jest to „proces bez tarcia”, ale może to być dodatkowa usługa dla zaawansowanych użytkowników, którą zwykli użytkownicy mogą zignorować. Jeśli chodzi o argument dotyczący tego, że PK jest „hasłem do hasła”, pamiętaj, że teoretycznie może tak być w przypadku wielu haseł; możesz użyć różnych haseł dla różnych usług i zaszyfrować je wszystkie przy użyciu tego samego klucza. Wtedy PK będzie cenniejsze niż tylko jedno hasło. Być może jest to abstrakcyjny sposób porównywalny z menedżerem haseł (?). Nie od razu wiadomo mi, jakie to może mieć konsekwencje ...
Kjartan,
12

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

z-boss
źródło
4
@ sneg - Cóż, jestem wściekle przekonującym facetem, ale czasami jest szefem, a czasem klientem, więc nie zawsze mam siłę, którą muszę przekonać w taki czy inny sposób. Będę jeszcze ćwiczyć w lustrze ..;)
Shane
Aby być przekonującym, tak naprawdę nie potrzebujesz żadnej dźwigni innej niż kompetencje i umiejętności komunikacyjne. Jeśli znasz lepszy sposób na zrobienie czegoś, ale ludzie nie słuchają ... Pomyśl o tym.
z-boss
7
@ z-boss - Najwyraźniej nie pracowałeś z / dla niektórych twardych głów, z którymi miałem przyjemność pracować. Czasami nie ma znaczenia, czy Twój język jest pokryty złotem i możesz przeprogramować Google Chrome w ciągu jednego dnia (co prawdopodobnie może być przydatne), nadal nie drgną.
Shane
11

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)
  • 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).

Daniel Loureiro
źródło
9

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.

Tomasz
źródło
10
Twoja odpowiedź całkowicie ignoruje to, że hasła są ponownie wykorzystywane w wielu witrynach / usługach, co jest kluczowe w tym temacie i sam powód, dla którego hasła do odzyskania są uważane za poważną słabość. Specjalista ds. Bezpieczeństwa nie przekazuje decyzji dotyczących bezpieczeństwa klientowi nietechnicznemu; profesjonalista wie, że jego obowiązki wykraczają poza płacącego klienta i nie oferuje opcji o wysokim ryzyku i zerowej nagrody. -1 za rant ciężką retoryką i wyjątkowo lekką na fakty - i za to, że tak naprawdę nie odpowiada na pytanie.
Aaronaught
4
Ponownie całkowicie pomijasz ocenę ryzyka. Aby użyć argumentu, nie możesz zatrzymać się na hashach jednokierunkowych. Musisz także uwzględnić wymagania dotyczące złożoności, długości haseł, ograniczeń związanych z ponownym użyciem hasła i tak dalej. Argumentowanie, że użytkownicy będą używać głupich haseł lub ponowne używanie haseł, nie jest wystarczającym uzasadnieniem biznesowym, jeśli system jest nieistotny i szczerze mówiąc, odpowiedziałem na pytanie. Krótka odpowiedź: nalegaj na użycie standardowej implementacji, udokumentuj swoje zastrzeżenia, jeśli zostaniesz unieważniony i przejdź dalej.
Thomas
7
I ponownie powtarzasz kanon, że nic z tego nie ma znaczenia dla systemu o niskiej wartości! Wartość hasła użytkownika nie ma nic wspólnego z wartością konta użytkownika w systemie. To tajemnica , którą musisz zawsze zachować. Chciałbym móc podać kolejne -1 za komentarz wskazujący, że nadal nie rozumiesz tutaj problemów.
Aaronaught
5
Podstawową kwestią jest ocena ryzyka. Ponowne użycie hasła to tylko jeden potencjalny problem w znacznie większym zestawie problemów. Dlaczego nie wymagać breloków? Dlaczego nie wymagać, aby osoba jechała do biura, aby się zalogować? Bez rozsądnej oceny ryzyka nie ma sposobu, aby odpowiedzieć na te pytania. W twoim świecie wszystko jest ryzykowne, więc każdy system wymaga bezpieczeństwa logowania na poziomie FBI. Po prostu nie tak działa prawdziwy świat.
Thomas
7
Jedyną rzeczą, która jest tutaj jasna, jest to, że cały twój argument jest niczym innym jak błędem Slippery Slope i że próbujesz parować czytelników modnymi słowami, takimi jak „ocena ryzyka”, aby ukryć ten fakt. Zapewniamy, że każdy system używany przez „FBI” będzie znacznie bezpieczniejszy niż skrót bcrypt i minimalna długość hasła. Jeśli wymaganie standardowych systemów uwierzytelniania czyni mnie „fanatykiem bezpieczeństwa”, to chyba jestem fanatykiem; osobiście boli mnie świadomość, że są ludzie gotowi poświęcić MOJE bezpieczeństwo dla pieniędzy. To jest nieetyczne .
Aaronaught
8

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)

Rob Fonseca-Ensor
źródło
Użytkownik może również inaczej odpowiedzieć na pytanie. Niektóre pytania wymagają dłuższych odpowiedzi, które później łatwo sformułować.
Monoman,
5
Pytania bezpieczeństwa to zły pomysł. Jak sprawić, by mama zmieniła nazwisko panieńskie po naruszeniu informacji? Zobacz także: Inżynieria bezpieczeństwa Petera Gutmanna .
jww
7

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.

Monoman
źródło
Tymczasowe usunięcie czynnika z systemu uwierzytelniania wieloskładnikowego jest rzeczywiście o wiele bezpieczniejszym sposobem resetowania hasła niż irytujące systemy „tajnych pytań” widoczne na tak wielu stronach. Ale jeśli chodzi o przechowywanie haseł w formacie możliwym do odzyskania, nie jestem pewien, jak to pomaga, chyba że w jakiś sposób używasz drugiego czynnika do szyfrowania lub zaciemniania pierwszego, i nie jestem pewien, jak to możliwe z czymś takim jak SecurID. Możesz wytłumaczyć?
Aaronaught
@Aaronaught To, co powiedziałem, to to, że jeśli jesteś „zobowiązany” do odzyskania haseł, nieodłączne ryzyko jest niższe, jeśli nie jest to jedyny czynnik uwierzytelnienia, a dla użytkownika końcowego jest łatwiejsze, jeśli przepływy pracy wykorzystają czynniki, które on / ona już posiada i ma bieżący dostęp, zamiast próbować zapamiętać prawdopodobnie również zapomniane „tajne odpowiedzi” lub używając ograniczonych czasowo łączy lub tymczasowych haseł, oba przesyłane niebezpiecznymi kanałami (chyba że używasz S-MIME z certyfikatami klienta lub PGP, zarówno ponoszące koszty, szczególnie związane z zarządzaniem prawidłowym stowarzyszeniem oraz wygaśnięciem /
zamianą
1
Przypuszczam, że wszystko to prawda, ale ryzyko publicznego kompromisu jest na początku minimalne; poważniejszym problemem związanym z odzyskiwanymi hasłami jest bezpieczeństwo wewnętrzne i potencjalnie pozwalający niezadowolonemu pracownikowi odejść z hasłami e-mailowymi tysięcy klientów lub przekręconym dyrektorem generalnym, aby sprzedać je phisherom i spamerom. Uwierzytelnianie dwuskładnikowe doskonale sprawdza się w zwalczaniu kradzieży tożsamości i zgadywania haseł, ale tak naprawdę nie wnosi zbyt wiele do tabeli, jeśli chodzi o bezpieczeństwo bazy danych haseł.
Aaronaught 18.10.10
5

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.

Steven Sudit
źródło
5

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.

Dmitri Zaitsev
źródło
4

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.

devio
źródło
GUID to zły pomysł, niezbyt przypadkowy i łatwy do brutalnego użycia. są z tym inne problemy, patrz stackoverflow.com/questions/664673/…
AviD
3

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.

casraf
źródło
Nie przypuszczam, że e-mail jest bezpieczniejszy niż jakikolwiek inny system. Mimo że nie ma to dla mnie wątpliwości prawnej, nadal istnieje problem, że ktoś zgubił / usunął swój e-mail, a teraz wracam do sedna sprawy.
Shane
Podaj zarówno reset hasła, jak i wyślij e-mailem hasło w postaci zwykłego tekstu. Myślę, że to najwięcej, co możesz zrobić na ten temat, bez samodzielnego przechowywania kopii hasła.
casraf
To absolutnie okropny pomysł. Jest to zarówno nieefektywne (wielu użytkowników faktycznie usuwa wiadomości e-mail po przeczytaniu), jak i gorzej niż przed tym, przed czym próbujesz chronić (ponieważ e-mail jest domyślnie nieszyfrowany i przechodzi przez niewiarygodne sieci). Lepiej zasugerować użytkownikowi, że sami zanotują hasło, przynajmniej wysyłając sobie wiadomość e-mail, informacja nigdy nie idzie dalej niż serwer e-mail, nie przez cały Internet!
Ben Voigt,
3

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

anopres
źródło
Tak długo, jak masz adres e-mail powiązany z hasłem, a hasło to można odzyskać, potencjalnie wyciekałeś hasło dla tego adresu e-mail z powodu ponownego użycia hasła. To właściwie główna sprawa tutaj. Tak naprawdę nie ma żadnych innych danych umożliwiających identyfikację.
Aaronaught
1
Całkowicie przegapiłeś mój punkt. Jeśli tak naprawdę nie potrzebujesz hasła, nie odbieraj go. Programiści często utknęli w trybie myślenia „tak właśnie to robimy”. Czasami pomaga wyrzucić z góry założone pojęcia.
anopres
2

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?

JonnyBoats
źródło
Klucz główny byłby bardzo ryzykowny, pracownicy pomocy technicznej mieliby dostęp do każdego konta - a kiedy przekażesz ten klucz użytkownikowi, będzie on miał klucz główny i dostęp do wszystkiego.
Carson Myers
Klucz główny to okropny pomysł, ponieważ jeśli ktoś go odkryje (lub zostanie mu przypadkowo ujawniony), może go wykorzystać. Ponieważ mechanizm resetowania hasła do konta jest zdecydowanie preferowany.
Phil Miller
Jestem ciekawy, myślałem, że Linux ma domyślnie konto superużytkownika z dostępem do poziomu root? Czy to nie jest „klucz główny”, aby uzyskać dostęp do wszystkich plików w systemie?
JonnyBoats
@JonnyBoats Tak, to prawda. Właśnie dlatego współczesne systemy Unix, takie jak Mac OS X, wyłączają konto root.
Nicholas Shanks
@NicholasShanks: Wyłączyć konto root, czy deaktywować logowanie interaktywne na koncie root? Nadal działa dużo kodu z nieograniczonymi uprawnieniami.
Ben Voigt,
2

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

Jeremy C.
źródło
1

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.

Amir Arad
źródło
3
Jeśli serwer aplikacji może uzyskać do niego dostęp, może to zrobić każdy, kto ma dostęp do serwera aplikacji (haker lub złośliwy informator). Daje to zerowe dodatkowe bezpieczeństwo.
molf
1
Dodatkowym zabezpieczeniem jest to, że DB serwera aplikacji nie przechowuje haseł (więc potrzebny jest drugi hack - do haseł DB), a DB haseł może lepiej chronić przed nieregularnymi działaniami, ponieważ kontrolujesz dostępność usługi odzyskiwania haseł. dzięki czemu możesz wykrywać zbiorcze pobieranie danych, zmieniać klucz SSH pobierania co tydzień, a nawet nie zezwalać na automatyczne pobieranie danych i robić to wszystko ręcznie. To rozwiązanie pasuje również do każdego innego wewnętrznego schematu szyfrowania (takiego jak klucze publiczne + prywatne, sól itp.) Dla hasła DB.
Amir Arad,
1

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.

Sablefoste
źródło
1

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

Eliott
źródło
Jak myślisz, dlaczego konieczne jest porównanie tego, co użytkownik wprowadził bezpośrednio do zaszyfrowanego hasła przechowywanego w bazie danych? Jaką funkcjonalność to daje? Poza tym niezwykle ważne jest zastosowanie funkcji porównywania w czasie stałym między hasłem wprowadzonym przez użytkownika a hasłem z bazy danych. W przeciwnym razie ustalenie zaszyfrowanego hasła na podstawie różnic czasowych jest prawie banalnie możliwe.
Artjom B.,
1
@ArtjomB. Pytanie dotyczy sposobu ochrony hasła użytkownika, umożliwiając jednocześnie obsługę klienta (CS) rozmowę / wysłanie e-maila do użytkownika poprzez wprowadzenie zapomnianego hasła. Umożliwiając użytkowanie wersji z haszowaniem jako hasła w postaci zwykłego tekstu, CS może ją odczytać, a użytkownik może użyć jej zamiast zapomnianego hasła. CS może również użyć go do zalogowania się jako użytkownik i pomocy w wykonaniu zadania. Umożliwia to również ochronę użytkowników, którzy czują się komfortowo z automatycznymi systemami zapomnianego hasła, ponieważ hasło, które wprowadzają i używają, jest haszowane.
Eliott
Widzę. Nie przeczytałem pytania w całości. Nadal konieczne jest porównywanie w czasie stałym, aby zapobiec trywialnemu uszkodzeniu całego systemu.
Artjom B.