Co jeśli klient potrzebuje możliwości odzyskania haseł?

Obecnie odziedziczyłem aplikację w pracy i ku mojemu zdziwieniu zdałem sobie sprawę, że hasła użytkowników przechowywane w bazie danych są szyfrowane przy użyciu wewnętrznej funkcji szyfrowania, która obejmuje również możliwość deszyfrowania.

Więc wszystko, co naprawdę trzeba zrobić, to skopiować tabelę użytkowników i skopiować zestaw szyfrowania (każdy z dostępem do produkcji bazy danych), a następnie miałby dostęp do 100 000 adresów e-mail i potencjalnych haseł dla nich.

Próbuję wyjaśnić biznesowi, dlaczego nie jest to dobry pomysł, ale koncepcje bezpieczeństwa wydają się przesadzone, ponieważ nie są tak technicznie nastawieni (dotyczy rządu). Dodatkowo w aplikacji istnieją funkcje umożliwiające użytkownikom administracyjnym pobieranie haseł użytkownika w celu zalogowania się i zrobienia rzeczy (które, jak powiedzieli, wymagają).

Więc nie rozumieją konsekwencji dla bezpieczeństwa. Aby wdrożyć silniejszą politykę bezpieczeństwa (hashowanie haseł, aby nie można było ich łatwo odzyskać), muszę usunąć dla nich istniejącą funkcjonalność.

Co powinienem zrobić? Nie zbudowałem systemu haseł w pierwszej kolejności, więc nie można mnie winić, jeśli coś pójdzie nie tak. Z drugiej strony nie czuję się z tym dobrze, a także nie chcę mieć dostępu do 100 000 potencjalnych loginów e-mail.

Zaimplementuj potrzebną funkcjonalność w bezpieczny sposób. Administratorzy logujący się jako inny użytkownik mogą zostać zaimplementowani bez znajomości hasła użytkownika. Mogą zalogować się jako sami, a następnie mieć dostępną funkcję „zmiany tożsamości”.

Zabezpieczenie bazy danych haseł nie jest kwestią biznesową, lecz kwestią techniczną. Nieprzestrzeganie tego jest błędem. Jeśli firma uważa bezpieczeństwo za kompromis funkcjonalny, bezpieczeństwo straci. Nie powinieneś dawać im żadnego powodu, aby myśleć o tym w ten sposób.

Musisz przekonać ich, że tak naprawdę nie muszą ponosić odpowiedzialności cywilnej w przypadku włamania na ich serwer. Nie potrzebują też reakcji ze strony poinformowanej bazy użytkowników, która zdaje sobie sprawę, że są zaniedbywani.

Czasami zdarzają się wyraźne przypadki, w których jedna strona jest w błędzie, a druga ma rację. To jest jeden z tych czasów.

Zobacz, co właśnie stało się z Sony. Ponadto niedawno zaatakowano naszą witrynę, a jedną z rzeczy, które zapobiegły katastrofie, było skorzystanie z (względnie) dobrej jednokierunkowej funkcji skrótu (SHA512). Od tego czasu przeszliśmy na bcrypt, aby zapobiec nawet brutalnym atakom / atakom słownikowym (lub przynajmniej uniemożliwić ich atak). Po prostu nie uważam niczego innego za rozsądne.

Fakt: ludzie używają tego samego hasła w wielu witrynach

Twój szef prawdopodobnie nie zdaje sobie sprawy, że ludzie często używają jednego hasła (lub ich bardzo ograniczonego zestawu) do wszystkich rodzajów usług (w tym bankowości, Facebooka itp.). Jeśli użytkownicy mogą zmienić swoje hasło w systemie, istnieje duże prawdopodobieństwo, że użyją tego samego hasła, co w innym miejscu.

Jeśli twój szef uważa, że ​​dostęp do hasła nie stanowi problemu, powinieneś powiedzieć mu o tym i być może zaczną myśleć inaczej. Nawet jeśli Twoja aplikacja znajduje się za ścianą i nie jest publicznie dostępna, może stanowić zagrożenie bezpieczeństwa dla innych usług online. Nazwy użytkowników (zwłaszcza gdy są e-mailami) są dość łatwe do odgadnięcia. Nie wyobrażam sobie, jak zabawnie byłoby zalogować się na konto szefa Facebooka i położyć coś na ich ścianie.

