Possiamo semplicemente riscrivere la password su un sospetto hijack di sessione?

Naviga le tue risposte
1

Esaminare le persone si lamentano di Yahoo costringendo gli utenti a cambiare le loro password . Possiamo vedere che le persone non amano particolarmente cambiare le password (e se li cambiamo regolarmente è discutibile un aumento della sicurezza ). Questi due casi (violazioni di yahoo e modifiche periodiche della password) riguardano il fatto che gli hash delle password sono stati (o potrebbero essere) rubati.

Tuttavia, questo non è l'unico caso in cui è consigliabile cambiare una password. L'altro caso è hijacking di sessione .

Supponendo un'applicazione in rete e multisessione (ad esempio da divisioni diverse allo stesso tempo), quando un utente sospetta che la sua sessione ci consiglia spesso di cambiare la sua password . Questo ha senso in un certo senso perché OWASP sostiene che tutte le sessioni correnti dovrebbero essere invalidate al cambio della password . Inoltre, poiché i token di sessione sono spesso derivati dall'hash della password.

Invece di consigliare a questo utente di cambiare la sua password, non possiamo semplicemente riutilizzare la stessa password e semplicemente re-saltarla?

Guardando il vecchio Would re- salare le password regolarmente inserendo / diminuendo la sicurezza? Sto pensando se ci siano degli svantaggi nel consentire a un utente di mantenere i propri passowrd. Per eseguire il re-salting abbiamo bisogno che l'utente ci dia la password, quindi un dirottatore non sarebbe in grado di farlo.

Quindi sì, è un vantaggio di usabilità per un utente che può continuare a usare la stessa password ma:

  • Eseguendo il re-salting, ciò sarebbe più vulnerabile (ovvero una semplice modifica della password) a un utente malintenzionato che conosce parte dell'hash (ad esempio dal token di sessione)? (Credo di no)
  • Evitare qualsiasi informazione dall'hash della password che sfugge al token di sessione lo attenuerebbe?
  • Fornire invece un elenco di sessioni aperte all'utente e consentirgli di disabilitarle sarebbe meglio? (Credo che non da quando l'hacker potrebbe farlo anche lui)
posta grochmal 20.02.2017 - 22:08
fonte

2 risposte

2

No, non funzionerebbe. tu speri non hai la password sul tuo database, quindi non puoi semplicemente cambiare l'hash senza bloccare l'utente. Per cambiare l'hash, devi aspettare che l'utente effettui l'autenticazione, quindi hai la password. Con la password si crea un altro salt, l'hash di entrambi, si salva l'hash e si gira la password. Ma non è quello che vorresti fare.

Le sessioni potrebbero non essere legate alla password, ma salvate su un tavolo da qualche parte, quindi è meglio sbarazzarsi di tutti i token di sessione E costringere l'utente a cambiare la password, invalidando quella corrente e mandando una messaggio di gruppo (email, sms) con uno nuovo o un collegamento a una pagina modifica della password .

    
risposta data 20.02.2017 - 22:33
fonte
2

L'idea alla base della violazione è che un hacker ora ha la tua password. L'ha ottenuto usando uno dei numerosi attacchi (arcobaleno, dizionario, forza bruta) su un'immagine del database di Yahoo che ha ottenuto con mezzi illeciti.

Se ha la tua password, cambiare il sale non farà nulla. Lui non ha bisogno del tuo sale. Lui non ha bisogno del tuo hash. Tutto ciò di cui ha bisogno è la tua password.

Quando fornisce quella password nella pagina di accesso, Yahoo cercherà volentieri l'ultima versione per lui, e calcolerà l'hash della password che lo usa. Da lì verrà eseguito l'accesso con il tuo account.

Inoltre, non è possibile per Yahoo cambiare il sale e rigenerare l'hash della password, a meno che non abbiano la password stessa in chiaro. Il non dovrebbe. Se lo fanno, l'hacker ha ancora la password, che non è cambiata, e può ancora accedere come te.

    
risposta data 21.02.2017 - 04:47
fonte

Leggi altre domande sui tag

Come prevenire l'attacco dell'header host in Ubuntu Server 14.04? Infetti un'app Android esistente con malware e ridistribuisci