Nie jestem pewien, skąd jesteś. Przede wszystkim jego opinia jest sprzeczna z uznaną najlepszą praktyką branżową określoną przez NIST. Ponadto twój menedżer niebezpiecznie się myli. Im więcej użytkowników, tym większe prawdopodobieństwo uzyskania tych samych haseł dla kilku użytkowników. Robią to również następujące firmy i jestem przekonany, że mają większą globalną bazę użytkowników niż Twoja witryna:

• Facebook
• Gmail
• Linkedin

Innym powodem, który można wyjaśnić z perspektywy biznesowej jest ryzyko uszkodzenia wizerunku / marki w przypadku negatywnej reklamy silny>. Aby dać przykład, Adobe zastosował złą implementację do przechowywania haseł, co prowadzi do tego samego problemu, co teraz: wartość wynikająca z haszowania (w przypadku Adobe używali szyfrowania zamiast haszowania) hasło było takie samo przez kilka użytkowników, jeśli używali tego samego hasła (w ich przypadku z powodu nieużywania IV podczas szyfrowania symetrycznego, ale nie ma to znaczenia). Spowodowało to ogromną burzę negatywnego rozgłosu, w końcu firma internetowa powinna trzymać się czegoś tak prostego jak haszowanie hasła, prawda? Koszty finansowe wynikające z takiej negatywnej reklamy mogą być znaczne.

Również w zależności od kraju, w którym mieszkasz i obowiązujących przepisów, obecnie kierownictwo może zostać pociągnięte do osobistej odpowiedzialności , jeśli zostanie ustalone, że dopuściło się zaniedbania w zakresie ochrony danych prywatność (jeśli np. złamane hasła są wykorzystywane do pozyskiwania danych osobowych użytkowników). Również w zależności od rodzaju przechowywanych informacji, finansowych, medycznych, kart kredytowych, mogą obowiązywać różne zasady, które mogą skutkować również innymi rodzajami grzywien.

Jest to coś, co może nie mieć znaczenia w przypadku bezpośredniego haszowania haseł, ale może się przydać, jeśli menedżer podejmie dalsze złe decyzje. Dlatego zrób kopie wiadomości e-mail, w których jasno wyjaśnisz problem, a także zachowaj odpowiedzi menedżerów. (tylko po to, by pokryć swój własny tyłek)

Fakt, że nie używasz soli, prawdopodobnie oznacza również, że nie używasz prawidłowego algorytmu haszującego, ponieważ często zajmują się one generowaniem soli i wykonywaniem wielu iteracji . Trzy akceptowane algorytmy to:

• PBKDF2
• bcrypt
• scrypt

Głównym celem soli jest zapobieganie oszczędzaniu pracy przez napastnika poprzez porównanie pojedynczego obliczonego skrótu ze wszystkimi przechowywanymi hashami. Ten problem jest niezależny od tego, czy hasła są unikalne, czy nie.

Bez soli, atakujący może po prostu przejrzeć swoją listę możliwych haseł, obliczyć skrót dla każdego z nich, a następnie sprawdzić, czy wynik pasuje do któregokolwiek z przechowywane skróty. Tak więc wymagane jest tylko jedno obliczenie na przypuszczenie.

W przypadku soli atakujący musi przejrzeć swoją listę dla każdego użytkownika, ponieważ nie może ponownie wykorzystać wyników. To zmusza go do wykonania jednego obliczenia na jedno przypuszczenie i na użytkownika. To znacznie zwiększa koszty ataku.

Ale jak już powiedział Lucas, prawdziwym problemem jest to, że nie używasz odpowiedniego algorytmu. Sole to tylko jeden aspekt mieszania haseł.

„Najlepszy” kontrargument zależy od tego, co próbujesz osiągnąć.