Hasła użytkowników należy zawsze traktować jako informacje poufne / poufne najwyższego poziomu, do których dostęp ma tylko ograniczona liczba osób. Najlepiej unikać przechowywania takich niestabilnych informacji. A nawet gdy to zrobisz, powinieneś mieć zapewniony każdy dostęp do tych informacji. Jak zdobycie poufnego papieru z bardzo bezpiecznego sejfu, który można otworzyć tylko za pomocą wielu kluczy. Dzięki temu ludzie wiedzą, kto i kiedy uzyskał dostęp.

Jak wdrożyć delegowanie konta

Delegowanie konta w aplikacji powinno odbywać się inaczej.

1. Administratorzy powinni zalogować się jako sami, a następnie
2. albo (ponieważ są oni uprzywilejowanymi użytkownikami)
   • wprowadź tylko nazwę użytkownika lub
   • wybierz określonego użytkownika z listy, aby się zalogować

Zdecydowanie nie należy tego robić, logując się za pomocą kombinacji nazwa użytkownika i hasło .

To prawda, że ​​należy opracować nowy ekran, aby umożliwić delegowane logowanie, ale nadal.

Dlaczego logowanie delegowane jest lepsze?

Równie dobrze możesz zapewnić dodatkową funkcjonalność, która wyjaśni, że administrator wykonał pewne działania w imieniu jakiegoś użytkownika (czego nie możesz teraz wiedzieć, ponieważ administratorzy działają jak bogowie i logują się jako ktokolwiek i może robić rzeczy, które mogą zaszkodzić prawdziwa reputacja pracowników).

Musisz zgodzić się, że ludzie popełniają błędy. Administratorzy to także ludzie. A jeśli popełnią błąd w imieniu kogoś innego, będą próbować ich winić. Jestem tego w 100% pewien. Dzięki temu będzie bezpieczniejszy dla użytkowników niebędących administratorami, aby ich realna reputacja nie ucierpiała z powodu błędów innych osób.

Nie wspominasz o tym, co robi aplikacja. Jeśli są to aplikacje paszportowe, pełne informacji kradzieży tożsamości, które muszą być chronione, zasługuje na maksymalną ochronę. Ale jeśli to „powiedz mi wypadki drogowe na trasie do domu”, jakie są konsekwencje naruszenia hasła? Niektóre systemy, które napisałem, nie mają nawet haseł - wystarczy wpisać swój adres e-mail lub numer studenta lub inny identyfikator, który ludzie często znają się nawzajem, a właściciele systemu cenią łatwość użycia i niemożność zablokowania na temat możliwego naruszenia prywatności, jeśli ludzie podszywają się pod siebie. Z tym też nie mam problemu. Dlaczego potrzebuję hasła, aby na przykład ustawić harmonogram preferowanych sesji na konferencji?

Więc jeśli zostałbym przyprowadzony do przeglądu kodu, a ty mi to podałeś, od tego byśmy zaczęli. Co chronisz Jakie są negatywne konsekwencje, że jedna osoba udaje się zalogować jako jedna inna osoba? Jakie są negatywne konsekwencje ujawnienia przechowywanych danych? Może są okropne. Wymieniłbyś je dla mnie. Jakie są zatem konsekwencje braku możliwości kliknięcia „wyślij mi hasło e-mailem”, a zamiast tego „resetowania hasła”? Czy przestaną korzystać z witryny? A co z personelem logującym się jako osoba? Czy to oszczędza czas, pieniądze, utratę sprzedaży czy co?

Ostatnim elementem historii kosztów i korzyści, do którego można się dostać tylko wtedy, gdy istnieje naprawdę duża różnica między negatywami, na które jesteś teraz narażony, a negatywami, które otrzymasz po usunięciu funkcjonalności, jest koszt jej naprawienia. Czy wydałbym milion, aby oszczędzić mi szansy na ekspozycję za tysiąc dolarów? Nie. A może na odwrót? Chyba zależy od szans, ale moja pierwsza odpowiedź brzmi „tak”.

