Qualche motivo per utilizzare l'autenticazione "Basic HTTP"?

10

Sto costruendo una semplice API che verrà utilizzata in un'app Android (che solo circa 3-4 utenti avranno mai). L'app si collega al server e invia richieste GET / PUT.

Ho letto il mio googling che se stai usando SSL, l'invio delle password come testo in chiaro senza crittografarle con qualcosa come HMAC è OKAY.

Le persone, tuttavia, consigliano di utilizzare "autenticazione di base" che è fondamentalmente username: password codificata in base64 nell'intestazione HTTP. C'è una ragione per cui non dovrei semplicemente inviare i campi del corpo "username" e "password" non codificati se sto usando SSL? Se un hacker doveva davvero passare attraverso l'SSL, perché avrebbe importanza se fosse codificato usando base64? Sicuramente se è in grado di superare in qualche modo l'SSL, sarebbe in grado di decodificare base64?

Volevo solo le tue opinioni su se dovessi anche preoccuparmi di fare codifica in base64, grazie.

    
posta Shivang Saxena 13.06.2015 - 02:25
fonte

2 risposte

8

Il punto di differenza tra l'utilizzo dell'autenticazione HTTP e dell'autenticazione specifica dell'applicazione è il punto in cui si desidera gestire la logica di autenticazione e autorizzazione.

Autenticazione HTTP significa che il livello HTTP (apache, nginx, IIS, ecc.) sarà responsabile della gestione dell'autenticazione. Autorizzazione dell'applicazione significa che l'applicazione web (java, php, django, ecc.) Controllerebbe l'autenticazione e l'autorizzazione.

Perché la differenza?

Ricorda che HTTP è senza stato. Pertanto, aggiungendo un componente di autorizzazione, HTTP può impedire o consentire agli utenti di accedere a determinate risorse. L'uso più probabile di questo tipo di autorizzazione è quando non si dispone di alcuna logica dell'applicazione. Ad esempio, se si desidera consentire l'esplorazione della directory di file in apache, ma solo per determinati utenti, è possibile modificare il file .htaccess per limitare la directory a determinati utenti.

Tuttavia ci sono molte ragioni per cui le applicazioni gestiscono la logica di autorizzazione invece del server HTTP. Innanzitutto, la maggior parte delle applicazioni gestisce le sessioni. Questo viene fatto usando i cookie. Pertanto, solo il valore del cookie deve essere ritrasmesso. Se gestisci sessioni nel livello applicazione, sarà quasi sempre più facile gestire l'autorizzazione anche in questo livello. Quasi sempre, le sessioni sono preferite perché il contenuto della tua applicazione dipenderà da "chi "sta facendo qualcosa.

Ma la mia applicazione può leggere le intestazioni HTTP, perché utilizzare i moduli se HTTP fornisce un meccanismo?

Un ulteriore vantaggio dell'utilizzo delle sessioni include l'implicita capacità di disconnessione. Poiché l'autorizzazione HTTP non ha alcun concetto di sessione, non puoi davvero effettuare il logout. Spetterebbe al browser (o nel tuo caso, l'applicazione Android) dimenticare le credenziali, ma il server non ha il controllo su di esso. Anche se il tuo server vuole imporre una sorta di disconnessione, non può farlo con l'autorizzazione HTTP.

Vantaggi per la sicurezza dell'autenticazione basata su modulo

Poiché l'autenticazione basata su modulo generalmente implica sessioni, di solito è più sicura, a condizione che la sicurezza delle risorse dipenda dalle sessioni.

Vantaggi per la sicurezza dell'autenticazione HTTP

L'autenticazione di base HTTP è peggiore dell'autenticazione basata su moduli a causa della mancanza di sessioni. Tuttavia, è possibile ottenere alcuni vantaggi utilizzando l'autenticazione HTTP Digest, che calcola gli hash contro le credenziali e gli spegni per evitare l'invio di credenziali di testo. Pertanto, esiste un compromesso tra l'invio di credenziali chiare o l'attivazione da parte del server dell'applicazione della sessione.

Non posso calcolare gli hash sul lato client prima di trasmettere le credenziali?

Per le applicazioni basate su browser, molte persone pensano che usare javascript per calcolare un hash prima di inviare una credenziale sia meglio che usare una password in testo semplice, ma queste persone hanno torto. Per proteggere la password, il server invia il codice client che deve essere eseguito. Tuttavia, se un utente malintenzionato è in grado di parlare con il cliente, può sostituire questo codice per conto suo. Pertanto, il vantaggio di sicurezza dell'utilizzo di javascript per calcolare un hash è così minimo che raramente viene eseguito.

Dato che hai menzionato l'utilizzo di questa API in un'applicazione Android, l'hashing ha senso. Poiché è possibile calcolare l'hash con una routine client predefinita, ci sono chiari vantaggi nell'utilizzo di un meccanismo di hashing come descritto in RFC 2607 . Ti consiglio comunque di eseguire l'autorizzazione nel livello dell'applicazione, poiché desideri gestire le sessioni per un utente.

    
risposta data 13.06.2015 - 04:37
fonte
3

Mi piace dire alle persone che "HTTP Basic Auth è deprecato, non usarlo!" a favore dell'autenticazione basata su form. Tuttavia, rispetto a SSL è effettivamente sicuro in transito e non vulnerabile a intercettazioni facili. A livello di browser, l'autenticazione basata su moduli tende ad essere più sicura. Per un'app Android che utilizza un'API REST, consiglierei un sistema basato su token. Tuttavia, non direi che l'autenticazione di base su SSL non è sicura; Lo definirei "a malapena accettabile".

Lo scopo di hashing della password con qualcosa come SHA256-HMAC non è solo quello di proteggere la password in transito. In questo caso il server riceve solo l'hash della password e lo sta confermando. In tal modo, l'hash è in effetti la password. HMAC aggiunge ulteriore sicurezza oltre a impedire a un utente malintenzionato di inviare facilmente lo stesso hash.

L'hashing della password garantisce che il server non sappia mai quale sia la password dell'utente. Quindi, se il database viene rubato, le password dell'utente almeno non possono essere decodificate.

Nota che una corretta implementazione di questo richiede "salting" degli hash con un sale unico per utente per prevenire un attacco usando "rainbow tables". Esegui questa ricerca se prevedi di implementare l'hashing della password.

    
risposta data 13.06.2015 - 03:09
fonte

Leggi altre domande sui tag