Jeśli chcesz mieć tylko naukową rację, wystarczy powiedzieć, że sole nie są i nigdy nie były, metoda radzenia sobie z dwoma różnymi użytkownikami wybierającymi to samo hasło. W szczególności, ponieważ dwóch użytkowników, którzy wybrali to samo hasło, nie stanowi problemu na początku, więc nie ma nic do naprawienia. Sole służą do unikania ataków równoległych, w tym używania wstępnie obliczonych tabel. Brak soli był głównym grzechem LinkedIn.

Racja ma teraz wpływ tylko na ludzi, którzy są gotowi przyznać, że mogą się mylić lub przynajmniej nie w pełni poinformowani. To, co cytujesz od swojego przełożonego, zwykle pokazuje, że jest on zarówno całkowicie niekompetentny w tym temacie, jak i przekonany, że całkowicie go opanował. Jeśli chcesz przekonać tego menedżera, że ​​się myli, to wielkie szczęście. To, czego ludzie najbardziej się boją, to przyznanie, nawet pośrednio, że powiedzieli coś głupiego.

Jeśli chcesz, aby Twoja organizacja faktycznie przełączyła się na prawidłowe haszowanie haseł (przeczytaj to), to mógł być w stanie przekonać inne osoby że to, co właśnie powiedział menedżer, to czysty bełkot, że nie ma nawet sensu, aby się mylić. Jeśli menedżer zostanie wyizolowany, może przymknąć oko na implementację prawidłowego haszowania haseł, oczywiście nie potwierdzając tego. I znowu, naukowo poprawny argument niekoniecznie jest najbardziej skuteczny. W Ameryce Północnej (zwłaszcza na obszarach o wpływach brytyjskich, takich jak Nowa Anglia), spotkania biznesowe mają na celu unikanie konfliktów i osłabianie odpowiedzialności, dlatego należy szerzyć strach, niepewność i wątpliwości: pamiętaj, aby zwrócić uwagę, że konkurenci przechodzą na solone hashe i nie robią tego samego, co grozi utratą części rynku. W południowej Europie spotkania to rytualne bitwy o ustalenie hierarchii, więc krzycz, warcz, grozi i używaj sarkazmu, aby zdobyć poparcie tłumu: nie wygrywasz mając rację , ale będąc asertywnym .

Ogólnie rzecz biorąc, jednym z najbardziej skutecznych typów argumentów jest odwołanie się do autorytetu. W NIST Special Publication SP800-118 (obecnie w wersji roboczej) można zobaczyć:

Innym przykładem słabości algorytmu wyznaczania wartości skrótu jest to, że niektóre algorytmy nie używają saltingu.

„Bez soli” = „słabość”. NIST tak mówi. Kim jest ten menedżer, który uważa, że ​​jest mądrzejszy od NIST?

W pewnym sensie, jeśli spierasz się o sól, to już przegapiłeś łódź. Stan wiedzy w zakresie bezpieczeństwa przechowywania haseł znacznie wykracza poza kwestię „solić lub nie zasolić” i od tego czasu przeszedł do liczenia iteracji.

Ale zacznij od podstaw. Oto odpowiedź, którą napisałem niedawno, która była zaskakująco popularna. Wyjaśnia, dlaczego sól jest lepsza, a wiele osób twierdzi, że coś kliknęło, gdy inne wyjaśnienia upadły. To mniej więcej to, o co pytasz - pokaż to swojemu szefowi, jeśli uważasz, że przyniesie to coś dobrego:

Dlaczego solone hashe są bezpieczniejsze?

Ale najważniejszą kwestią jest ostatnia z nich. Oznacza to, że przechowywanie solonego skrótu SHA1 i nazywanie go dobrym nie jest już uważane za odpowiedzialne. Moc obliczeniowa osiągnęła punkt, w którym miliardy haszów na sekundę nie są już teoretyczne, co pozwala ci przebić się przez całą 32-bitową przestrzeń ataku brutalnego szybciej niż to, co trzeba by wyjaśnić, co robisz.