ps - rząd kanadyjski uruchomił witrynę z wnioskiem o paszport, która miała identyfikatory w adresie URL: jeśli edytowałeś adres URL z innym identyfikatorem, zobaczyłeś w połowie wypełnioną formę jakiegoś przypadkowego innego obywatela. I mam klientów, którzy logują się jako ich klienci w celach obsługi klienta do ogólnego szczęścia, więc widzę dobrą stronę, chociaż nie stałbym po stronie, gdyby dane za hasłem były naprawdę ważne dla nieznajomych.

Może to być niezgodne z prawem i może otworzyć ich na proces. Jeśli zachowują jakiekolwiek dane osobowe użytkownika lub system współdziała z innymi systemami, użytkownik może potrzebować sprawdzić, czy system podlega jakiejkolwiek stanowej lub federalnej ustawie o ochronie prywatności. to znaczy. Sarbanes / Oxley, California OOPA itp.

Oprócz potencjalnych problemów prawnych możesz również wskazać, że każdy administrator może w dowolnym momencie zrzucić całą tabelę na przenośny dysk danych i odejść z możliwością zalogowania się jako dowolny użytkownik i spowodować spustoszenie lub sprzedać dane.

Nawet jeśli zakładasz, że wszyscy administratorzy są godni zaufania, kompromis hasła administratora jest dewastujący.

Nie potrzebujesz również hasła użytkownika, aby wykonywać takie operacje. Możesz zaimplementować funkcję sudopodobną do.

Nie może to być federalny system rządowy, ponieważ wymagania FIPS i FISMA zakazałyby odwracalnego szyfrowania haseł, a dział rodzicielski uderzyłby ich w księżyc.

Aby wdrożyć silniejszą politykę bezpieczeństwa (hashowanie haseł, aby nie można było ich łatwo odzyskać), muszę usunąć dla nich istniejącą funkcjonalność.

W mojej poprzedniej firmie walczyłem o możliwość wysyłania wiadomości e-mail dotyczących resetowania hasła, aby obejść ten problem. I ciągle mnie odrzucano. W końcu zmęczyło mnie odkuwanie kupy pod prąd, więc wyszedłem. Był to również spiczasty szef, który uważał, że głupie pytania zadawane przez niektóre strony internetowe banków są liczone jako „uwierzytelnianie 2-czynnikowe”. Kłócenie się z nim było jak kreskówka Dilberta (miał kształt PHB).

Dodatkowo w aplikacji istnieją funkcje umożliwiające użytkownikom administracyjnym pobieranie haseł użytkownika w celu zalogowania się i zrobienia rzeczy (które, jak powiedzieli, wymagają).

Widziałem to wdrożone w instytucji finansowej. Osoby w dziale obsługi klienta logowałyby się przy użyciu własnych poświadczeń, a gdyby miały do ​​tego uprawnienia, mogłyby udawać, że logują się jako klient. To nie zalogowało ich jako klienta, tylko podszywało się pod klienta . W ten sposób, jeśli przedstawiciel działu obsługi klienta zdecyduje się wypłacić pieniądze, nie wyświetli się tak, jak klient robi to w dziennikach: pokaże, że przedstawiciel działu obsługi klienta próbuje to zrobić (a także wysyła ostrzeżenie, aby zwolnić ich jak najszybciej rentacop mógłby dostać się na podłogę).

Złe wykonanie sprawiłoby, że pracownicy obsługi klienta mogliby sprawić, że wydaje się, że użytkownik końcowy wykonał jakąś działalność, która mogłaby spowodować poważne zobowiązania finansowe lub prawne.

Ostatnia federalna strona internetowa, nad którą pracowałem, zebrała 1/4 miliardów dolarów rocznie od użytkowników końcowych (z których było około 400 użytkowników), więc rejestrowanie musiało być bardzo ścisłe, i że tylko upoważniony użytkownik końcowy mógł dotykać strony internetowe, na których zgłaszali rzeczy, od których płacili podatki akcyzowe.

