Frontend JS per backend RESTful vs autorizzazione

Naviga le tue risposte
1

Sto costruendo web-app. E ho preoccupazioni per i problemi di sicurezza.

Nel mondo molte domande simili, ma molte di esse non hanno una risposta chiara (consiglio, suggerimento). Questo è il motivo per cui ho fatto questa domanda.

Ho una pagina di accesso con nome utente e password. L'utente li eseguirà tramite HTTPS. Il server lo confronterà con il nome utente e la password del DB e se tutto è a posto, genererà access_token usando un approccio specifico come: sha1(username + password + expiration_date) , btw, expiration_date è Unix l'ora di scadenza del token. Nel risultato expiration_date e access_token saranno scritti in DB nel record utente correlato, access_token verrà sicuramente inviato all'app JavaScript JavaScript da HTTPS.

Quindi tutte le richieste dall'app client verranno eseguite da HTTPS e access_token verrà incluso in ogni richiesta di intestazione. Il lato server dovrebbe autorizzare questa richiesta e rilevare l'ID utente che ha inviato questa richiesta. Il server effettuerà la ricerca nel DB di access_token e controllerà expiration_date ). Dopo che access_token sarà stato fondato, dovrai verificare la seguente condizione: current_date <= expiration_date , se true poi ok, se false allora dobbiamo rigenerare access_token usando il nuovo expiration_date e salvarli su DB e inviare% nuovo% co_de al client?

se sì, allora cosa ne pensi di questo approccio alla sicurezza?

    
posta web_dev 04.06.2012 - 14:49
fonte

1 risposta

1

Supponendo che almeno hash + salvi la password degli utenti nel database, il tuo flusso di lavoro sembra corretto.

Ma vorrei aggiungere due cose:

  1. NON INSERIRE LA PASSWORD DELL'UTENTE NELLA PARTIRE , non è affatto sicuro e totalmente inutile. Anche expiration_date è inutile qui. Metti una sha1(username + 'randomly generated string') e sarai bravo.
  2. Se il expiration_date è scaduto, non dovresti ripristinare automaticamente l'utente, ma chiederle di accedere di nuovo. Perché se fai come dici tu, perché usare un expiration_date allora?

Per il mio # 1, poiché il tuo token è sha1 (username + password + expiration_date), come attaccante, posso conoscere il nome utente, la data di scadenza e il token di accesso, i risultati di sha1.

Devo solo costruire un sistema di forza bruta locale che proverà tutta la combinazione della password possibile, e confrontare sha1 (username + "current testing password" + expiration_date) al dato access_token , e una volta lo trovo , Saprò la password: /

    
risposta data 04.06.2012 - 16:13
fonte

Leggi altre domande sui tag

Quando (se mai) la web app deve forzare gli accessi numerici, generati (quindi difficili da ricordare)? È possibile utilizzare AP falso per ottenere le chiavi wpa? [duplicare]