Teraz skupiamy się na zmuszeniu atakującego do rozwiązania problemu tysiące lub setki tysięcy razy, aby tylko zgadnąć. Tam pojawia się PBKDF2 (ubrany w garnitur i krawat wydany przez NIST), a także scrypt i przyjaciele (wyglądający niechlujnie, ale potężnie).

Który algorytm wybierzesz, nie jest tak naprawdę kluczowy. Wszystkie rozwiązują mniej więcej ten sam problem, tylko na różne sposoby, z różnymi akcentami. Ale musisz użyć czegoś - jakiegoś algorytmu, który utrudnia brutalne wymuszenie nawet jednego hasła. Powód jest prosty: jest to standard branżowy, jest mierzalnie i dający się udowodnić bezpieczniejszy, a jego używanie nie wiąże się ze znacznymi kosztami. Połącz te czynniki razem, a szybko stanie się jasne, że jeśli tego nie zrobisz , możesz zostać uznany za niedbałego w przypadku naruszenia.

Najlepszym argumentem jest wyciągnięcie listy najpopularniejszych haseł i pokazanie, że około 1% użytkowników wybierze hasło „123456”. Drugim najlepszym rozwiązaniem byłoby przeprowadzenie analizy wycieku haseł dla dużej witryny i wykazanie, że tylko około połowa użytkowników zdoła wymyślić unikalne hasło.

Należy zwrócić uwagę na dwie kwestie:

• Użycie soli zmniejsza wartość skradzionego pliku zawierającego zaszyfrowane hasła. Dzieje się tak niezależnie od tego, jakim językiem (językami) posługują się użytkownicy systemu, ponieważ atakujący, który ma tęczową tabelę dla twojego algorytmu haszującego, może go użyć do odwrócenia zaszyfrowanego hasła, niezależnie od języka ojczystego osoby, która to wybrała hasło.

• Używanie soli jest prawie darmowe. Wykluczenie go nie daje prawie nic, a nawet w obecnych szacunkach przełożonego wykluczenie tego „prawdopodobnie” nie spowoduje poważnego problemu z bezpieczeństwem. Dlatego używaj go.

Jest zastrzeżenie, które Twój menedżer może zgłosić do pierwszego punktu, ale mam nadzieję, że nie może: „używamy naszego własnego, niestandardowego algorytmu haszującego, nie ma niebezpieczeństwa, że ​​istnieje dla niego tęczowy stół ”. W takim przypadku musisz także argumentować za użyciem standardowego algorytmu haszowania haseł.

Znajduję również:

[użytkownicy ] wszystkie mają różne języki ojczyste

dziwaczne założenie dotyczące systemu. Jeśli polegasz na założeniu do analizy bezpieczeństwa, twój system staje się niepewny (lub w każdym razie nie oceniany pod kątem bezpieczeństwa), gdy tylko założenie zostanie złamane. Więc opierając się na tym założeniu w zakresie bezpieczeństwa, musisz wymusić, aby nie było dwóch użytkowników produktu, którzy mają ten sam język ojczysty . Dlaczego ktoś miałby chcieć ograniczać swój system w ten sposób, aw szczególności w jaki sposób egzekwowanie tego ograniczenia będzie łatwiejsze niż użycie soli?

Jednak w tym przypadku założenie to nawet nie prowadzi do wniosku, że twój przełożony uważa, że ​​sól jest niepotrzebna (z powodu podanego powyżej). Więc pytanie, czy to założenie może zostać utrzymane, jest raczej nieistotne, biorąc pod uwagę fakt, że to nie pomaga!

Wreszcie do Twojej wiadomości, istnieje konkretny powód, dla którego mój pierwszy punkt powyżej zaprzecza analizie twojego menedżera:

prawdopodobnie nie użyje tego samego hasła