Sony było jedną z firm, które miały najnowsze naruszenie bezpieczeństwa. To nie tylko sieć PS3, to także ich sieć gier MMORPG, o łącznej wartości ponad 25 000 000 nazwisk, adresów, numerów kart kredytowych, nazw użytkowników i haseł. Możesz uwierzyć, że wcale nie jestem szczęśliwy (chcę mój wieczny crack!).

Odnoszę się do Kodeksu Etyki Inżynierii Oprogramowania w takich sprawach. Moja interpretacja, twoim priorytetem nie jest podważanie interesu publicznego (nie w przypadku możliwości złamania hasła, bardziej jak w tym przykładzie, w którym firma zmodyfikowała laptopy Dell, aby firma wynajmująca mogła szpiegować najemców bez ich wiedzy). Następnie musisz poinformować klienta o potencjalnym ryzyku i pozwolić mu wziąć to pod uwagę. Oczywiście to minimalna linia bazowa. Musisz sam ocenić, czy czujesz, że jest to więcej, niż możesz stać i pozwolić.

Oczywiście, kiedy wspominasz o projekcie rządowym, jeśli prywatne informacje obywateli są zagrożone z powodu tych praktyk, podważa to interes publiczny.

Możesz wydrukować listę e-maili i odszyfrowanych haseł i umieścić je na biurku szefa, z dużym ostrzeżeniem na stronie tytułowej: „Poufne”

Jednak czcionka powinna być mała, aby nie marnować papieru.

Możesz także pokazać im, w jaki sposób bugzilla pozwala administratorom na podszywanie się pod ludzi bez używania hasła.

Przede wszystkim zgadzam się z innymi odpowiedziami wskazującymi, że o wiele bezpieczniej jest po prostu tego unikać i przechowujemy tylko skróty haseł, a nie same hasła lub cokolwiek, co można przekształcić z powrotem w hasło.

Są jednak chwile, kiedy mniej więcej musisz pozwolić na odzyskanie. W przypadku haseł zazwyczaj chcesz je odzyskać, pozwalając administratorowi na zmianę hasła w razie potrzeby, zamiast odzyskiwania istniejącego hasła.

Inną możliwością jest jednak to, że pozwalasz użytkownikowi na przechowywanie danych na serwerze, które są zaszyfrowane własnym hasłem. W takim przypadku zwykłe zezwolenie administratorowi na zmianę hasła nie jest wystarczające. Nowe hasło nie będzie działać w celu odszyfrowania danych, a większość użytkowników uzna za niedopuszczalne, aby wszystkie ich zaszyfrowane dane stały się niedostępne, gdy / jeśli zapomną / zgubią hasło. W tej sytuacji istnieje alternatywa, która jest względnie bezpieczna i nadal umożliwia odzyskanie, gdy jest naprawdę potrzebna.

Zamiast używać hasła użytkownika do szyfrowania danych, tworzysz losowy klucz do szyfrowania samych danych. Następnie przechowujesz ten klucz w kilku miejscach: raz zaszyfrowany hasłem użytkownika, a następnie w innym miejscu zaszyfrowanym hasłem administratora. Następnie, gdy (nie tak naprawdę) użytkownik traci hasło i nie może już uzyskać bezpośredniego dostępu do danych, możesz użyć hasła administratora do odszyfrowania prawdziwego klucza i użyć go do odzyskania danych i / lub ponownego zaszyfrowania klucza za pomocą nowe hasło użytkownika.

Jeśli nie chcesz całkowicie ufać jednemu administratorowi, możesz to również zarządzać. Na przykład możesz zdecydować, że 5 osób będzie miało klucze administratora i chcesz, aby co najmniej trzy z nich zgodziły się, zanim klucz będzie można odzyskać. W takim przypadku, gdy przechowujesz zaszyfrowane hasło do celów administracyjnych, przechowujesz je wiele razy, po jednym dla każdego zestawu trzech z pięciu administratorów (co nie zajmuje dużo miejsca, ponieważ przechowujesz tylko wiele kluczy , po ~ 256 bitów na sztukę, nie wiele kopii danych). Każda z tych kopii jest kolejno szyfrowana (skrótami) każdego z haseł tych trzech administratorów.

