czy można używać losowych adresów URL zamiast haseł? [Zamknięte]

12

Czy używanie adresu URL zbudowanego z takich losowych znaków jest uważane za „bezpieczne”?

http://example.com/EU3uc654/Photos

Chciałbym umieścić kilka plików / galerii zdjęć na serwerze internetowym, do których dostęp ma tylko niewielka grupa użytkowników. Moją główną obawą jest to, że pliki nie powinny być pobierane przez wyszukiwarki lub ciekawskich zaawansowanych użytkowników, którzy przeglądają moją stronę.

Skonfigurowałem plik .htaccess, aby zauważyć, że klikanie http://user:pass@url/łączy nie działa dobrze w niektórych przeglądarkach / klientach e-mail, monitowanie okien dialogowych i komunikatów ostrzegawczych, które dezorientują moich niezbyt wybrednych użytkowników.

— gulasz
źródło

Nie. Możesz użyć tego, ale nie jako jedynego lub głównego mechanizmu uwierzytelniania.

— Andrew Smith,

1

Próbowałem tego wielokrotnie jako eksperymentu i za każdym razem, gdy linki kończą się w wyszukiwarkach. Nie wiem jak, ale wiem, że tak się dzieje.

— David Schwartz

Możesz skonfigurować protokół SSL, aby zatrzymać ostrzeżenia, możesz uzyskać bezpłatne certyfikaty ze strony openssl.com, a protokół SSL nie wymaga już intensywnych obliczeń (o ile jest poprawnie skonfigurowany).

— Hubert Kario

To pytanie jest klasycznym przykładem „niekonstruktywnym”. Nie wiemy, jak bardzo cenisz bezpieczeństwo swoich zdjęć. Jedynym sposobem na przekazanie znaczenia bezpieczeństwa jest wprowadzona metodologia autoryzacji w celu ochrony dostępu do tych zdjęć. Otrzymujesz „argumenty debaty” w formie „odpowiedzi”. Ale żaden z nich nie jest pełnym przeglądem współczesnych implikacji bezpieczeństwa i technicznych. Powinieneś przeczytać o metodach bezpieczeństwa zapewnianych przez twoją platformę i ocenić wartość każdej z nich dla twojej sytuacji; jeśli po zrobieniu tego masz dalsze pytania, zapytaj ponownie.

— Chris S

17

To, czy jest to „w porządku”, czy nie, zależy od czułości obrazów.

Jeśli nie używasz protokołu SSL, adresy URL, HTML i same obrazy będą buforowane na komputerach użytkowników. Może to przeciekać, ale uważam to za mało prawdopodobne.

Paski narzędzi przeglądarki, zwłaszcza te tworzone przez firmy, które obsługują roboty, takie jak Alexa i Netcraft, mogą zgłaszać odwiedzane adresy URL z powrotem do swoich stron nadrzędnych, gotowe do uruchomienia bota i zaindeksowania go później.

Prawidłowe uwierzytelnianie, takie jak uwierzytelnianie HTTP lub zmienna POST, nie powinno być w ten sposób buforowane ani przekazywane do żadnej strony nadrzędnej.

Inną techniką jest używanie unikalnych i krótkotrwałych adresów URL. W ten sposób, nawet jeśli przeciekają, nie ma to większego znaczenia. Oczywiście musisz aktualizować legalnych użytkowników nowych adresów URL.

— Ladadadada
źródło

+1 za wzmiankę o paskach narzędzi przeglądarki.

— Hubert Kario

23

Nie, nie do końca, to tylko bezpieczeństwo poprzez zaciemnienie, które w ogóle nie jest zabezpieczeniem. Wszystko, co jest bezpośrednio dostępne z Internetu bez jakiejkolwiek formy prawdziwej ochrony, zostanie znalezione, zindeksowane i zapisane w pamięci podręcznej.

— użytkownik9517
źródło

10

Czy i tak wszystkie hasła nie są po prostu zabezpieczeniem przez zaciemnienie?

— Winston Ewert

4

@WinstonEwert: Same hasła nie mają nic wspólnego z bezpieczeństwem poprzez niejasność, która dotyczy tajemnicy projektowania / wdrażania. Na przykład w przypadku podstawowego uwierzytelniania Apache jego projekt / implementacja jest w pełni otwarta dla wszystkich.

— user9517

10

nonsens - wszystko jest bezpieczeństwem poprzez niejasność. Chodzi o to, że aby się tam dostać, potrzebujesz pewnej informacji, która jest mało prawdopodobna do odgadnięcia. Wyrażenie „Bezpieczeństwo przez zaciemnienie” jest nadmiernie nadużywane. Losowy fragment adresu URL jest dokładnie równoważny z umieszczeniem „hasła” w adresie URL. Jedyne pytanie brzmi - kto to widzi, a odpowiedź, którą wpisuję w moim komentarzu, brzmi: „pośredni proxy, plus to http, więc każdy, kto może węszyć”

— Bron Gondwana

1

Jeden błąd (lub powrót do konfiguracji domyślnej) w konfiguracji apache, a twoje katalogi pokazują indeksy ze wszystkimi plikami i katalogami na twojej dłoni, nie tyle z hasłami.

— Hubert Kario

4

Mówisz, że bezpieczeństwo poprzez niejasność „dotyczy tajemnicy projektowania / wdrażania”. Ale oczywiście losowe adresy URL nie wiążą się z tajemnicą projektowania / wdrażania. Tak więc losowe adresy URL, bez względu na ich wady, nie mogą być klasyfikowane jako bezpieczeństwo przez zaciemnienie.

— Winston Ewert

6

