va bene usare URL casuali invece di password? [chiuso]

12

È considerato "sicuro" usare un URL creato da caratteri casuali come questo?

http://example.com/EU3uc654/Photos

Vorrei mettere alcuni file / gallerie di immagini su un server web a cui può accedere solo un piccolo gruppo di utenti. La mia preoccupazione principale è che i file non debbano essere raccolti dai motori di ricerca o da curiosi utenti esperti che frugano nel mio sito.

Ho impostato un file .htaccess, solo per notare che fare clic sui http://user:pass@url/collegamenti non funziona bene con alcuni browser / client di posta elettronica, che richiede finestre di dialogo e messaggi di avviso che confondono i miei utenti non troppo esperti di computer.

— stufato
fonte

No. Puoi usarlo, ma non come l'unico o principale meccanismo di autenticazione.

— Andrew Smith,

1

L'ho provato molte volte come esperimento, e ogni volta i link finiscono nei motori di ricerca. Non so come, ma so che succede.

— David Schwartz,

Potresti voler configurare SSL per interrompere gli avvisi, puoi ottenere certificati gratuiti da startsl.com e SSL non è più intensivo dal punto di vista computazionale (purché configurato correttamente).

— Hubert Kario,

Questa domanda è un classico esempio "Non costruttivo". Non sappiamo quanto apprezzi la sicurezza delle tue foto. L'unico modo in cui è possibile comunicare l'importanza della sicurezza è la metodologia di autorizzazione implementata per proteggere l'accesso a tali immagini. Ciò che hai ottenuto sono "argomenti di dibattito" sotto forma di "Risposte". Ma nessuno di loro è un sondaggio completo delle moderne implicazioni di sicurezza e tecniche. Dovresti leggere i metodi di sicurezza forniti dalla tua piattaforma e valutare il valore di ciascuno per la tua situazione; se hai ulteriori domande una volta che lo hai fatto, quindi chiedilo di nuovo.

— Chris S

17

Se va bene o no dipende dalla sensibilità delle immagini.

Se non si utilizza SSL, gli URL, l'HTML e le immagini stesse verranno memorizzati nella cache dei computer dell'utente. Ciò potrebbe fuoriuscire, ma lo riterrei improbabile.

Le barre degli strumenti del browser, in particolare quelle create da aziende che eseguono crawler, come Alexa e Netcraft, possono riportare gli URL visitati ai loro siti padre, pronti per il bot che verrà e scansionerà in seguito.

L'autenticazione corretta come l'autenticazione HTTP o una variabile POST non dovrebbe essere memorizzabile in questo modo o riportata su qualsiasi sito Web principale.

Un'altra tecnica consiste nell'utilizzare URL unici e di breve durata. In questo modo, anche se perdono, non importa molto. Ovviamente, devi continuare ad aggiornare i tuoi utenti legittimi dei nuovi URL.

— Ladadadada
fonte

+1 per menzionare le barre degli strumenti del browser.

— Hubert Kario,

23

No, non proprio, questa è solo sicurezza attraverso l'oscurità che non è affatto sicurezza. Tutto ciò che è direttamente accessibile da Internet senza alcuna forma di protezione reale verrà trovato, indicizzato e memorizzato nella cache.

— user9517
fonte

10

Le password non sono solo sicurezza attraverso l'oscurità comunque?

— Winston Ewert,

4

@WinstonEwert: le password stesse non hanno nulla a che fare con la sicurezza attraverso l'oscurità che si riferisce alla segretezza della progettazione / implementazione. Nel caso, ad esempio, dell'autent di base di Apache, la sua progettazione / implementazione è completamente aperta a tutti.

— user9517

10

assurdità: tutto è sicurezza attraverso l'oscurità. Il punto è che per arrivarci è necessario disporre di un'informazione sufficientemente improbabile da essere indovinabile. La frase "Sicurezza attraverso l'oscurità" è ampiamente abusata. Un pezzo casuale di URL equivale esattamente a inserire una "password" nell'URL. L'unica domanda è: chi può vederlo e la risposta che ho inserito nel mio commento è "proxy intermedi, in più è http, quindi chiunque può curiosare"

— Bron Gondwana,

1

Un errore (o ritorno alla configurazione predefinita) in apache config e le tue directory mostrano gli indici con tutti i file e le directory sul palmo della tua mano, non tanto con le password.

— Hubert Kario,

4

Dici che la sicurezza attraverso l'oscurità "si riferisce alla segretezza della progettazione / implementazione". Ma chiaramente, gli URL casuali non mettono in relazione la segretezza della progettazione / implementazione. Pertanto, gli URL casuali, qualunque siano i loro difetti, non possono essere classificati come sicurezza attraverso l'oscurità.

— Winston Ewert,

6

Saranno registrati in ogni proxy lungo la strada. Sarai al sicuro da curiosi utenti esperti e motori di ricerca a meno che qualcuno non pubblichi effettivamente il link.