Aby go odszyfrować, musisz zidentyfikować trzech administratorów, którzy wprowadzają swoje hasła, i wybrać odpowiedni zaszyfrowany klucz dla tego zestawu trzech, a następnie odszyfrować za pomocą każdego z trzech haseł, aby w końcu uzyskać oryginalny klucz. Następnie możesz użyć go do odzyskania samych danych lub po prostu ponownie zaszyfrować je przy użyciu (skrótu) nowego hasła użytkownika, aby nadal mieć dostęp do swoich danych.

Kiedy to robisz, naprawdę musisz użyć standardowego algorytmu szyfrowania i (z wyraźną preferencją) standardowej, dobrze znanej, dokładnie zbadanej jego implementacji.

Martwi mnie to, biorąc pod uwagę, że jest to projekt rządowy. Odzyskanie hasła użytkownika w celu wykonania akcji pod jego identyfikatorem jest nonsensem z jakiegokolwiek rodzaju audytu bezpieczeństwa. Jedyny powód, dla którego to widzę, to utworzenie fałszywej ścieżki audytu.

Naprawdę nie ma potrzeby używania odwracalnego szyfrowania haseł. Jeśli kiedykolwiek istnieje uzasadniony powód do fałszowania identyfikatora użytkownika, można to zrobić przez:

• Zapisz bieżący skrót hasła
• Zastąpienie znaną wartością
• (Faked-audit-trail-activity, np. Przelew funduszy na rachunek offshore)
• Zastąp oryginalny skrót hasłem

Byłbym niewygodny z ostatnim krokiem - ktokolwiek był podszywany pod system, powinien wiedzieć, że to się stało. Może uda ci się przekonać firmę, mówiąc: „To tak, jakby twój bank pozwalał mi uzyskać dostęp do twojego konta bez twojej wiedzy, ponieważ powiedziałem, że naprawdę muszę”

Ich wiara w lepszy system haseł nie stanowi problemu. Utwórz rozwiązanie, aby umożliwić administratorowi / wsparciu personifikację konta użytkownika i podać poprawkę do haseł. Bezpieczeństwo często cierpi z powodu wygody. Spraw, by było to wygodne i bezpieczne.

Edycja: Nigdy, przenigdy nie zrozumieją problemu bezpieczeństwa hasła, ale rozumieją utratę funkcjonalności. Złóż tę propozycję i sprawdź, czy możesz uzyskać zgodę na dokonanie niezbędnych zmian. Nie wiedzą nawet, czy zajmie to godzinę, czy rok. Jest to zmiana funkcji, a nie pełna przebudowa.

Biorąc pod uwagę bieżące wydarzenia (wyciek danych Epsilon i wyciek danych Playstation Network), można mieć nadzieję, że problemy będą rażąco oczywiste.

Czasami jednak jako programista po prostu nie możesz wpływać na zasady.

Zrobiłbym wszystko, aby pokazać potencjał skandalu i wydatków, które powinny być łatwe, ponownie biorąc pod uwagę bieżące wydarzenia. Ale jeśli to się nie powiedzie, co naprawdę możesz zrobić. Niewiele. Przestań protestować, pokaż słabość, by zwrócić na siebie uwagę. Żaden nie brzmi jak świetne opcje.

Odradzam to, ale jeśli absolutnie musisz mieć możliwość odszyfrowywania haseł, powinieneś użyć szyfrowania kluczem publicznym. W ten sposób możesz zaszyfrować wszystkie hasła za pomocą klucza publicznego. Możesz zweryfikować hasła, szyfrując je za pomocą klucza publicznego i porównując, a klucz prywatny możesz przechowywać gdzie indziej (nie na komputerze produkcyjnym).

Zwykle powodem, dla którego administrator widzi hasło użytkownika, jest to, że jeśli je zgubi, może je podać użytkownikowi. O ile wiem, system Windows również nie pozwala administratorowi zobaczyć hasła - dlaczego więc twoja aplikacja? Każda wewnętrzna biblioteka szyfrująca z pewnością zostanie zepsuta, ponieważ jestem pewien, że ktokolwiek ją napisał, nie działa dla NSA.