Autenticazione di base estesa

Naviga le tue risposte
2

Vorrei implementare un'API REST con l'autenticazione di base che si basa su nome utente e password. Poiché REST è senza stato, l'utente dovrebbe immettere nuovamente nome utente e password per ogni richiesta senza memorizzarli in un cookie. Poiché la memorizzazione di nome utente e password in un cookie non è un'opzione, è necessaria un'altra soluzione.

Lo scenario che sto pensando sarà il seguente:

  1. L'utente passa al link
  2. L'utente inserisce nome utente e password (crittografati con SSL).
  3. Il sistema verifica se le credenziali fornite sono corrette.
  4. Se corretto: il sistema genera un GUID, crittografa il GUID con la password dell'utente e lo invia all'utente.
  5. Se non è corretto: aumenta FailedPasswordAttemptCounter e controlla se l'accesso deve essere bloccato per l'utente.

Poiché la risposta del server al client non è crittografata, il GUID è crittografato con la password dell'utente. Solo l'utente è in grado di decodificare il GUID.

L'utente fornisce il GUID per tutte le altre risorse che necessitano di autenticazione invece di nome utente e password.

Questo approccio è migliore rispetto alla fornitura di nome utente e amp; password per ogni richiesta?

Sono consapevole del fatto che qualcuno è in grado di generare GUID e tenta di autenticarsi con loro. Ma un attacco mirato a un utente specifico è quasi impossibile in quanto la risorsa di accesso fornisce un meccanismo di blocco.

La mia domanda è in qualche modo correlata a questo: link

    
posta niklr 03.08.2013 - 20:15
fonte

1 risposta

4

Because REST is stateless the user would have to reenter username and password for every request

È direttamente contraddittorio per

The user provides the GUID for all other resources which needs authentication instead of username and password.

Puoi:

A. invia la password ad ogni richiesta, o
  B. non inviare la password ad ogni richiesta.

Ma dovrai sceglierne uno.

Ecco lo scenario ideale. È vicino a ciò che stai descrivendo:

  1. L'utente esegue l'accesso. Nome utente, password, token di autenticazione, qualsiasi cosa.
  2. Il server memorizza quell'evento di autenticazione lato server e crea un token casuale (GUID o qualsiasi altra cosa desideri) da fornire al client
  3. Quando il cliente desidera inviare la sua richiesta, invia anche il token che lo identifica al server. Potrebbe trovarsi in un cookie, nell'URL, in una variabile di modulo, in un'intestazione separata. Non importa Ovunque nella richiesta va bene.
  4. Il server espira il token dopo che non è più necessario utilizzarlo. Forse è buono per 5 minuti, forse è buono fino a quando non è stato utilizzato per un'operazione. Forse è buono fino a quando non passa inutilizzato per 5 minuti. Qualunque cosa tu voglia.
risposta data 03.08.2013 - 22:18
fonte

Leggi altre domande sui tag

Qual è il risultato ottimale per la questione del brevetto sulla curva ellittica? Perché alcune password non consentono determinati tipi di caratteri?