hash nome utente e password nel ricordarmi il token?

6

Il framework MVC Symfony utilizza il seguente metodo nella sua creazione di un cookie remember me:

/**
 * Generates a hash for the cookie to ensure it is not being tempered with.
 *
 * @param string $class
 * @param string $username The username
 * @param int    $expires  The Unix timestamp when the cookie expires
 * @param string $password The encoded password
 *
 * @return string
 */
protected function generateCookieHash($class, $username, $expires, $password)
{
    return hash_hmac('sha256', $class.$username.$expires.$password, $this->getKey());
}

Quindi usano una stringa della classe utente, seguita dal nome utente, quindi un timestamp e poi la password dell'utente. Viene salato con una chiave che non cambia mai ed è uguale per tutti gli utenti del sistema.

Ora ecco il mio problema con questo: Perché inserire la password nel cookie? Anche se è la password salata e salata (con un altro sale, unico per ogni utente), non è un rischio inutile?

O sono paranoico qui?

Inoltre, con quell'hash, sembra che l'unica cosa unica sia la data e ora della scadenza. Sembra che sarebbe possibile copiare alcuni vecchi cookie e crearne uno nuovo per un attacco di riproduzione giusto?

Aggiorna

Il cookie risultante è codificato in base64 e il suo contenuto decodificato è:

Somenamespace\YourApp\YourUserClass:MjQ2NjM=:1501576079:74fbfcddcc66c2a11586bf4e39e68ddb459afa3a3fa6684e93d03fc393ee1141

Il primo elemento è la classe utente. Il secondo parametro dovrebbe essere il nome utente codificato in base 64 ma questo è ciò che ottengo per questo, quindi suppongo che sia l'id utente. Proverò a scoprire come funziona anche questo. Il terzo parametro è il timestamp "scade", quindi non devi nemmeno indovinare. Il quarto parametro è detto cookie hash.

    
posta Andresch Serj 01.08.2016 - 11:18
fonte

3 risposte

2

Questo meccanismo è tale che quando l'utente cambia la sua password, tutte le sessioni "remember-me" vengono invalidate.

Le due caratteristiche principali di questo meccanismo per quanto riguarda la sicurezza sono:

  • Che la password non può essere determinata dall'hash nel cookie, se l'hacker riesce in qualche modo ad accedere al cookie.
  • Che l'utente malintenzionato non può ricreare il cookie "remember-me" utilizzando altri dati per ottenere l'accesso da un altro computer.

A prima vista, perché il cookie contiene un hash della password

Somenamespace\YourApp\YourUserClass:MjQ2NjM=:1501576079:74fbfcddcc66c2a11586bf4e39e68ddb459afa3a3fa6684e93d03fc393ee1141

potrebbe sembrare che un utente malintenzionato possa forzare la forza o "indovinare la password" per scoprire se una password testata genera lo stesso hash (4 ° parametro sopra). Tuttavia, poiché si tratta di un hash con chiave (in questo caso HMAC), l'utente malintenzionato non avrà la chiave per eseguire tale attacco sul valore del cookie.

Riguardo al secondo punto, questo è anche difficile per un attaccante compiere per le stesse ragioni. Poiché la chiave dell'hash non è nota, sarà quasi impossibile per un utente malintenzionato ricreare il cookie "remember-me" anche se sono noti l'ID utente, la classe e la scadenza.

    
risposta data 02.08.2016 - 09:24
fonte
1

... Now here is my issue with this: Why put the password in the cookie? Though it is the hashed, salted password (with another salt, unique for each user), isn't that an unnecessary risk?

La valutazione del rischio si basa su una base caso per caso, quindi non possiamo dire se sia accettabile o meno senza ulteriori dettagli su dove viene utilizzato (e questa non è una domanda per S.E.)

Come sottolineato il ragionamento dietro il perché la password corrente (in qualsiasi forma) è parte del token hashing utilizzato per aggiungere entropia e per legare la password con il token.

Un token simile per una password diversa non funzionerà quindi. Ciò consente al sistema di "disconnettere automaticamente" chiunque quando la password cambia, senza eseguire esplicitamente un logout e rintracciare tutti i token "ricordami".

La password stessa dovrebbe essere nella sua forma hash (probabilmente salata), dal momento che non dovremmo mai memorizzare password unhasshed.

Or am I being paranoid here?

Sì, ma è una brutta cosa? ... cosa dicono le voci ??

Also, with that hash, it seems the only unique thing is the expires timestamp. Seems like it would be possible to copy some old cookies and create a new one for a replay attack right?

Bene, no. come attaccante è necessario il nome utente e la password per ricreare un hash con per ottenere un token di attacco 'valido'. hai maggiori problemi se l'utente malintenzionato ha il nome utente e la password.

    
risposta data 01.08.2016 - 13:41
fonte
0

L'unica ragione che posso vedere per aggiungere il parametro password nell'hash generato è che quando l'utente cambia la sua password, le altre sessioni persistenti in altri computer verranno automaticamente interrotte.
Questa è anche una buona pratica per forzare la ri-autenticazione con la nuova password.

    
risposta data 01.08.2016 - 12:13
fonte

Leggi altre domande sui tag