Security through obscurity
Z Wikipedii
Security through obscurity lub security by obscurity (z ang. bezpieczeństwo gwarantowane niejasnością) to kontrowersyjny paradygmat bezpieczeństwa teleinformatycznego, którego istotą jest ukrywanie detali dotyczących implementacji, formatów i protokołów przed potencjalnymi adwersarzami. Osoby stosujące tę technikę wierzą, że nawet jeśli system posiada luki, nieznajomość błędów uniemożliwia przeprowadzenie ataku.
Spis treści |
[edytuj] Przykład
Eric Raymond, w eseju The Cathedral and the Bazaar, opisał security by obscurity na przykładzie jednego z programów swojego autorstwa. Fetchmail jest narzędziem, które automatyzuje proces pobierania poczty elektronicznej ze zdalnych serwerów POP3 lub IMAP. Dane konta pocztowego podane są w pliku konfiguracyjnym. Użytkownicy programu wielokrotnie prosili o dodanie możliwości kodowania hasła, aby osoba mająca dostęp do pliku konfiguracyjnego nie mogła odczytać hasła. Eric argumentował, że właściwą metodą ochrony hasła jest uniemożliwienie dostępu do pliku konfiguracyjnego (poprzez odebranie prawa do odczytu pozostałym użytkownikom) i odmówił implementacji złudnego zabezpieczenia[1].
[edytuj] Krytyka
Najczęściej stosowanym argumentem krytyków security through obscurity jest (sformułowana w 1883) zasada Kerckhoffsa. Mówi ona, że system kryptograficzny powinien być bezpieczny nawet wtedy, gdy wszystkie szczegóły jego działania – oprócz klucza – są znane. Na tę zasadę powołał się Ross Anderson w podręczniku Security Engineering dyskutując kwestię otwartości w systemie zarządzania nuklearnego:
| „ | Korzyści wynikające z redukcji zagrożenia przypadkowej wojny przeważyły potencjalne korzyści wynikające z utrzymania tajemnicy. Jest to nowoczesna reinkarnacja doktryny Kerckhoffsa sformułowanej w XIX wieku, wymagającej aby bezpieczeństwo systemu zależało od klucza, a nie od niejawności konstrukcji systemu. | ” |
| — Ross Anderson, Security Engineering | ||
Claude Shannon sparafrazował tę zasadę jako "wróg zna system", a Bruce Schneier we wstępie do swojego podręcznika Applied Cryptography stawia pojęcie niejawności w opozycji do bezpieczeństwa:
| „ | Jeśli wezmę list, zamknę go w sejfie, ukryję sejf gdzieś w Nowym Jorku i każę Ci go przeczytać, to nie jest bezpieczeństwo. To niejawność. Z drugiej strony, jeśli wezmę list, zamknę go w sejfie, a następnie przekażę Ci ten sejf wraz z jego specyfikacją techniczną oraz setką identycznych sejfów z ich kodami, abyś razem z najlepszymi włamywaczami świata mógł przestudiować jego zabezpieczenia – a Ty nadal nie będziesz go mógł otworzyć i przeczytać listu – to właśnie jest bezpieczeństwo. | ” |
| — Bruce Schneier, Applied Cryptography | ||
[edytuj] Kontrargumenty
Choć poleganie wyłącznie na niejawności nie gwarantuje bezpieczeństwa, utrzymanie konstrukcji systemu w tajemnicy może być rozsądną taktyką realizującą jedną z warstw strategii wielostrefowej obrony (z ang. defense in depth) i może redukować krótkoterminowe ryzyko wykorzystania luk systemu.
Taktyka niejawności może również służyć do stworzenia honeypotu, który przyciągnie uwagę atakującego do nieistotnych części systemu oraz umożliwi poznanie źródeł i strategii ataków.
