Posso buttare via una chiave privata e usare la chiave pubblica come una funzione di hash?

0

Sì, sì lo so "non inventare i propri protocolli se non si è esperti". Non c'è bisogno di urlarmi, voglio solo sapere se c'è un difetto in questa idea e se qualcuno non l'ha fatto prima.

La motivazione qui è che voglio essere in grado di autenticare gli utenti. So che la soluzione standard è la password salata e hash. Ma non mi piace il fatto che la password stessa debba essere inviata al server per controllarla. Cosa succede se qualcuno ascolta? Il lato client può crittografare e inviare la password, ma non mi piace neanche perché forse la mia chiave di decrittazione perde e qualcuno che ha registrato il traffico web precedente può dedurre tutte le password. L'autenticazione non è un problema nuovo, quindi non mi soffermerò più sui pro e contro delle solite soluzioni.

La mia idea

Per ogni utente (a) il server memorizza una chiave pubblica (g ^ x_a) e la password crittografata con quella chiave pubblica (g ^ {x_a} * p_a). La chiave privata associata è stata prontamente distrutta o (meglio ancora) mai calcolata. Il generatore di gruppo g è tenuto in considerazione per la futura generazione di chiavi. La solita relazione si applica g ^ a * g ^ b = g ^ {a + b}. Il processo di autenticazione è il seguente

  1. L'utente Alice chiede di essere autenticato

  2. Il server Bob genera una nuova chiave pubblica temporanea g ^ t (di nuovo senza una chiave privata associata). Bob moltiplica questa chiave pubblica temporanea sui suoi dati di Alice. Questo risulta in g ^ t * g ^ {x_a} = g ^ {t + x_a} = g ^ {x_a} 'e g ^ t * g ^ {x_a} * p_a = g ^ {t + x_a} * p_a = g ^ {x_a} '* p_a. Bob dispone della chiave pubblica temporanea lasciandolo solo con una nuova chiave pubblica (g ^ {x_a} ') e la password di Alice crittografata con questa chiave. Invia la nuova chiave ad Alice.

  3. Alice prende la chiave data da Bob che la usa per crittografare la sua password. Invia il valore crittografato a Bob.

  4. Bob autentica Alice se il valore dato corrisponde ai dati crittografati calcolati nel passaggio 2.

Per ricapitolare

  1. In nessun momento il server (o un hacker del database) può decodificare la password. Con le chiavi private disattivate la crittografia a chiave pubblica funziona in modo efficace come un hash.

  2. Poiché ogni utente è crittografato con una chiave diversa, le password vengono effettivamente salate. Un tavolo arcobaleno non funzionerebbe qui.

  3. Un hacker con un'immagine precedente del database non può dedurre i valori futuri di g ^ x_a * p_a ascoltando sul traffico web poiché ciò richiederebbe la deduzione della chiave temporanea (che richiede la risoluzione del log discreto). Pertanto, un'immagine del database trapelata non consente a un utente malintenzionato di impersonare gli utenti.

  4. Né il server né il client dispongono di chiavi private da gestire. Solo il cliente ha bisogno di mantenere informazioni segrete e le informazioni segrete possono essere leggibili.

  5. (inconveniente) un utente malintenzionato ha una piccola finestra di tempo tra i passaggi 2 e 4 in cui può penetrare il server e impersonare un utente utilizzando i dati trovati.

posta IIAOPSW 20.07.2018 - 09:29
fonte

2 risposte

3

Un problema molto "facile" su (qualsiasi) crittografia di trasporto delle password:

  • Inviandolo in testo in chiaro su HTTP, ovviamente qualsiasi sniffer può leggerlo e usarlo per accedere.
  • L'invio di testo in chiaro su HTTPS (dove tutti i dati sono crittografati, non solo la password da solo) è già ok.
  • L'invio di password crittografata in HTTPS non offre alcun vantaggio.
  • E password crittografate su HTTP (e il server si aspetta crittografato): C'è ancora il problema che uno sniffer può leggere la password crittografata, inviarla al server stesso e accedere correttamente.

Quindi, dimmi, perché stai crittografando le password durante il trasferimento?

Sulla tua combinazione di chiavi pubbliche, con RSA-OAEP ecc., questo non funzionerà (se non hai mai sentito parlare di OAEP, dovresti solo sapere che il semplice RSA non è sicuro).

Ci sono altri problemi, ma questi due da soli rendono già inutilizzabile il tuo schema.

    
risposta data 20.07.2018 - 12:42
fonte
1

@deviantfan dà una buona risposta; Voglio espandere.

Un'idea interessante e potrebbe funzionare (dopo un'attenta analisi da parte di persone più crittografie di me), ma perché non usare semplicemente una funzione di hash salata regolare? Per prima cosa, RSA è lento . Davvero lento. (per qualsiasi messaggio più lungo di circa 256 bit, è più efficiente per crittografare RSA una chiave AES e quindi crittografare AES il messaggio).

Stranamente, le persone non sembrano pubblicare i tempi di benchmark per il keygen RSA, ma sembra come creare una nuova chiave temporanea RSA impiega circa 1 secondo per RSA 2048 e circa 20 secondi per RSA 4096. È molto carico il server e la latenza per l'utente.

Come sottolinea @Ben, slow è utile per le funzioni hash di memorizzazione delle password, ma non questo lento . Inoltre, con l'hashing della password lenta, il server deve eseguire l'operazione di hash lento una volta per accesso legittimo, mentre l'hacker deve eseguirlo per ipotesi, rallentando il numero di tentativi al secondo. Qui, il server deve eseguire il keygen lento una volta per accesso legittimo, ma l'hacker non ha mai bisogno di farlo affatto perché ottiene la chiave pubblica e può quindi indovinarla. In realtà stai inclinando la quantità di lavoro sul server rispetto alla quantità di lavoro che l'attaccante deve fare sostanzialmente a favore dell'attaccante.

    
risposta data 20.07.2018 - 15:56
fonte

Leggi altre domande sui tag