Krótki link chroniony hasłem to krótki adres URL, który przed przekierowaniem pyta o hasło. Otwierasz link, zamiast celu trafiasz na niewielką stronę pośrednią, wpisujesz hasło, i dopiero wtedy uruchamia się przekierowanie. Podasz złe hasło - zostajesz na monicie. Cel nigdy nie zostaje ujawniony, dopóki weryfikacja się nie powiedzie.
To cała idea i warto być tu precyzyjnym, bo sama nazwa obiecuje więcej, niż daje. Brama hasła to utrudnienie dostępu przed linkiem. To nie szyfrowanie strony, która się za nim kryje. To dwie różne gwarancje, a mylenie ich to sposób, w jaki ludzie później się zdziwią. Ten artykuł omawia, do czego brama się nadaje, jakie zastosowania faktycznie pasują, jak działa weryfikacja przy przekierowaniu, gdzie kończy się bezpieczeństwo i z czym warto ją łączyć, żeby całość się trzymała.
Do czego służy krótki link chroniony hasłem
Przydatne przypadki mają wspólny kształt: udostępniasz link w kanale, nad którym nie masz pełnej kontroli, i chcesz, żeby do wejścia potrzebna była jeszcze jedna rzecz oprócz samego adresu URL.
Wrażliwy dokument to oczywisty przykład. Wysyłasz projekt umowy, model finansowy albo wewnętrzną prezentację komuś spoza firmy. E-maile są przekazywane dalej. Pliki PDF wysyłane są ponownie. Krótki link, który może otworzyć każdy mający adres URL, jest tak prywatny, jak najmniej ostrożna osoba, która kiedykolwiek go posiadała. Nałóż na niego hasło, a przypadkowe przekazanie dalej przestaje oznaczać automatyczny dostęp.
Materiały dla klienta to ten sam schemat, tylko z dołączonym terminem. Agencja przekazuje paczkę materiałów, zmontowane wideo, raport z kampanii. Klient powinien mieć do tego dostęp, ale cała jego książka adresowa już nie. Zabezpieczony adres URL trzyma materiał za wspólnym sekretem, który ustawiasz przy tworzeniu linku.
Prywatne kampanie i treści zamknięte dopełniają listę. Strona lądowania przed premierą, którą chcesz pokazać wąskiej grupie do wglądu. Oferta wczesnego dostępu dla listy oczekujących. Zasób tylko dla członków, gdzie odbiorcy już mają hasło skądinąd. W każdym z tych przypadków link podróżuje przez e-mail albo czat, a hasło to element, który odróżnia "dostałem to" od "trafiłem na to przypadkiem".
Co się nie nadaje: cokolwiek naprawdę tajnego, cokolwiek regulowanego, cokolwiek, czego wyciek byłby incydentem podlegającym zgłoszeniu. Dla takich przypadków wspólne hasło do linku jest zbyt tępym narzędziem. Potrzebujesz uwierzytelniania dla każdej osoby osobno na samym celu, a to inna kontrola, do której jeszcze wrócę.
Jak działa brama hasła przy przekierowaniu
Oto część mechaniczna, bo to kolejność operacji sprawia, że brama ma sens.
Zwykły krótki link to przekierowanie. Edge wyszukuje slug, znajduje cel i wysyła do przeglądarki odwiedzającego 302. Szybko, bezstanowo, bez pytań. Krótki link chroniony hasłem wstawia jeden krok przed przekierowaniem: edge widzi, że link ma ustawione hasło, więc zamiast przekierować, zwraca wyzwanie. Odwiedzający dostaje stronę pośrednią z prośbą o hasło. Wpisuje je. Podana wartość jest sprawdzana wobec zapisanego hasha. Jeśli pasuje, przekierowanie następuje. Jeśli nie, odwiedzający zostaje na monicie, a docelowy adres URL nigdy nie trafia do jego przeglądarki.
Dwa szczegóły decydują o tym, czy to w ogóle coś warte.
Po pierwsze, hasło jest haszowane, nigdy nie jest przechowywane jawnym tekstem. Zapisany sekret linku powinien być hashem jednokierunkowym, żeby odczyt bazy danych nie oddawał atakującemu wszystkich haseł do linków w systemie naraz. Argon2id to obecnie zalecany algorytm haszowania haseł i to właśnie z niego korzysta Elido przy hasłach do linków, a weryfikacja odbywa się w procesie za pomocą porównania w stałym czasie, dzięki czemu sama kontrola nie ujawnia informacji przez pomiar czasu. API linku nigdy nie zwraca hasha - zwraca wartość logiczną mówiącą, czy hasło jest ustawione. Odbiorca trafiający na chroniony link dostaje 401 z flagą password_required i tokenem wyzwania, i musi w kolejnym żądaniu podać poprawne hasło, zanim nastąpi przekierowanie. Mechanikę tego przechowywania opisuje checklist bezpieczeństwa skracacza URL, w sekcji o ochronie hasłem na poziomie pojedynczego linku.
Po drugie, weryfikacja odbywa się, zanim cel zostanie ujawniony. Brzmi to oczywiście, ale zaskakująco wiele "prywatnych" schematów linków ujawnia cel w kodzie po stronie klienta albo w łańcuchu przekierowań, który zdeterminowany odwiedzający odczyta wprost z ruchu sieciowego. Sens wykonywania weryfikacji przy przekierowaniu, po stronie serwera, polega na tym, że docelowy adres URL zostaje na serwerze, dopóki hasło się nie zgadza. Jeśli kiedykolwiek widziałeś bramę zaimplementowaną jako JavaScript, który pobiera prawdziwy adres URL, a potem przekierowuje, widziałeś bramę, którą każdy z narzędziami deweloperskimi przeglądarki przejdzie bez przeszkód. Weryfikacja po stronie serwera robi tu różnicę - to samo rozumowanie sprawia, że smart linki kierują ruch na edge, a nie w skrypcie JS na stronie lądowania.
Granice bezpieczeństwa, powiedziane wprost
To sekcja, którą ludzie pomijają, a potem tego żałują, więc umieszczamy ją w środku, gdzie trudno ją przeoczyć.
Brama hasła chroni krótki link. Nie chroni celu. Jeśli cel to publiczny adres URL, do którego każdy dotrze, wpisując go bezpośrednio, hasło powstrzymuje tylko osoby mające krótki link, a nie te, które mogą odgadnąć bazową stronę albo na nią trafić. Brama podnosi poprzeczkę w typowym przypadku udostępniania, gdzie jedyne, co ktoś ma, to krótki adres URL. Nie robi nic dla celu, który już jest odsłonięty.
Zasada jest więc prosta: cel też powinien mieć kontrolę dostępu. Dokument za krótkim linkiem chronionym hasłem powinien też mieszkać gdzieś, gdzie sprawdza się, kim jesteś, a nie tylko gdzieś, gdzie akurat jest długa, trudna do odgadnięcia ścieżka. Punktem odniesienia są tu OWASP Authentication Cheat Sheet oraz towarzyszące wytyczne dotyczące kontroli dostępu: uwierzytelnianie dowodzi, kim ktoś jest, kontrola dostępu decyduje, do czego może dotrzeć, a wspólne hasło do linku to słaba forma tego pierwszego, która nic nie mówi o drugim. Traktuj je jako warstwę wygody, a nie jako coś, co stoi między atakującym a danymi regulowanymi.
Kilka kolejnych szczerych ograniczeń.
Wspólne hasło jest wspólne. Dla bramy każdy, kto je zna, jest tą samą tożsamością. Nie ma śladu na poziomie osoby, kto otworzył link, ani sposobu odebrania dostępu jednej osobie bez zmiany hasła wszystkim pozostałym. Jeśli musisz wiedzieć, że materiał otworzyła konkretnie Dana, wspólne hasło do linku Ci tego nie powie.
Link zawsze powinien być serwowany przez HTTPS. Hasło wysłane przez zwykłe HTTP to hasło przesłane jawnym tekstem do każdego na trasie sieciowej. Szyfrowanie transportu to podłoga, nie funkcja dodatkowa; przegląd HTTPS od MDN wyjaśnia dlaczego. Elido domyślnie serwuje przekierowania przez HTTPS, także na domenach niestandardowych, ale ta zasada obowiązuje niezależnie od tego, gdzie stawiasz bramę.
I hasło nie zastępuje wygaśnięcia. Link, który pozostaje aktywny wiecznie, jest zobowiązaniem niezależnie od tego, czy ma hasło, bo sekret z czasem powoli wycieka, w miarę jak trafia w coraz więcej miejsc. Połącz bramę z czasem życia linku.
Z czym warto ją łączyć
Brama hasła to jedna kontrola. Działa najlepiej w zestawieniu z innymi, które pokrywają to, czego ona nie potrafi.
Wygaśnięcie i limity maksymalnej liczby kliknięć ograniczają link w czasie i użyciu. Ustaw expires_at, żeby materiał dla klienta gasł po zakończeniu współpracy, oraz limit maksymalnych kliknięć, żeby jednorazowy link do pobrania dezaktywował się po pierwszym otwarciu. Oba mechanizmy są egzekwowane przy przekierowaniu, zanim zarejestruje się jakiekolwiek zdarzenie kliknięcia, co oznacza, że błędna próba hasła wobec linku, który już wygasł, w ogóle nie dociera do bramy. Kompromisy dotyczące czasu życia linku omawia nadchodzący wpis wygasanie linków i linki samoniszczące się.
Limity IP albo geograficzne zawężają, kto w ogóle może próbować przejść przez bramę. Jeśli materiał dla klienta jest otwierany zawsze z jednego biura, ograniczenie linku do tego zakresu oznacza, że wyciekłe hasło plus wyciekły link i tak zawiodą z każdego innego miejsca. Kontrole na poziomie regionu omawia wpis krótkie linki z geolockowaniem i łączą się one z hasłem, zamiast je zastępować.
Dla zespołów właściwą odpowiedzią zwykle wcale nie jest wspólne hasło. Jest nią SSO. Gdy osoby, które powinny mieć dostęp do linku, to pracownicy w Twoim dostawcy tożsamości, zabezpiecz cel przez SCIM i SSO, żeby dostęp podążał za katalogiem: ktoś odchodzi z firmy, jego dostęp znika, bez konieczności zmiany hasła. Wspólne hasło do linku jest do doraźnego udostępniania na zewnątrz; dostęp zarządzany przez katalog jest do wszystkiego, gdzie potrzebujesz odbierania dostępu pojedynczej osobie. Przewodnik konfiguracji SCIM i SSO prowadzi przez wdrożenie, a strona rozwiązań dla przedsiębiorstw pokazuje, gdzie to pasuje.
Ogólna zasada to obrona w warstwach. Żadna pojedyncza kontrola nie jest tu silna sama w sobie. Hasło powstrzymuje przypadkowy dostęp, wygaśnięcie ogranicza okno czasowe, HTTPS chroni transmisję, kontrola dostępu celu chroni treść, a SSO obsługuje przypadek zespołowy. Ułóż w stos te, których wymaga Twoja sytuacja.
Praktyczny poradnik krok po kroku
Jeśli chcesz zabezpieczyć link, kształt tej pracy jest taki sam niezależnie od narzędzia.
Ustaw hasło przy tworzeniu albo edycji linku. Ustawienia linku powinny pozwalać dołączyć hasło; gdy jest ustawione, link przestaje być zwykłym przekierowaniem i zaczyna zwracać wyzwanie. Wybierz hasło, które nie jest trywialne do odgadnięcia i nie jest powtórzone skądinąd, bo wspólny sekret, który otwiera też Twoją skrzynkę e-mail, to zły wspólny sekret.
Udostępniaj link i hasło osobnymi kanałami. To pojedynczy nawyk o najwyższej wartości. Wyślij krótki link w e-mailu albo dokumencie, a hasło w wiadomości na czacie, osobnym e-mailu albo podczas krótkiej rozmowy. Jeśli oba podróżują w tej samej wiadomości, jedna przechwycona wiadomość oddaje wszystko, a brama nic nie dała. Rozdzielenie ich oznacza, że atakującemu potrzebne są dwa kanały, a nie jeden.
Ustaw wygaśnięcie od razu. Zdecyduj z góry, jak długo link powinien żyć i czy powinien się zablokować po znanej liczbie otwarć, i ustaw to przy tworzeniu linku, zamiast obiecywać sobie, że posprzątasz to później. Nie posprzątasz.
Sprawdź, czy cel ma własną kontrolę dostępu, jeśli treść jest wrażliwa. Brama wykonuje swoje zadanie w scenariuszu udostępniania. Jeśli bazowy dokument musi też odeprzeć kogoś, kto odgadnie adres URL, ta ochrona musi mieszkać na celu, nie na krótkim linku. Pełniejsze omówienie tego, jak te elementy wpisują się w model zagrożeń, znajdziesz w artykule czy skracacze URL są bezpieczne, a strona zaufania opisuje podejście Elido.
Taka jest uczciwa wersja krótkich linków chronionych hasłem. To przydatny, mało uciążliwy sposób, żeby udostępniony adres URL nie był otwarty dla każdego, kto akurat go dostanie. To nie skarbiec. Użyte jako jedna warstwa w stosie, z wygaśnięciem i właściwie kontrolowanym dostępem do celu, robią dokładnie to, co powinny. Użyte jako jedyna rzecz stojąca między atakującym a czymś ważnym, zawiodą. Ustaw bramę, rozdziel kanały, ogranicz czas życia i zabezpiecz cel, a dostaniesz przepływ udostępniania, który się trzyma.
Jeśli chcesz zobaczyć, które kontrole są dostępne na którym planie, wymienia je cennik, a funkcja domen niestandardowych opisuje serwowanie zabezpieczonych linków na własnej brandowanej domenie przez HTTPS. Konfigurację tego omawia artykuł jak skonfigurować brandowane krótkie linki.
Powiązane na blogu
Najczęściej zadawane pytania
Czym jest krótki link chroniony hasłem?
To krótki link, który przed przekierowaniem pokazuje monit o hasło. Odwiedzający otwiera krótki adres URL, trafia na stronę pośrednią, wpisuje hasło, a przekierowanie uruchamia się dopiero po poprawnym wpisie. Błędne hasło zostawia go na monicie. Hasło to brama przed linkiem, a nie szyfrowanie strony, do której on prowadzi.
Kiedy warto zabezpieczyć link hasłem zamiast po prostu trzymać go w ukryciu?
Użyj hasła, gdy link będzie udostępniany w kanale, nad którym nie masz pełnej kontroli: przekazany dalej e-mail, wiadomość na Slacku, plik PDF, który ktoś wysyła dalej. Link ukryty jest tak prywatny, jak ostrożne są osoby, które go posiadają. Hasło dodaje drugi czynnik, którego sam przekazany adres URL nie niesie, dzięki czemu przypadkowe przekazanie linku nie daje automatycznie dostępu.
Czy krótki link chroniony hasłem jest bezpieczny?
To utrudnienie dostępu, a nie granica bezpieczeństwa samego celu. Brama powstrzymuje przypadkowy dostęp i nieumyślne przekazanie linku dalej. Nie szyfruje celu, a każdy, kto ma zarówno link, jak i hasło, dotrze do treści. Przy czymkolwiek naprawdę wrażliwym cel również potrzebuje własnej kontroli dostępu. Traktuj hasło jako jedną warstwę, a nie całą obronę.
Czy można obejść hasło, zgadując docelowy adres URL?
Jeśli cel to publiczny, łatwy do odgadnięcia adres URL bez własnej kontroli dostępu, to tak - brama chroni tylko krótki link, a nie samą stronę. Dlatego cel również powinien mieć kontrolę dostępu. Brama hasła podnosi poprzeczkę dla osób, które mają wyłącznie krótki link, a to najczęstszy przypadek udostępniania.
Powinienem użyć hasła czy wygaśnięcia linku?
Często obu naraz. Hasło kontroluje, kto się dostaje do środka. Wygaśnięcie i limit maksymalnej liczby kliknięć kontrolują, jak długo link pozostaje użyteczny i ile razy można go otworzyć. Materiał dla klienta, który ma być dostępny przez dwa tygodnie, a potem zniknąć, to hasło plus data wygaśnięcia. Rozwiązują różne problemy i dobrze się ze sobą łączą.
Jak udostępnić hasło, nie ujawniając go przy okazji?
Wyślij link i hasło osobnymi kanałami. Link w e-mailu, hasło w wiadomości na czacie albo podczas krótkiej rozmowy. Jeśli oba podróżują razem w tej samej wiadomości, jedna przechwycona wiadomość oddaje wszystko. Rozdzielenie ich oznacza, że atakujący musi złamać dwa kanały, a nie jeden.
Wypróbuj Elido
Wklej URL, otrzymaj krótki link
Bez rejestracji. Link działa 30 dni. Zarejestruj się, aby zachować go na zawsze.
Za darmo, bez rejestracji · 2 dziennie