Będą oni zalogowani w każdym proxy po drodze. Będziesz bezpieczny od ciekawskich zaawansowanych użytkowników i wyszukiwarek, chyba że ktoś faktycznie opublikuje link.

I oczywiście uważaj na losowość generatora.

Zgaduję, że nie szukasz tutaj super-wysokiego bezpieczeństwa.

— Bron Gondwana
źródło

Jeśli ktoś opublikuje adres URL, nic nie powstrzyma go przed opublikowaniem hasła. Uwierzytelnianie przez wiedzę jako czynnik zawsze może zostać „oszukane” w ten sposób.

— Manuel Faux

@ManuelFaux: Jasne, jeśli to celowe. Ale może być również przypadkowy. Na przykład może użyć narzędzia, które sprawdza odwiedzane adresy URL, aby sprawdzić, czy zostały zgłoszone jako złośliwe. Narzędzia wiedzą, że hasła powinny być trzymane w tajemnicy. Wiedzą, że parametry w adresach URL mogą być wrażliwe. Ale nie wiedzą, że ścieżki w adresach URL tak. (Na przykład odsyłacz http .)

— David Schwartz

5

Zaszyfrowany adres URL jest przydatny do jednorazowego pobrania, ale nie zapewnia rzeczywistej ochrony. Musisz pamiętać, że nie wszystkie boty honorują plik robots.txt, więc jeśli w Twojej witrynie jest jakikolwiek link prowadzący do ukrytego folderu, zostanie on zindeksowany przez niektóre wyszukiwarki, a po uruchomieniu nie będzie powrotu.

Sugerowałbym użycie prostego systemu uwierzytelniania opartego na .htaccess zamiast lub oprócz tego, co proponujesz.

— John Gardeniers
źródło

5

Chciałbym dodać inną, może bardziej przerażającą perspektywę zaciemnionych adresów URL, takich jak ten przykład. Nawet jeśli Twój adres URL nie zostanie przypadkowo udostępniony, może zostać przesłany do wyszukiwarek przez:

ISP odwiedzającego. Wizyty HTTP są gromadzone, analizowane, a czasem wręcz sprzedawane stronom trzecim przez dostawców usług internetowych.
Cloud Storage dla odwiedzających. Istnieje wiele usług przechowujących zakładki i historię do bezpłatnej synchronizacji między instalacjami przeglądarki. O ile nie zaszyfrują danych tak jak Mozilla, można implikować te same praktyki eksploracji danych.

YMMV.

— Korkman
źródło

o tak - lub po prostu przez wtyczkę do przeglądarki, która wyszukuje pokrewne strony lub pozwala użytkownikom na udostępnianie notatek o stronie

— Bron Gondwana

2

W przeszłości korzystałem z podobnej metody, aby umożliwić użytkownikom tworzenie przestrzeni współdzielonych w systemie zarządzania dokumentami. Udostępniane treści nie były ściśle tajne, więc system nie musiał być bardzo bezpieczny.

Właśnie sprawiłem, że adres URL każdego użytkownika zawiera znacznik czasu wygaśnięcia i MD5 ich wiadomości e-mail.

SO URL wyglądał następująco:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

z powyższym, jeśli użytkownik wprowadzi adres e-mail użytkownik@gmail.com przed 30 lipca, będzie dobrze.

Nie do końca wojskowy poziom bezpieczeństwa, ale zadziałał.

— Dave e
źródło

0

Działa to tak samo, jak przechowywanie sessionID w adresie URL. Ktoś może przypadkowo skopiować i wkleić link do innych, zapomnieć cenzurować go na zrzucie ekranu lub pozwolić komuś na sprawdzenie go, ponieważ nie jest on oznaczony gwiazdką jak hasła.

Ponadto, jeśli niektóre treści są chronione hasłem, po zalogowaniu się wiesz, że jest to tajemnica. Jeśli otrzymasz link, możesz łatwo go zapomnieć.

Kolejną rzeczą jest usunięcie uprawnień użytkownika. Możesz usunąć użytkownika, aby nie mógł się już zalogować, ale z linkami Musisz zmienić je wszystkie i wysłać wszystkim (oprócz usuniętego użytkownika) nowe adresy URL.

Myślę, że nie jest źle, jeśli są to tylko obrazy. Ale jeśli są to zdjęcia, które naprawdę, naprawdę nie lubisz dzielić;), sugeruję, abyś użył dłuższego losowego słowa, bardziej jak ten przedstawiony.

EDYCJA: Dodaj? DO_NOT_SHARE_THIS_LINK do adresu URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-to- powinien- być- dłuższy-/Dzięki?

Tak właśnie działa Kongregate, osadzając gry hostowane gdzie indziej (umieszcza dane uwierzytelniające w adresie URL ramki). BTW, Kongregate korzysta również z linków dostępu gości do niepublikowanych gier, dokładnie tak, jak chcesz.

— Markus von Broady
źródło

W rzeczywistości jest znacznie gorzej niż identyfikatory sesji, ponieważ sesje wygasają po pewnym czasie. Wyszukiwarki pobierające zalogowany identyfikator sesji zwykle kończą się prezentowaniem martwego linku / niezalogowanej sesji w wynikach. Lub, jeśli serwer nie dba o to, może zsynchronizować sesję wielu użytkowników, a gdy jeden z nich się zaloguje, wszyscy tak robią. W każdym razie, nie tak źle, jak trwale zalogowany adres URL :-)

— korkman

Oczywiście jest gorzej i możesz również zapamiętać adres IP w sesji, ponieważ najpierw musisz się zalogować, aby uzyskać adres URL sessid, a następnie możesz zniszczyć sesję, jeśli adres IP się zmieni.

— Markus von Broady,