Include un GUID segreto in un URL Security Through Obscurity?

Cercherò di rispondere alla domanda stessa senza tenerti informato su cosa usare e cosa non usare.

Considerando le tue ipotesi (che sono ipotesi abbastanza audaci, IMO)

• SSL è usato.
• Nessuna registrazione ovunque.
• I GUID non sono facilmente prevedibili.
• La password è strong.

Quindi no, questa non è sicurezza per oscurità. Questa è sicurezza, beh, sicurezza. La tua sicurezza dipende dall'incapacità dell'attaccante di indovinare / conoscere la password, e non dall'incapacità dell'attaccante di indovinare / sapere come funziona il tuo sistema. La tua password è, in qualche modo, la tua chiave. Finché la tua sicurezza dipende dalla tua chiave, stai bene.

Ora, temo che tu stia tentando qualcosa come memorizzare directory sul tuo server con quei GUID e password e quindi collegarti alle risorse all'interno di quelle directory. In tal caso, assolutamente no! Non farlo! Le password non dovrebbero essere trattate in questo modo.

Sicurezza attraverso l'oscurità significa violare Principio di Kerckhoffs , che può essere riassunto in questo modo: presupponi che tutta l'intelligenza sia pubblica e tenga la casualità privata.

Questo significa che la tua sicurezza non deve essere danneggiata rendendo pubblico il tuo protocollo. D'altra parte, mantenere una password privata è l'intero punto di una password.

Dovresti essere in grado di quantificare quante conoscenze manca all'attaccante. Questo è impossibile con un protocollo, non puoi misurare quanto sia difficile per l'attaccante capirlo. Questo è eminentemente possibile per una password: è l'entropia che è andata a generarlo.

Uno schema la cui sicurezza dipende dalla segretezza di una password non è mai segretezza per oscurità. La generazione della password può essere protetta dall'oscurità (se la password viene scelta per essere intelligente anziché casuale), ma l'uso della password non lo è.

La scelta tra le tue due proposte dipende esclusivamente da ciò che il client e il server faranno con l'URL. Si noti che per client e server, intendo tutto su entrambi i lati della connessione SSL; se hai un server front-end che decodifica la richiesta HTTPS e la inoltra a un back-end, fanno entrambe parte del server.

Includere un segreto all'interno di un URL al di fuori del campo della password (e talvolta anche nel campo della password) di solito è sbagliato perché l'URL può finire in molti registri, sia sul lato client (cronologia del browser) che sul lato server. Se la richiesta proviene dalla tua applicazione anziché attraverso un browser, questa è una cassastrong. È necessario dare uno sguardo attento al lato server, sia come è ora, sia come potrebbe evolversi in futuro. Ci sono dei log? Quali informazioni includono? Come sono protetti i registri? Dove viene eseguito il backup?

Riguardo all'uso dei GUID: mentre alcune API di Windows forniscono GUID "kinda-random-ma-actually-predictable", ci sono pochi motivi per usarli. Attenersi agli UUID casuali (versione 4), utilizzando un buon generatore di numeri casuali con entropia adeguata. Se non hai una funzione di libreria adatta, genera 128 bit casuali e se hai bisogno di UUID conformi a RFC, applica la maschera uuid[6] = (uuid[6] & 0x0f) | 0x40; uuid[8] = (uuid[8] & 0x3f ) | 0x80; .

Vediamo se è possibile suddividere questo:

1. Stai usando SSL che è buono. SSL crittografa tutti i dati inviati, compreso l'URL. Tuttavia SSL protegge solo i dati mentre è in transito. Significato su server e client, i dati potrebbero essere leggibili.
2. Se si dispone di un token di sicurezza (nome utente / password, chiave generata in modo casuale o altro) e lo si trasmette in modo sicuro (ad esempio SSL, vedere il punto 1), per qualcuno che cerca di intercettare i dati non farà alcuna differenza il blocco dati crittografato è memorizzato. Non possono vederlo.
3. È necessario comprendere appieno come il server gestisce i dati (ora decrittografati) che riceve. Come le altre risposte citate, un tipico server http registrerà gli URL che riceve. Questo e qualsiasi altra cosa che il server fa con l'URL diventa una fonte di potenziale perdita di dati.
4. È inoltre necessario comprendere appieno come funziona il client (e le eventuali librerie del sistema operativo in uso), per garantire che non perdano il token di sicurezza (indipendentemente da dove lo si archivia nei dati). Se il client è o meno un browser è in gran parte irrilevante per la tua domanda
5. Non puoi davvero fidarti del cliente. Se il client conosce il token di sicurezza, allora presume che anche l'utente lo faccia. Generalmente questo non è un problema con un nome utente e una password normali, ma se si utilizza una chiave condivisa tra più utenti non è possibile revocare facilmente l'accesso.

In breve, è necessario sapere dove (e in quale stato) i dati sono sempre. Sia durante il trasporto che durante il riposo. Se capisci che puoi decidere quali rischi vuoi preoccupare o se necessiti di ulteriore attenuazione.

La premessa di base per il passaggio di un token di sicurezza nell'URL su HTTPS non è la sicurezza attraverso l'oscurità. Tuttavia, potrebbe non essere ancora una buona idea e ci sono probabilmente modi migliori per fare ciò che vuoi fare.

Sulla base di uno dei tuoi commenti sembra che tu stia creando un URL tale che conoscere l'URL di un dato non metta a rischio l'url di altre parti dei dati (qualsiasi chiave casuale lunga potrebbe funzionare). A seconda di quali sono i tuoi obiettivi generali, questo può essere adatto (ho lavorato con il software che lo fa), ma non lo considererei come una password.

Il precedente formato <user>:<password>@<host> è deprecato e non è supportato da tutti i principali browser , quindi non utilizzarlo. Tuttavia, i browser che lo supportano convertono tale URI HTTP in una richiesta con Autenticazione di base HTTP .

Quindi la tua domanda dovrebbe piuttosto riguardare l'autenticazione di base HTTP e i parametri URI tramite HTTPS. Lo svantaggio principale di quest'ultimo è che l'URL richiesto può apparire in diverse posizioni, ad esempio i file di registro del server Web, la cronologia del browser, il referrer HTTP, ecc., Che può comportare la divulgazione delle credenziali utilizzate. Quindi, di nuovo, non farlo.

Utilizza invece l'autenticazione HTTP di base o Digest, o qualche altro schema di autenticazione provato.

Lo schema URL username / password ha la possibilità di crittografare quei valori per la trasmissione mentre la normale richiesta get non lo fa. Comunque tu mostri lo schema HTTPS così non vedo alcun problema.

Un difetto è forse un utente che vorrebbe inserire un segnalibro in uno dei suoi URL, che potrebbe non essere protetto e quindi essere afferrato da qualcuno. Il primo schema consente un segnalibro senza la combinazione nome utente / password. Solo un pensiero.

Il tuo secondo schema sembra simile all'invio di credenziali di accesso su un modulo utilizzando GET anziché POST. Nessuno lo fa davvero. È meno sicuro? Forse, ma non ci sono ragioni concrete per cui sia così. Le persone preferiscono il POST solo perché è più "nascosto" nella transazione HTTP.

Un pensiero finale, è buono per seguire le pratiche standard. La sicurezza dall'oscurità è grande contro un attacco ampio, ma un attacco mirato ti farà brindare. Le best practice hanno la possibilità di proteggerti da fattori esterni non correlati al protocollo HTTP come l'ingegneria sociale per acquisire nomi utente e password. L'attenzione alla sicurezza non dovrebbe essere troppo stretta.