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.