Hashing del token cookie per il login persistente

1

In un sistema di accesso che sto facendo , sto usando un token di cookie generato dall'utente per dispositivo, generato a caso . Una parte di lo script ha il seguente aspetto:

// Generate current device's token
$token = substr(bin2hex(mcrypt_create_iv(200)), 0, 60);

// Include this device's token
$STH = $userDB->prepare("INSERT INTO devices (user_id, token, active) VALUES (?, ?, 1)");
$Res = $STH->execute(array($Id, $token));

if (!$Res)
  throw new Exception("Couldn't store the device in the database");

// To keep users logged in between sessions
$Cookie->email = $email;
$Cookie->token = $token;

Tuttavia, questo implica che se il database è stato rubato, l'utente malintenzionato potrebbe accedere come chiunque modificando i cookie . Questo è un problema che voglio evitare. So che sha256 non è valido per l'hashing della password generale. Tuttavia, dalla stringa proviene,

$token = substr(bin2hex(mcrypt_create_iv(200)), 0, 60);

È sicuro memorizzare un hash sha256 del token ad alta entropia nel database? O dovrei usare il bcrypt più costoso, come con le password?

    
posta Francisco Presencia 02.04.2014 - 00:09
fonte

1 risposta

1

Se il tuo token è sufficientemente lungo, penso che staresti bene usando semplicemente SHA256. Non ho molta familiarità con PHP, ma sembra che tu stia creando token di lunghezza 200, il che sarebbe più che sufficiente. Il motivo per cui penso che SHA256 sia OK è che lo spazio di ricerca per un token di lunghezza è così gigantesco che non importa quanto sia veloce la funzione di hashing. Non c'è alcuna possibilità che sarà brutale costretto in nessuna delle nostre vite.

Tuttavia, dal punto di vista della programmazione, potrei comunque raccomandare l'uso di bcrypt. Non sono sicuro dell'implementazione di PHP, ma l'hashing di Bcrypt è in genere meno difficile da rovinare l'hashing SHA256, il che rende meno probabile l'esistenza di bug nel sistema. Se si utilizza bcrypt altrove per l'autenticazione basata su password, utilizzarlo in modo coerente invece di avere due metodi diversi per l'hashing rende il sistema meno complicato e quindi anche meno probabile che abbia bug critici. Se sei preoccupato per la velocità, fai attenzione a non ottimizzare il tuo sistema troppo presto. Implementalo prima con bcrypt e poi esegui qualche profilazione del tuo sistema. Se e solo se identifichi il tuo sistema di hashing di token come rallentato, dovresti pensare a usare SHA256.

    
risposta data 02.04.2014 - 17:46
fonte

Leggi altre domande sui tag