Sicurezza dell'API basata su token su richieste ripetute di nome utente / password

Naviga le tue risposte
2

Quali sono i vantaggi per la sicurezza rispetto a un modello di sicurezza dell'API basato su token rispetto all'invio del nome utente & password ogni volta?

Il processo dell'approccio basato su token è:

  1. Invia una richiesta di "accesso" con nome utente e password
  2. Ricevi un token
  3. Utilizza il token al posto del nome utente / password per tutte le richieste successive

I vantaggi di un sistema basato su token (in base a questo link ) sono:

  • Scalabilità
  • Tecnologia ad accoppiamento lento
  • Mobile friendly

Tuttavia, non sono sicuro del motivo per cui questi vantaggi sono specifici per un approccio basato su token piuttosto che inviare lo username / password ogni volta? Non è altrettanto facile aggiungere successivamente i server Web a un cluster? La verifica della password viene ancora eseguita in entrambi i casi, quindi il lato client è altrettanto sciolto?

Vantaggi? È semplicemente che il nome utente / password non devono essere "controllati" ogni volta e possiamo fare una ricerca più semplice basata su un elenco di chiavi di sessione? Mentre questo è un miglioramento delle prestazioni, aggiunge una maggiore complessità all'applicazione client e ulteriori complessità se c'è un timeout sul token in cui il client dovrebbe controllare se il token è ancora valido?

Svantaggi? Gli svantaggi con un nome utente / password inviati con ogni richiesta che con sempre più trasmissioni di questi dati diventa più probabile che possa essere scoperto? In tal caso, HTTPS non è abbastanza robusto da contrastare questa minaccia?

EDIT: Ho letto questo potenziale duplicato: Perché utilizzare un token di autenticazione al posto del nome utente / password per richiesta?  ma sono un po 'insicuro perché il punto 2 afferma che il nome utente / password verrebbero memorizzati come cookie. Perché il computer client dovrebbe mantenere il nome utente / password come cookie e non includerlo nel contenuto del post stesso?

    
posta JLo 20.02.2017 - 11:26
fonte

2 risposte

1

Why would the client machine keep the username/password as a cookie and not include it in the post content itself?

Mantenendo il nome utente / password (o il token) in un contenuto del post, localStorage o sessionStorage espone questo contenuto a un attacco XSS. Consulta questo articolo. Anche se l'articolo riguarda un token, lo stesso principio vale per qualsiasi credenziale (incluso nome utente / password). Altri riferimenti su questo qui . Se memorizzi tali informazioni in un cookie httpSolo, il contenuto non è disponibile per JavaScript e quindi teoricamente imune su un attacco XSS. Una volta che hai le tue credenziali in un cookie, sei aperto a un attacco CSRF e devi gestirlo.

La risposta alla tua domanda collegata è corretta.

Vorrei aggiungere un altro vantaggio per il token: scadenza. Se le credenziali di username / password vengono rubate, potrebbe essere difficile rilevarle. I token scadranno a un certo punto e l'utente dovrà registrarsi per poterne disporre uno nuovo. Questo limita il lasso di tempo in cui un token rubato può essere utilizzato per l'autenticazione sul server. In caso di credenziali username / password, non esiste tale limite o è più grande (la politica di scadenza della password è di solito un mese o più in cui un token può essere impostato per scadere in minuti o giorni)

    
risposta data 21.02.2017 - 17:25
fonte
0

Nome utente / password

  • Non è una buona idea inviare credenziali con ogni richiesta API. Anche se si inviano credenziali su ssl / tls (non fornisce un tunnel sicuro end-end, vulnerabilità note !!), ci sono alte probabilità che il client sia vittima di attacchi MITM (livello Lan / Wifi, livello ISP, livello Paese) .

  • Nome utente (nome, email) / password (non troppo complessi) sono facilmente ipotizzabili. Sicuramente non vorresti che i tuoi utenti inserissero password di 21+ caratteri, giusto? per una migliore esperienza utente!

Basato su token

  • 1 token (con tempo di scadenza fino alla disconnessione dell'utente) è uguale a Username / Password

  • Dovresti provare a implementare Oauth, JWT o lo schema di accesso / aggiornamento dei token personalizzati. Questo approccio non fornirà più sicurezza se lo implementate in modo errato.

Con i token, puoi fornire agli utenti una trasparenza di gestione delle sessioni più flessibile.

Ex: -

  • Elimina la sessione remota (lascia scadere il token!)
  • Rinnova la sessione corrente (rinnova il token di accesso tramite il token di aggiornamento!)
  • Tieni traccia di tutte le sessioni attive
  • Token (Random + length) non è facile da bruteforce.

Non parlerò di scalabilità e altri vantaggi qui. Ma sì, puoi scalare il tuo servizio con l'approccio basato su token :-) Apri em up per il consumo di terze parti.

    
risposta data 20.02.2017 - 16:01
fonte

Leggi altre domande sui tag

Come viene utilizzato il tag QSS come carico utile in un attacco XSS? Comprensione dell'output di nmap / spiegazione dell'autore ... (Scapy)