Ho un'app che trasmette la password in chiaro. Stavo progettando di utilizzare l'hash della password (SHA-512) come chiave per crittografare la password in testo semplice. Quindi inviare il testo crittografato al server. la lunghezza della password è di minimo 12 caratteri (compresi i caratteri speciali) e max 20 caratteri.
Questo è un cattivo meccanismo?
Con un piccolo aggiustamento questo può essere reso ragionevolmente sicuro.
Il problema con il tuo approccio originale è che l'hash sarebbe sempre lo stesso, quindi è vulnerabile a un attacco di ripetizione .
Se regoli il protocollo per includere una sfida variabile , questo può funzionare:
Questo accordo è sicuro contro replay attack e evita anche che il server memorizzi un equivalente password . La principale vulnerabilità è che un accesso acquisito può essere utilizzato per un attacco brute force offline . Inoltre, se stai implementando questo in JavaScript, il codice JavaScript potrebbe essere intercettato e manomesso.
Ora, mentre questo è interessante, dovrei echeggiare il consiglio di altre risposte: non eseguire il crypto
Is this is bad mechanism ?
Sì. Utilizza SSL / TLS e non tentare di implementare il proprio schema crittografico .
Se la tua preoccupazione è trasmettere la password, allora sì, assolutamente, questo è un cattivo meccanismo. La tua applicazione è ancora vulnerabile a un tipo di attacco pass-the-hash . Sebbene la password stessa non sia disponibile per l'utente malintenzionato, la password crittografata può essere intercettata e utilizzata, di per sé, per l'autenticazione.
Vai sempre allo standard:
Sì, questo è male. Se tutto ciò che serve al server per autenticarti è questo (mai cambiare) hash, quindi è la tua password ora. Non è meglio che inviare la password in chiaro, perché tutto ciò di cui ha bisogno l'autore dell'attacco per impersonare te è quell'hash.
Invece, se vuoi usare password hash per la trasmissione, il modo in cui lo fai è attraverso una challenge- risposta sistema. In questo modo, lo stesso hash non viene mai inviato due volte. Ma questa non è una buona idea, perché ...
È più importante che la password non sia archiviata sul tuo server. TLS / SSL è sufficiente per prevenire qualsiasi tipo di attacco man-in-the-middle. Quella parte è risolta, basta usare TLS e non preoccuparti di ciò. Ma tu fai devi preoccuparti che il tuo server venga violato e che il tuo database delle password sia trapelato. Pubblicare database di password di altre persone è di gran moda in questi giorni, e non vuoi essere uno di quelli catturati non hashing il loro database. Non ci sono scuse.
Quindi, trasmetti le tue password in testo semplice all'interno di una connessione crittografata, ma memorizzale come hash sul server. Se fai qualcos'altro, qualsiasi altra cosa, allora stai sbagliando.
I was planning to use the hash of the password (SHA-512) as the key for encrypting the plain text password. Then send the encrypted text to the server.
Non mi interessa se usi SHA con la chiave 8192 bit, stai provando ad autenticare con qualcosa che viaggia in chiaro che qualcuno può solo MITM così la tua risposta è no. Chiunque abbia lavorato con crypto (come le altre buone risposte qui) ti dirà di non provare a lanciare la tua crittografia, a meno che tu non sappia davvero cosa stai facendo, e anche allora ci sono molte buone API per questo.