Utilizzo di bcrypt in chrome extension [closed]

Question

Utilizzo di bcrypt in chrome extension [closed]

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

0

Sto sviluppando un'estensione di Chrome per questo non profit. Sto anche lavorando sul componente lato server. Non sono uno sviluppatore a tempo pieno quindi la maggior parte delle mie conoscenze deriva semplicemente da anni di raccolta di informazioni casuali. Una cosa che questo programma deve fare è accedere al server e recuperare un codice univoco per l'utente. Fortunatamente da come sta funzionando nella mia mente non abbiamo bisogno di memorizzare la password, solo recuperare e memorizzare il loro ID univoco. Tuttavia dovremo effettuare il login per ottenere quell'ID.

Quindi la mia domanda è se uso bcrypt in javascript per cancellare la password all'interno dell'estensione e poi inviare l'email + hash al server (tramite https, ovviamente), c'è qualche rischio per la sicurezza qui? Non sto pensando ad una cosa sola, ma ho pensato che avrei consultato alcune persone che vivono in questo mondo regolarmente. Grazie!

chrome password-management bcrypt

posta stevo81989 20.01.2015 - 00:56

fonte

2 risposte

Leggi altre domande sui tag chrome password-management bcrypt

utilizzando token temporanei per comunicazioni sicure con IFRAME comprensione del tracert per determinare l'attacco MITM?

score 1 · Answer 1

C'è un rischio per la sicurezza? No.

C'è un vantaggio in termini di sicurezza? No.

L'utilizzo di HTTPS significa che la password è protetta durante il transito e che viene inviata al server che si desidera. L'hashing della password lato client e l'invio dell'hash non guadagnano nulla: un hacker in grado di guardare all'interno del tunnel SSL e rubare una password in testo semplice (ad esempio malware installato sul client) può invece rubare l'hash e passarlo quando si impersona l'utente.

Come nota a margine, ci sono problemi con l'hashing o la crittografia in Javascript. L'utilizzo di un'estensione del browser piuttosto che di JavaScript in-page evita molti di essi, ma c'è ancora un problema di velocità: Javascript è lento rispetto al codice nativo, quindi non puoi permetterti da nessuna parte vicino a quanti cicli di hashing bcrypt.

score 0 · Answer 2

Si prega di leggere la risposta canonica di Thomas Pornin su Come fare in modo sicuro le password di hash , in particolare la sezione

Since hashing is (deliberately) expensive, it could make sense, in a client-server situation, to harness the CPU of the connecting clients. After all, when 100 clients connect to a single server, the clients collectively have a lot more muscle than the server.

To perform client-side hashing, the communication protocol must be enhanced to support sending the salt back to the client. This implies an extra round-trip, when compared to the simple client-sends-password-to-server protocol. This may or may not be easy to add to your specific case.

Client-side hashing is difficult in a Web context because the client uses Javascript, which is quite anemic for CPU-intensive tasks.

In the context of SRP, password hashing necessarily occurs on the client side.

Il risultato è che puoi sentirti libero di eseguire il lato client dell'hash, TUTTAVIA, ciò non modifica in alcun modo i requisiti per l'hash dei risultati lato server prima della memorizzazione in un database o in un altro archivio dati .

Indipendentemente da ciò che il client ti invia per convalidare chi sono, devi farlo sul lato server con un gran numero di iterazioni di PBKDF2, BCrypt o SCrypt, in modo che qualcuno con una copia trapelata della tua password / database di autenticazione deve ancora fare una quantità significativa di lavoro per autenticarsi nella tua app.

È necessario memorizzare il conteggio iterazione ServerBcrypt (ClientBcrypt (password, lotti), evenmorelots) / fattore di lavoro e sali in modo da avere qualcosa per autenticare qualsiasi cosa l'utente presunto ti fornisca.