Niewidzialność nie jest złym środkiem bezpieczeństwa. Poleganie na niejasności, jako jedynym lub najbardziej znaczącym środku bezpieczeństwa, jest mniej więcej grzechem kardynalnym.

Zasada Kerckhoffa jest prawdopodobnie najczęściej- przytoczony argument przeciwko wdrażaniu bezpieczeństwa poprzez zaciemnienie. Jeśli jednak system jest już odpowiednio zabezpieczony zgodnie z tą zasadą, jest to niewłaściwe.

Zasada, sparafrazowana, mówi: „załóżmy, że wróg wie wszystko o projekcie twoich systemów bezpieczeństwa”. Nie oznacza to w żaden sposób „powiedz wrogowi wszystko o swoim systemie, ponieważ oni i tak wiedzą”.

Jeśli system jest już dobrze zaprojektowany zgodnie z Zasadą Kerckhoffa, najgorsze, co można powiedzieć o zastosowaniu bezpieczeństwo poprzez niejasność polega na tym, że niewiele wnosi do żadnej wartości. Jednocześnie w przypadku takiego systemu ochrona poufności jego projektu jest równie niewielka lub żadna.

Zachowanie tajemnicy projektu nie sprawia, że ​​drzwi są niepewne per se ; jednak przekonanie, że zwiększa bezpieczeństwo, jest niebezpiecznym złudzeniem.

Jeśli ujawnienie szczegółów systemu uwierzytelniania pozwoliłoby go złamać, to ten system jest czystym śmieciem i należy go wyrzucić. Dlatego jeśli dobrze wykonałeś swoją pracę, ujawnienie szczegółów powinno być nieszkodliwe. Jeśli nie wykonałeś swoją pracę prawidłowo, zwolnij się i zatrudnij kogoś kompetentnego.

Ogólnie rzecz biorąc, publikowanie szczegółów systemu promuje zewnętrzne recenzje, które skutkują przerwą cykl poprawek, który ostatecznie poprawia bezpieczeństwo. W kontekście szkolnym nie publikowanie szczegółów systemu szkodzi bezpieczeństwu, ponieważ szkoły są pełne uczniów, a studenci są znani jako wścibscy anarchiści, których szczególnie pociąga inżynieria wsteczna wszystkiego, co jest przed nimi utrzymywane w tajemnicy. Powszechnie wiadomo, że w sali komputerowej studenta najlepszym sposobem na ograniczenie liczby incydentów związanych z bezpieczeństwem jest podanie kilku uczniom hasła roota / administratora - gdy uczeń chce zająć się bezpieczeństwem komputera, dając mu pełny dostęp usuwa wszelką motywację do prób zepsucia rzeczy ORAZ zamienia go w darmowego policyjnego pomocnika do monitorowania innych uczniów.

Ponadto, opisanie wewnętrznego działania systemu bezpieczeństwa może być wysoce pedagogicznym przedsięwzięciem. Słyszałem, że w niektórych szkołach faktycznie praktykują pedagogikę, przynajmniej od czasu do czasu. Twoja szkoła może chcieć spróbować.

Otrzymałeś już kilka doskonałych odpowiedzi, chociaż odpowiedzi @ TomLeek i @ Iszi (obie znakomite przy okazji) wydają się być w bezpośredniej sprzeczności.

Obydwie mają doskonałe uwagi: z jednej strony zachowanie tajemnicy projektu nie zapewni bezpieczeństwa systemu, podczas gdy publiczne przeglądanie go umożliwi (prawdopodobnie) znalezienie pewnych luk, których nie brałeś pod uwagę; z drugiej strony nie zaszkodzi utrzymywać projekt w tajemnicy, o ile nie jest to kluczowy czynnik dla bezpieczeństwa projektu.

Obie strony mają całkowitą rację - czasami .

