Il testo in chiaro su https è davvero una buona idea? [duplicare]

Question

Il testo in chiaro su https è davvero una buona idea? [duplicare]

#1 da (3 voti)
#2 da (2 voti)

4

L'invio di password in chiaro su https è abbastanza sicuro, il traffico è crittografato, rendendo praticamente impossibile l'intercettazione.

Tuttavia, una volta sul lato server, è ancora testo normale. Ovviamente, la memorizzazione delle password richiede una corretta crittografia, ecc. Ma che ne dite di monitorare strumenti, registrazione, ecc.? Non è possibile che le password di testo in chiaro finiscano nei log, ecc.? Anche quando usi il POST?

Se monitorassimo la comunicazione, vedremmo anche le password in testo normale. Un semplice sommario invece del testo normale renderebbe più difficile per noi vederlo e ricordarlo. Sì, posso comunque accedere a molti dati sensibili. Sì, posso usare le tabelle arcobaleno per decifrare l'hash MD5. Se vogliamo fare male, possiamo fare male. Ma perché dovremmo consentire a me e ai miei colleghi di vedere password in testo semplice?

Dato che le persone tendono a utilizzare la stessa password per più servizi online, avere una password per alcuni dà accesso a più dati solo di quella persona.

passwords tls

posta Taco Jan Osinga 05.03.2015 - 15:25

fonte

2 risposte

Leggi altre domande sui tag passwords tls

Come calcolare il fattore di esposizione? IPsec: AH in modalità tunnel è sicuro?

score 3 · Answer 1

Le buone idee sono limitate nel tempo.

Proteggere le password con MD5le era una volta una buona idea. Poi sono state scoperte le tabelle arcobaleno e le collisioni MD5. Quindi ora è una cattiva idea.

L'invio di password in chiaro su HTTP è una pessima idea, l'invio di password in chiaro su HTTPS è un'ottima idea per confronto , ma ci sono ancora approcci migliori che puoi adottare.

Memoria - Come guida generale, devi presupporre che il server a cui stai inviando le tue credenziali sia sicuro, quindi non preoccuparti troppo delle password in chiaro che vengono conservate in memoria a meno che tu non sia cercando di sviluppare applicazioni ultra-sicure.

Log - I log in genere non contengono alcun dato HTTP POST / UPDATE, perché questi dati sono potenzialmente molto sensibili - e talvolta memorizzarli in file di log non crittografati sarebbe illegale - come quando un client invia i dati della carta di credito per l'elaborazione di un pagamento.

Le password devono solo essere inviate come parte del corpo della richiesta HTTP, mai nell'URL per il sito e preferibilmente non nelle intestazioni HTTP. L'autenticazione HTTP BASIC utilizza un campo password nell'intestazione, protetto primariamente con Base64 - ma questo è solo per impedire alle persone di eseguire il surfing la password, non la proteggerà da nient'altro.

Puoi consultare Hash password lato client , che sarebbe coinvolgere l'hashing della password sul lato client prima che venga inviato al server - così anche il server non avrebbe mai il testo della password reale (e dovrebbe comunque continuare a saltarlo e cancellarlo comunque), ma questo è più complicato da configurare e non è raccomandato per tutti quelli che non capiscono cosa stanno facendo.

score 2 · Answer 2

L'invio di password in testo normale su HTTPS è sicuro.

Se sei preoccupato della registrazione, dovresti controllare l'intera implementazione, compresi framework e strumenti. Potrebbe esserci qualche codice AOP che potrebbe arrivare ai dati prima di accedere al contenuto delle variabili. Quindi il codice di registrazione potrebbe essere un problema di sicurezza.

Ricorda sempre di aggiungere una parola salt alla password prima di eseguire l'hashing.