to błędna analiza słabości, którą rozwiązuje sól. Dla atakującego nie ma znaczenia, czy dwóch użytkowników systemu ma to samo hasło, czy nie, chyba że atakujący jest jednym z tych dwóch użytkowników i dlatego zna hasło, które udostępniają. Sole bronią nie tylko przed tym atakiem, ale także przed atakami tęczowego stołu. Więc nawet gdyby ten niezwykły atak jednego z użytkowników na to samo hasło był niemożliwy w Twoim systemie, nadal potrzebujesz soli.

Wydaje mi się, że jest to bardziej problem ludzki niż techniczny. Dlatego należy odpowiedzieć umiejętnościami miękkimi, a nie wyjaśnieniami technicznymi. Jeśli Twój menedżer pozytywnie reaguje na wyjaśnienia techniczne, wybierz wcześniej jedną z odpowiedzi.

Jeśli chcesz przejść do strony umiejętności miękkich, możesz spróbować kilku rzeczy:

• Najważniejsze do zapamiętania: Twój szef jest Twoim szefem. Nie złość się na niego, bo inaczej będziesz miał pecha.
• Staraj się nie zadawać mu pytań, na które nie może odpowiedzieć. Zamiast tego zadawaj pytania pośrednie w formie prostych zdań.
• Spróbuj zrozumieć jego punkt widzenia i argumenty.
• Zastosuj parafrazę.
• Nigdy się nie śmiej.
• Nigdy nie bądź niegrzeczny.
• Przeczytaj książkę Dale Carnegie „Jak zdobyć przyjaciół i wpływać na ludzi”.

Przykładowe okno dialogowe może wyglądać tak (pamiętaj, że ja ' Nie jestem rodzimym użytkownikiem języka angielskiego):

Szef: „Nie potrzebujemy soli”.
Ty: „Nie potrzebujemy dodatkowej ochrony”.
Szef: „Tak, nasi użytkownicy nie używają ponownie tego samego hasła”.
Ty: „Silne hasło jest już bezpieczne”.
Szef: „Zgadza się”.
Ty: „W porządku, rozumiem. Nasi użytkownicy zabezpieczają hasło, a my po prostu żyjemy bez soli”.
Szef: „Tak, może nie wszyscy użytkownicy ...”
Ty: uśmiech

Lub tak:

Szef: „Nie potrzebujemy soli”.
Ty: „Korzyści z używania soli nie są warte wysiłku”.
Szef: „Zgadza się”.
Ty: „Więc usuwamy sól z listy zadań i kontynuujemy z resztą”.
Szef: „Dobra, już mamy opóźnienie”.
Ty: „Gdybyśmy inaczej dotrzymali harmonogramu, moglibyśmy wprowadzić sól”.
Szef: „Nie, nie rozumiem tej koncepcji soli”.
Ty: „Te kwestie kryptograficzne są zawsze trudne do zrozumienia”.
Szef: „Nawet kiedy czytałem artykuł, nie miałem pojęcia”.
Ty: „Co sprawia, że ​​myślisz, że to dużo wysiłku”.
Szef: „Tak, stracimy mniej więcej dwa dni”.
Ty: "Z pomocą frameworka mogę to zrobić w 2 godziny."
Szef: „Naprawdę?”
Ty: uśmiech

Pamiętaj, że w ogóle nie ma znaków zapytania. Szef nigdy nie jest pod presją odpowiedzi na pytania, na które mógłby nie znać odpowiedzi.

Niestety, trudno jest zastosować takie techniki, jeśli nigdy wcześniej tego nie robiłeś.

Jeśli takie podejście też nie działa dobrze, jest jeszcze jedna opcja:

Po prostu zaimplementuj. Nie powinno to być zbyt wielkim wysiłkiem, a Twój szef prawdopodobnie tego nie zauważy, z wyjątkiem tego, że przegląda kod lub przegląda tabele bazy danych.

Po prostu wrzuć kilka skrótów (być może jego własnego hasła) do Google. Najprawdopodobniej zwróci hasło. Jego słaby haszowanie jest jak brak haszowania.

https://www.google.de/search?q=a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

Jeśli tak nie jest przekonać go do szukania nowej pracy ...