CMS Utilizza http e quindi invia password in testo normale

Devi usare https. Questa non è una responsabilità dell'applicazione CMS, ma una responsabilità della persona che distribuisce il sistema, di acquistare un certificato SSL firmato da un'autorità di certificazione attendibile nota (nota che è possibile acquistare gratuitamente da say link o inclusi nel costo della registrazione del dominio, per esempio link ) e forzare tutto il traffico solo inviato tramite HTTPS.

Anche se l'applicazione CMS dice hash la tua password lato client (usando say javascript), ha inviato la password hash sulla rete, e poi ha controllato l'hash lato server, la password hash (diciamo hash=bcrypt('Correct Horse Battery Staple', salt)= '$2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.' )  verrebbe comunque inviato in testo in chiaro perché chiunque possa origliare. Questi intercettatori sarebbero comunque in grado di eseguire un attacco di replay (ad esempio, modificare il javascript sul lato client anziché l'hash di una password inserita, per inviare semplicemente indietro la password hash acquisita $2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04. ) che hanno intercettato. Inoltre, si noti che ciò trasforma efficacemente la password con hash del client nella password effettiva; quindi idealmente avresti anche un ulteriore hash sul lato server hash ricevuto da confrontare con ciò che è memorizzato nel database. Oppure potrebbero semplicemente intercettare i cookie di sessione inviati in rete e utilizzarli per simulare l'attività di un utente attualmente connesso.

Oppure potrebbero semplicemente fare confusione con il routing per fare un attacco uomo nel mezzo, quindi invii la password al loro server.

Inoltre, se hanno richiesto di utilizzare SSL senza aver acquistato un certificato, gli utenti potrebbero essere spaventati a causa degli avvisi del browser relativi a un certificato non attendibile.

Uno schema più complicato può convincerti che c'è più sicurezza di quanto non sia in realtà, anche se per un aggressore sarebbe banale aggirare. Tutto ciò che è necessario è configurarlo usando HTTPS.

Bene, Joomla è un'applicazione web, non è responsabilità dell'applicazione web fornire un'interfaccia SSL in modo da poter utilizzare HTTPS. Questa attività è per il server web su cui è in esecuzione la webapplication.

Joomla ha avuto un'impostazione "Force SSL" dalla versione 1.5. Puoi configurarlo modificando il file configuration.php o utilizzando la GUI Web di amministrazione .

È impostato su "None" per impostazione predefinita, principalmente perché diversi host non supportano SSL / HTTPS out of the box. Probabilmente vorrai cambiarlo in "Solo amministratore" per proteggere solo l'interfaccia di amministrazione, o "Tutto il sito" se vuoi proteggere anche il front-end pubblico (utile se hai accessi front-end.)

L'invio di password a siti Web in testo semplice (ad esempio un modulo di accesso HTML standard su un CMS, forum o altro script Web) non è sicuro. Allo stesso modo, l'invio di password nelle e-mail (se una nuova come "resetta" o meno) non è sicuro. Ogni volta che una password è in chiaro, allora non è sicura.

La domanda è se l'account (e il sito) è abbastanza importante da autorizzare SSL a crittografare la password in transito - la sicurezza è sempre un compromesso tra lockdown e usabilità e "propensione al rischio".

Per il forum di Joe Bloggs per lui e i suoi amici, supponendo che ognuno di loro segua pratiche di sicurezza decenti e abbia una password univoca che non ha riutilizzato su altri siti (!), quindi il livello di interesse di un hacker sta per essere molto basso. Per annusare quella password, è necessario che si trovino su un hop tra l'utente e il server, che in genere è un'attività molto impegnativa per gli account di basso valore (lo lascia nel forum). Se riutilizzano le password, il valore di ciascun account aumenta, ma la dimensione della retata è ancora relativamente bassa rispetto a un semplice attacco di phishing su conti bancari o social media.

Se si desidera che le password siano crittografate prima del transito e non siano suscettibili agli attacchi di riproduzione, è necessario utilizzare qualcosa come mod_auth_digest , che utilizza un meccanismo di risposta alle sfide. Il tuo CMS o altro script potrebbe avere un plug-in o "MOD" che abilita questa opzione.

Non esiste una soluzione analoga per le password nelle e-mail: una volta inviata, è un testo semplice e non puoi fare nulla al riguardo **. Basta non farlo!

Vedi PlainTextOffenders.com per esempi di cattive pratiche di "password in email", insieme a storie correlate di pratiche peggiori che diventano evidenti dalle email .

.

.

** Questo ignora l'opzione della crittografia PGP, ma richiede la chiave pubblica PGP del destinatario in modo che tu possa crittografarla solo per gli occhi, a cui generalmente gli script non avranno accesso e molti utenti non avranno nemmeno impostato