Utilizzo della password hash come chiave segreta per hmac per evitare lo scambio di segreti tra server e client

0

Attualmente sto cercando di migliorare la nostra API per essere più riposante, quindi evito qualsiasi stato sul server. Voglio realizzare questo con un token hmac, aggiunto ad ogni richiesta. L'hmac sarà realizzato con la seguente parte di dati: host, metodo di richiesta, request-uri, timestamp (per evitare replay) e in caso di POST / PUT anche il corpo della richiesta. Qualche obiezione contro questo?

Invierò hmac insieme al nome utente o magari a una rappresentazione hash (chiave pubblica) dell'utente per poter avere chiavi segrete diverse per ogni utente sul server.

Ora sto pianificando lo scambio di chiavi segrete tra client (JavaScript) e server (PHP) e ho l'idea di usare solo qualcosa che il server e il client già conoscono entrambi senza scambiarlo e dovrebbe comunque essere diverso per ogni utente.

Quindi perché non usare la password hash dell'utente come chiave segreta? Il server ha l'hash della password salvata nel database accanto all'utente in usertable e il client può calcolare l'hash in base all'input dell'utente e memorizzarlo in una sessione client per un utilizzo successivo.

Quali sono i dubbi sull'uso della password utente con hash come chiave segreta?

    
posta Preexo 24.06.2014 - 15:56
fonte

1 risposta

2

Non è proprio possibile usare la password dell'utente in quanto non è possibile memorizzare in modo sicuro le password in modo che il client possa ricavare la stessa chiave dalla password in modo indipendente. Il motivo è che è necessario salare una password mentre la si archivia.

Gli attuali algoritmi di hashing della password accettati sono:

  • bcrypt
  • scrypt
  • PBKDF2
risposta data 24.06.2014 - 16:29
fonte

Leggi altre domande sui tag