Quanto è significativo il rischio di avere un email / IM di un htpasswd hash?

Per impostazione predefinita, l'utilità htpasswd tende a utilizzare una password di hashing specifica per Apache chiamata "apr1" e documentata qui . Sembra essere una costruzione personalizzata che richiama MD5 1000 volte. Supponendo che non ci sia debolezza strutturale in quella costruzione, l'attaccante può ancora provare le password ad un ritmo piuttosto veloce. Come documentato qui , una GPU AMD R9 290X è in grado di calcolare circa 11,5 miliardi di MD5 al secondo. Poiché ogni tentativo di password richiede un migliaio di invocazioni MD5, l'utente malintenzionato dovrebbe essere in grado di provare 11,5 milioni di password al secondo. Questo è abbastanza veloce, e si deve presumere che una "normale password utente" non durerà molto a lungo.

Anche un piuttosto strong 44-bit la password entropia cadrà entro una settimana di calcoli, con un utente malintenzionato che utilizza una singola GPU disponibile immediatamente.

L'identificazione della funzione non è difficile poiché è scritta nella stringa hash stessa (ad es. inizia con $apr1$ ).

Personalmente, userei il telefono. Come suggerisce @ André, PGP è anche utilizzabile, a condizione che PGP sia installato. Un'altra opzione è aprire un account di shell basato su SSH (ciò richiede l'ottenimento di una copia della chiave SSH public dell'utente) e l'archiviazione della password in un file su quell'account (o l'utente lo spinge htpasswd file lì).

Le e-mail potrebbero andar bene se puoi controllare dove si trova l'e-mail, il che è difficile in generale, ma può essere reso molto più facile in alcuni casi. Vale a dire, l'utente invia l'email dal suo account Gmail al proprio account Gmail; presumibilmente, le e-mail inviate da Gmail a Gmail non viaggiano senza protezione su Internet. Tuttavia, poiché non esiste alcuna sicurezza nei protocolli di posta elettronica, tale ipotesi non può essere presa per nessun server di posta elettronica.

(Di norma, è meglio presumere che qualsiasi attaccante che si preoccupa di leggere le tue e-mail sappia un bel po 'su cosa fai e su quali sono le password scambiate - dopotutto lui legge le tue e-mail ).

In generale, dovresti prendere provvedimenti per evitare che un hash venga esposto, magari usando l'e-mail crittografata o almeno una connessione crittografata. Detto questo ...

Credo che il rischio di 1 (connessione compromessa) o 2 (posta elettronica intercettata) accada è piuttosto basso, e il numero 3 (risolvere l'hash) è la parte che conta di più, perché se la risposta a 3 è che l'hash non può essere risolto facilmente, quindi non dovresti preoccuparti tanto di 1 o di 2. Continuerò con il calcolo di Tom da 11,5 milioni di tentativi al secondo, ma giungere a una conclusione leggermente diversa. Se si utilizzano solo lettere e numeri (62 caratteri) e si richiede un minimo di 8 caratteri, il tempo medio per trovare una password è di circa 11 giorni. Con un minimo di 9 caratteri, il tempo medio sarebbe di circa 2 anni. Se aggiungi solo alcuni dei caratteri speciali (18 simboli o 80 caratteri totali), una password casuale di 8 caratteri impiega in media 84 giorni per risolverli e una password di 9 caratteri impiega in media 19 anni. Se si effettua il minimo di 10 caratteri casuali, esso arriva fino a 1500 anni. Aggiungi tanti caratteri quanti più ti richiede la paranoia.

Ho due pensieri a riguardo:

1. Poiché in genere gli utenti memorizzano le proprie password di Subversion nel proprio client, (non è necessario memorizzarle), quindi è possibile utilizzare le password generate. Se sono password casuali di almeno 80 caratteri consentiti con una lunghezza minima di almeno 10 caratteri, un hash compromesso non dovrebbe preoccuparti.
2. Se gli utenti stanno creando la propria password e si vede solo l'hash, non si avrebbe modo di sapere se l'utente ha effettivamente generato la password correttamente in base alle regole specificate. Quindi, se non puoi garantire che le password effettive seguano le regole richieste per creare un hash sicuro da mostrare, allora dovresti pensare che gli hash non siano sicuri se compromessi.