Dovremmo bloccare tutte le autenticazioni in chiaro e richiedere l'autenticazione su un canale criptato?

Question

Dovremmo bloccare tutte le autenticazioni in chiaro e richiedere l'autenticazione su un canale criptato?

#1 da (6 voti)

2

Dovremmo configurare i nostri server affinché richiedano l'autenticazione su un canale crittografato e bloccare tutti i metodi di autenticazione in chiaro non crittografata?

Recentemente ho configurato i miei server per disabilitare tutte le forme di autenticazione in testo normale e richiedono agli utenti di autenticarsi su un canale crittografato con SSL. Ad esempio:

Ho disabilitato l'autenticazione con testo in chiaro POP3: ora gli utenti possono autenticarsi solo su SSL (IMAPS)
Ho disabilitato l'autenticazione del testo in chiaro SMTP: ora gli utenti devono autenticarsi tramite SMTPS (ESMPTSA)
Ho disabilitato Exchange RPC - ora gli utenti devono autenticarsi tramite SSL (HTTPS)
Ho disabilitato l'autenticazione del testo in chiaro HTTP - ora gli utenti devono autenticarsi tramite SSL (HTTPS), incluso per il back-end, la webmail e altre app web del mio sito web. Gli utenti che tentano di connettersi tramite HTTP ricevono un reindirizzamento 301 su HTTPS.
Ho disabilitato l'autenticazione del testo in chiaro FTP: ora gli utenti devono autenticarsi tramite SSL (solo FTPS)
Ho disabilitato l'accesso API da siti Web esterni (gateway di pagamento, ecc.)

L'ho implementato tramite modifiche al server (ad esempio, il modulo mod_security), bloccando l'accesso a determinate porte (ad esempio, bloccando la porta imap e lasciando aperta la porta imaps) o costruendo il mio proxy inverso per far rispettare questi requisiti .

Questa è una buona idea? Tutti dovrebbero disabilitare tutte le forme di autenticazione in chiaro (dove le credenziali vengono inviate non criptate)? Ho notato che alcune società di hosting consentono ancora l'autenticazione in testo normale; perché lo fanno? Dovrebbero disabilitare anche l'autenticazione del testo libero?

authentication passwords wifi tls sniffer

posta Andrew Smith 01.09.2012 - 13:07

fonte

1 risposta

Leggi altre domande sui tag authentication passwords wifi tls sniffer

quanto tempo ci vuole per la forza bruta che varia gli standard di crittografia? Processo di crittografia SSL e sicurezza

score 6 · Accepted Answer

La vulnerabilità non è in consentendo l'autenticazione in testo semplice , ma in utilizzando l'autenticazione in testo semplice . Ad esempio, un servizio telnet aperto su un sistema Unix non rende il sistema Unix debole - le persone che effettivamente usano quel servizio fanno lo rendono debole.

Essendo la natura umana quella che è, quando un servizio è disponibile, la gente la userà, quindi questa è una buona ragione per chiudere le porte non protette su base generale. Tuttavia, sui miei server in cui tutti gli utenti sono competenti e affidabili (perché c'è un solo utente, io, e mi fido di tutte le mie personalità), a volte trovo che valga la pena lasciare alcuni deboli gates, perché potrebbero essere utili in alcune situazioni in cui l'urgenza aggira le garanzie di sicurezza: ad esempio, potrebbe accedere tramite un telnet non protetto perché mi fido di me stesso solo in situazioni alquanto sicure (ad es. link ethernet diretto) e applicare misure di mitigazione (come cambiare la password subito dopo - non è una misura perfetta, lo so, ma le emergenze sono delle emergenze).

^{(La tua domanda tende ad assumere che il problema provenga dal WiFi, che è una dichiarazione dubbia: credere che i cavi siano sicuri e, ancora più, Internet essere liberi da intercettazioni oltre i punti di accesso WiFi, mi sembra una fantasia troppo ottimistica.)}