E attenzione alla casualità del tuo generatore, ovviamente.

Immagino che tu non stia cercando una sicurezza altissima qui.

— Bron Gondwana
fonte

Se qualcuno pubblicasse l'URL, nulla gli impedirebbe di pubblicare una password. L'autenticazione mediante la conoscenza come fattore può sempre essere "ingannata" in questo modo.

— Manuel Faux,

@ManuelFaux: Certo, se è intenzionale. Ma può anche essere accidentale. Ad esempio, può utilizzare uno strumento che controlla gli URL visitati per vedere se sono stati segnalati come dannosi. Gli strumenti sanno che le password dovrebbero essere mantenute segrete. Sanno che i parametri negli URL possono essere sensibili. Ma non sanno che i percorsi negli URL lo fanno. (Ad esempio, referer http .)

— David Schwartz

5

Un URL criptico è utile per i download monouso ma non fornisce alcuna protezione reale. Devi essere consapevole del fatto che non tutti i robot onorano il file robots.txt, quindi se c'è qualche link in qualsiasi punto del tuo sito che porta alla cartella mascherata verrà indicizzato da alcuni motori di ricerca e una volta avviato non potrà tornare indietro.

Suggerirei invece di utilizzare un semplice sistema di autenticazione basato su .htaccess o in aggiunta a ciò che stai proponendo.

— John Gardeniers
fonte

5

Vorrei aggiungere un'altra prospettiva, forse più spaventosa, su URL offuscati come questo esempio. Anche se il tuo URL non viene accidentalmente condiviso, può essere inviato ai motori di ricerca tramite:

ISP di un visitatore. Le visite HTTP vengono raccolte, archiviate e talvolta vendute addirittura a terzi dagli ISP.
Cloud Storage di un visitatore. Esistono numerosi servizi che memorizzano segnalibri e cronologia gratuitamente per la sincronizzazione tra le installazioni del browser. A meno che non pre-crittografino i dati come fa Mozilla, le stesse pratiche di data mining possono essere implicite.

YMMV.

— Korkman
fonte

oh sì - o semplicemente da un plug-in del browser che cerca siti correlati o consente agli utenti di condividere note su una pagina

— Bron Gondwana,

2

In passato ho usato un metodo simile per consentire agli utenti di creare spazi di condivisione su un sistema di gestione dei documenti. Il contenuto condiviso non era un segreto, quindi il sistema non doveva essere ultra sicuro.

Ho appena creato l'URL di ciascun utente contenente un timestamp di scadenza e un MD5 della sua e-mail.

Quindi l'URL sembrava:

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

con quanto sopra, se l'utente ha inserito l'e-mail user@gmail.com prima del 30 luglio, sarebbe bello andare.

Non esattamente sicurezza di livello militare, ma ha fatto il lavoro.

— dave e
fonte

0

Questo condivide la stessa vulnerabilità dell'archiviazione di sessionID nell'URL. Qualcuno può copiare e incollare accidentalmente il collegamento su altri, dimenticare di censurarlo in uno screenshot o lasciare che qualcuno lo cerchi, poiché non è asterisco come una password.

Inoltre, se alcuni contenuti sono protetti da password, accedendo Sai che è un segreto. Se ottieni un link, puoi facilmente dimenticarlo.

Un'altra cosa è rimuovere i privilegi dell'utente. Puoi eliminare un utente, in modo che non possa più accedere, ma con i link Dovresti modificarli tutti e inviare a tutti (tranne l'utente eliminato) nuovi URL.

Penso che non sia male se queste sono solo immagini. Ma se queste sono alcune immagini che non vorresti davvero condividere;) allora ti suggerisco di usare parole casuali più lunghe, più simili a quelle presentate.

EDIT: Aggiungi? DO_NOT_SHARE_THIS_LINK all'URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos?DO_NOT_SHARE_THIS_LINK

Questo è ciò che fa ad esempio Kongregate quando si incorporano giochi ospitati altrove (inserisce le credenziali di autenticazione nell'URL del frame). A proposito, Kongregate utilizza anche i collegamenti di accesso ospite per i giochi non pubblicati, proprio come si desidera utilizzare.

— Markus von Broady
fonte

In realtà è molto peggio degli ID di sessione, perché le sessioni scadono dopo un po 'di tempo. I motori di ricerca che ottengono un ID di sessione registrato di solito finiscono per presentare un link non funzionante / sessione non registrata nei risultati. Oppure, se al server non interessa, potrebbe sincronizzare la sessione di molti utenti e quando uno di essi accede, lo fanno tutti. Comunque, non male come un URL registrato in modo permanente :-)

— korkman

Ovviamente è peggio, e potresti anche ricordare l'IP in sessione poiché devi prima accedere per ottenere il sessid in url, quindi puoi distruggere la sessione se l'IP è cambiato.

— Markus von Broady,