Myślę, że uczciwie byłoby powiedzieć, że obie strony w ogólnym argumencie zgodzą się, że zachowanie tajemnicy projektu w ogóle nie zwiększa bezpośrednio bezpieczeństwa.
W najgorszym przypadku po prostu ukrywa luki w zabezpieczeniach (które mogą, ale nie muszą być dobre, w zależności od tego, przed kim uważasz, że są najbardziej ukryte).
W najlepszym przypadku (gdy nie ma żadnych trywialnych luk, które zostałyby ujawnione przez publikacja projektu), nadal nie zwiększa bezpieczeństwa - ale minimalizuje powierzchnię ataku .

Minimalizuje powierzchnię ataku (nawet bez obecności luka) jest zdecydowanie dobrą rzeczą; należy to jednak rozważyć i wymienić na korzyści płynące z publikacji (a mianowicie weryfikację przez dodatkowe spojrzenia) oraz wady związane z utrzymywaniem tego w tajemnicy - np. pokusa polegania na nim jako na kontroli bezpieczeństwa (zawsze popularne zabezpieczenie przez zapomnienie), jako na formie teatru bezpieczeństwa.

Warto również zauważyć, że, jak wspomniał @Tikiman, samo opublikowanie projektu nie wystarczy, aby upewnić się, że zostanie on zrecenzowany - zwłaszcza przez tych, którzy potrafią znaleźć luki i którzy są również skłonnych do ich ujawnienia. W wielu przypadkach opublikowany projekt byłby sprawdzany tylko przez złośliwe osoby z nielegalnym zamiarem, więc nie osiągnąłbyś spodziewanych korzyści. Co więcej, często nawet nie wiadomo , czy ich projekt mieści się w wyżej wymienionym najlepszym, czy najgorszym przypadku.

Podsumowując - podobnie jak w przypadku wielu innych kwestii związanych z bezpieczeństwem, prosta odpowiedź nadal brzmi: To zależy .

Należy rozważyć pewien kompromis - jeśli byłby to złożony system kryptograficzny, odpowiedź byłaby jasna; gdyby był to typowy system korporacyjny wymagający dużej liczby wdrożeń, jasna byłaby inna odpowiedź.

Moje skłonności w tym przypadku są takie, jak powiedział @Tom, ale z wymienionych drugorzędnych powodów - częściowo z anarchicznej bazy użytkowników, a głównie z celu pedagogicznego.

Zauważ, że nie są to tak naprawdę względy bezpieczeństwa - przynajmniej nie bezpośrednio.

(Aha, a co do punktu @ Tikimana - pedagogika tutaj zaangażowana oznacza, że ​​możesz faktycznie upewnić się, że projekt jest recenzowany, przynajmniej przez całą klasę ;-))

Ten artykuł Daniela Misslera jest świetny!

Stwierdza, że ​​

Security by Obscurity jest zły, ale niejasny, gdy zostanie dodany jako warstwa na wierzchu innych elementów sterujących może być całkowicie uzasadniona.

mając taką koncepcję, o wiele lepszym pytaniem byłoby

Czy dodawanie niejasności jest najlepszym zastosowaniem moje zasoby, biorąc pod uwagę kontrolki, które mam na miejscu, czy lepiej byłoby dodać inną kontrolę (nie opartą na niejasności)?

Możemy również użyć anologii kamuflażu jako niejasność jako kolejna warstwa bezpieczeństwa

Potężnym tego przykładem jest kamuflaż . Rozważmy czołg opancerzony , taki jak M-1. Czołg jest wyposażony w najbardziej zaawansowany pancerz, jaki kiedykolwiek był używany. i wielokrotnie pokazywano, że jest skuteczny w rzeczywistych bitwach.

Tak więc, biorąc pod uwagę to wysoce skuteczny pancerz, czy zagrożenie dla czołgu wzrosłoby w jakiś sposób, gdyby był pomalowany na ten sam kolor co jego otoczenie? A może w przyszłości, gdy będziemy mogli uczynić czołg całkowicie niewidocznym? Czy zmniejszyliśmy skuteczność zbroi? Nie, nie zrobiliśmy tego. Sprawienie, że coś trudniej jest zobaczyć, nie ułatwia ataku, jeśli zostanie odkryte. Jest to błąd, który po prostu musi się skończyć.

