Più hash di bcrypt esposti dello stesso UUID v4 con sale generato casualmente essere troppo insicuro?

Question

Più hash di bcrypt esposti dello stesso UUID v4 con sale generato casualmente essere troppo insicuro?

#1 da (2 voti)
#2 da (0 voti)

1

Sto cercando di implementare un controllo di proprietà sugli oggetti JSON e voglio evitare di tornare al database per assicurare la proprietà di detto oggetto / record (cioè, per impedire a un utente di aggiornare un oggetto / record che non possiedono - per lo più operazioni CRUD). Ciò si verifica nel contesto di un'API di servizio / applicazione Web.

Il mio pensiero è di avere un UUID di proprietà "proprietario" assegnato a un sistema lato server associato a ogni record utente, in modo che quando si passa un oggetto JSON di proprietà dell'utente alla vista, il sistema crittografa l'UUID di "proprietà" privato del proprietario usando bcrypt con un salt casuale e lo assegna all'oggetto / record (dove potrebbe essere persistente insieme al record per scopi di caching in modo che non debba essere nuovamente crittografato). Inoltre, dovrei notare che è possibile che gli oggetti di proprietà possano essere crittografati separatamente ognuno con il proprio sale generato a caso, anche se sono di fatto lo stesso UUID di proprietà dell'utente (questo è necessario per impedire il rilevamento della proprietà dell'oggetto dell'utente in alcune applicazioni casi).

Successivamente, se un utente tenta di aggiornare detto oggetto, il server dovrà convalidare il proprio UUID privato con l'hash di bcrypt per assicurarsi che disponga dei diritti di proprietà per aggiornare il record.

Si presume che criptassi utilizzando un numero appropriato di round per la crittografia. Un'altra ipotesi che sto facendo è che la crittografia e il tempo di controllo superino i tempi di controllo del database. L'ultima ipotesi da sottolineare è questa rigorosamente una verifica della sicurezza delle app e non farebbe nulla se qualcuno avesse effettivamente preso possesso del database.

La mia attuale opinione è che con l'UUID che è casuale e che le dimensioni della stringa siano grandi (insieme ad un numero appropriato di round) renderebbe pubblicamente esposti questi hash di bcrypt non essere un problema. O questo approccio è solo troppo rischioso / controllato?

encryption web-application hash bcrypt web-service

posta Jordan 11.10.2013 - 20:40

fonte

2 risposte

0

Un altro approccio consiste nel firmare i campi protetti usando HMAC.

{"RecordID": "nnn", "Day": "day_since_epoch", "OwnerUserId": "[email protected]", "OwnerUserIdHmac": "{yyy}", ...}

Dove yyy = HMAC ($ RecordID + $ OwnerUserId + $ Day, $ SecretKey [$ Day])

La chiave segreta viene ruotata quotidianamente e puoi decifrare utilizzando la chiave di un giorno precedente.

risposta data 11.10.2013 - 21:11

fonte

Leggi altre domande sui tag encryption web-application hash bcrypt web-service

Problemi con certificati SSL intermedi e proxy SSL Tentativo di hacking dei commenti di WordPress

score 2 · Accepted Answer

Non hai bisogno di bcrypt qui.

Bcrypt e altre funzioni di hashing della password simili ai sali e iterazioni per far fronte alla debolezza intrinseca delle password, che è la loro vulnerabilità alla ricerca esaustiva. Lo spazio delle possibili password, quello che la maggior parte degli utenti sceglierà e sarà in grado di ricordare, è semplicemente troppo piccolo per comodità. Usiamo le iterazioni in modo che il compito dell'aggressore venga rallentato. Utilizziamo i sali in modo che l'attaccante non possa realizzare economie di scala quando tenta di infrangere più password. Ma tutto ciò ha senso solo perché è possibile interrompere la password one .

Quando i dati da sottoporre a hash (per ulteriori verifiche) sono un strong tasto casuale, scelto in modo uniforme da uno spazio abbastanza grande da sconfiggere la ricerca esaustiva, i sali e l'hashing lento non sono necessari. Questo è il caso del tuo "UUID privato". Si suppone che un UUID "v4" contenga 122 bit generati da un PRNG crittograficamente strong. Questo è ben oltre ciò che è suscettibile di ricerca esauriente. Questo "UUID privato" è una chiave nel vero senso del termine.

Quindi, in un determinato protocollo in cui si hash questi "UUID privati" con bcrypt, è possibile sostituire bcrypt con una semplice funzione di hash (ad esempio SHA-256) e dimenticare i sali. Nel tuo caso, il server memorizza h (UUID) per qualche funzione hash h , collegata a un utente, e l'utente deve mostrare a UUID stesso l'accesso autorizzato. Questo è il semplice modello di "password" ma con una password veramente strong, che non richiede gli strumenti sviluppati per tollerare password umane (che non sono forti). Ovviamente vorrai eseguire l'intero protocollo sotto la protezione di alcuni livelli che garantisce che il client parli con il server giusto e che i trasferimenti siano protetti da intercettazioni e alterazioni (in pratica, SSL).