Kiedy celem jest zmniejszenie liczby udanych ataków, zaczynając od solidnych, przetestowanych zabezpieczeń i dodawania niejasności jako warstwy, przynosi ogólne korzyści dla stanu zabezpieczeń. Kamuflaż osiąga to na polu bitwy, a PK / SPA osiąga to, chroniąc usługi wzmocnione.

Podkreślam mój.

Komentarz Isziego jest również świetny, stwierdza, że ​​tak jest znacznie lepiej, jeśli zmienimy słowo adding na enforcing , więc podsumowując będzie to wyglądało tak:

Podsumowanie:

Bezpieczeństwo dzięki niejasności jest złe, ale bezpieczeństwo wymuszane z niejasnością jako warstwą na wierzchu innych kontroli może być całkowicie uzasadnione. Zakładanie, że jesteś bezpieczny na polu bitwy, ponieważ uważasz, że twój czołg jest pomalowany na ten sam kolor co otoczenie, jest po prostu bzdurą. . Ale doskonalenie obrony czołgów i wzmocnienie farby, która zapewnia kamuflaż jako kolejną warstwę ochrony, jest świetne!

Chociaż nie odpowiadam na Twoje pytanie, może to posłużyć jako argument przeciwko Twojej szkole.

Uważam, że ktoś, kto uzyska dostęp do autoryzowanego klucza / tożsamości, stanowi realne ryzyko. Ludzie są niechlujni, używają złych haseł i cały czas zapisują sekrety. Pewien nauczyciel w mojej szkole, wieki temu, zostawił kiedyś klucze do całej szkoły w studenckiej łazience.

Gdybym chciał dostać się do tego pokoju, nie zawracałbym sobie głowy próbą znalezienia luki w zabezpieczeniach oprogramowanie; Kradłem klucz, próbowałem manipulować fizycznym zamkiem lub inną zewnętrzną metodą.

Albo, jak powiedział mój przyjaciel, gdy dyrektor zapytał go, jak zabrałby się do włamania do systemu szkolnego w celu zniszczenia danych; „Użyłbym kija baseballowego”.

Mam długie wyjaśnienie, które może wydawać się błądzące, więc podam skróconą odpowiedź, a następnie ją uzasadnię. Krótka odpowiedź: to bezpieczeństwo poprzez zaciemnienie, ale prawdopodobnie nie stanowi to problemu ze względu na liczbę osób, które mają kontakt z systemem. Więc prawdopodobnie nie warto się o to kłócić.

Masz rację twierdząc, że utrzymywanie projektu systemu w tajemnicy jest zabezpieczeniem przez zaciemnienie (STO). Głównym powodem, dla którego STO jest złym pomysłem, jest to, że system, którego wewnętrzne działanie nie jest początkowo znane, można odtworzyć we wszystkich przypadkach poprzez uważną obserwację i właściwe zastosowanie inżynierii społecznej. Jeśli jesteś jedyną osobą, która rozumie, jak działa system, jesteś jedyną osobą, która może zweryfikować jego integralność. Dlatego też, jeśli w Twoim projekcie występuje potencjalnie omijalna wada, a ktoś inny dokona inżynierii wstecznej Twojego projektu i odkryje go, może go wykorzystać łatwiej, niż gdybyś nie zachował swoich projektów w tajemnicy. Jest też bardziej prawdopodobne, że będą w stanie zachować swoje odkrycie i nielegalne użycie w tajemnicy.

Dzieje się tak, ponieważ jeśli upublicznisz swój projekt, więcej osób go obejrzy, im więcej osób przyjrzy się projektowi, tym większe jest prawdopodobieństwo, że ktoś odkryje istniejącą wadę i powie Ci o niej. Błąd projektowy może nie występować nawet w ogólnej koncepcji, ale w konkretnej implementacji, takiej jak możliwość przepełnienia bufora w implementacji bezpiecznego algorytmu. Podstawowa koncepcja publicznego użycia prymitywów kryptograficznych polega na tym, że informując wszystkich o twoich prymitywnych algorytmach kryptograficznych, inni mogą je przejrzeć. Po wykonaniu tej czynności przez dużą liczbę osób możesz mieć pewność, że projekt jest bezpieczny. Trudność polega na tym, że ponieważ tworzysz projekt dla szkoły, tylko bardzo niewielka liczba osób będzie prawdopodobnie oglądać Twoje projekty, z których bardzo niewielu prawdopodobnie je zrozumie. Im mniej osób obejrzy Twoje projekty, tym większe prawdopodobieństwo, że każdy, kto wykryje usterkę, nie zgłosi usterki.

Chyba że masz dostęp do dużej społeczności specjalistów ds. Bezpieczeństwa, którzy chcą przejrzeć Twój projekt, pozwalając im ich sposób może być mniej więcej równy pod względem rzeczywistego bezpieczeństwa.

Oczywistym celem byłoby uniemożliwienie uczniom włamania się do systemu uwierzytelniania drzwi.

Jeśli założymy, że system uwierzytelniania jest nieco, ale nie bardzo trudny do zhakowania, i że są studenci z pewnymi zaawansowanymi umiejętnościami hakerskimi, ale bez nich, to jest całkiem możliwe, że dodatkowa trudność wynikająca z dopracowania szczegółów systemu jest na tyle niedostępne, że jest poza zasięgiem tej grupy (studentów).

Z drugiej strony, gdy system jest tak bezpieczny, że złamanie go jest znacznie trudniejsze niż znalezienie lub odtworzenie działania systemu, utrzymywanie szczegółów w tajemnicy nie jest już zbyt przydatne.

Gdybym był odpowiedzialny za drzwi, miałbym takie same wymagania dotyczące poufności. Jeśli świat (i twoja praca) byłyby doskonałe, niejasność rzeczywiście będzie bezużyteczna.

Ale pomyśl tylko o tym, co faktycznie dzieje się w prawdziwym świecie. Zakładam, że wykonałeś swoją pracę najlepiej jak potrafiłeś, używając najnowocześniejszych algorytmów. Ale diabeł ukrywa się w szczegółach, a szczegół implementacji może osłabić bezpieczeństwo. Zdarzyło się to w bibliotece SSL nie tak dawno temu, nawet jeśli algorytmy rzeczywiście były bezpieczne.

To, czego chcesz, ujawniając szczegóły systemu bezpieczeństwa, to to, że partnerzy sprawdzają twoją implementację i ostrzegają o możliwych wadach zanim zostaną odkryte i wykorzystane przez atakujących. Jeśli znasz ekspertów w dziedzinie systemów bezpieczeństwa i każesz im przejrzeć twoją pracę, myślę, że byłoby to postrzegane jako dobra praktyka nawet w twojej szkole - przynajmniej IMHO powinno . Ale jeśli po prostu go opublikujesz, bardziej prawdopodobne jest, że Twoimi pierwszymi czytelnikami będą ci, przeciwko którym zbudowano zabezpieczenie drzwi! I na pewno nie chcesz, aby jako pierwsi przejrzeli twoją pracę pod kątem możliwych wad.

TL / DR: Jeśli zbudujesz ogólny system bezpieczeństwa, może on mieć dużą publiczność i nie używasz go od razu w produkcji powinieneś opublikować go jak najszerzej, aby uzyskać dobre recenzje. Ale jeśli stworzysz dedykowaną implementację, która zostanie natychmiast wykorzystana do prawdziwego bezpieczeństwa, ujawniaj szczegóły tylko zaufanym ekspertom, aby uniknąć pomagania atakującym w znalezieniu możliwych błędów.