Un esempio di anestetico e’ tutta la serie di minchiate che mi hanno scritto per email dopo il mio articolo sul discorso “cambiate la password” in seguito alla scoperta del baco di SSL. Ed e’ buffo come chi si sforza di alzarsi in alto per sputare sugli altri mostri, nel farlo , di non aver afferrato bene cosa sia successo. E specialmente, riceverne un FALSO senso di sicurezza, pericolosissimo.
Per prima cosa, rimango della mia opinione: cambiare la password quando sono ancora validi i cookie di autenticazione significa semplicemente che state mettendo la chiave sotto il tappeto. Quei cookie possono venire usati per simulare la sessione, anche (e specialmente) MENTRE cambiate la password.
Quindi rimango della mia opinione: PRIMA distruggete OGNI cookie di sessione, e poi, eventualmente, se vi va cambiate la password. (cosa che andrebbe fatta regolarmente comunque).
NON DICO che non sia corretto cambiare la password. Dico che SENZA terminare OGNI sessione, e togliere OGNI cookie di sessione dal browser, non e’ sufficiente e vi offre un FALSO senso di sicurezza. Cosa fare lo scrivo sotto.
In ogni caso, chi mi ha scritto mostra dei livelli di incomprensione del problema impressionanti.
Per prima cosa, in un sistema ben disegnato tra la business logic ed internet ci DEVE essere un elemento di separazione sul layer applicativo.
Significa circa questo:
INTERNET => FRONTEND => BACKEND => (Eventuale) Database.
quello che chiamo “frontend” e’ un elemento di separazione, nel caso di HTTP un reverse proxy, che si limita a trasformare eventualmente il protocollo, e ovviamente validarlo – nella misura in cui deve comprenderlo per eseguire un forward. Sarebbe meglio che ogni => corrispondesse ad uno strato di filtraggio dei pacchetti. MA tant’e’.
Questo significa che ANCHE leggendo la RAM di uno di quei frontend, non ci dovete trovare la logica che esegue l’autorizzazione. E siccome il trasporto SSL finisce li’ per forza di cose nel design che ho descritto, allora non ci trovare la password nota. Al massimo ci trovate quella INVIATA.
Se un sistema non e’ costruito cosi’, NON dovete cambiare la password. Dovete cambiare fornitore, sistema, social network, eccetera. Cambiare la password in un sistema che NON ha lo strato che io chiamo qui “Frontend” non serve ad un cazzo: e’ un sistema soggetto a cosi’ tanti espedienti ed attacchi legati al protocollo in uso che la sua sicurezza e’ ridicola di suo.
Si, molti cantinari di successo usano queste architetture. E sono , appunto, dei cantinari di successo.
A quel punto, arriva la second aobiezione: ma c’e’ un tipo che ha mostrato uno snoop di Yahoo, dove si vede chiaramente che le credenziali vengono passate in chiaro dentro una POST.
L’ho letto anche io. Ma ci ho letto piu’ di voi.
L’uomo bianco ha inventato tante cose, dagli hash salt ai nonce. Esistono autenticazioni a piu’ fasi , autenticazioni con challenge (come kerberos/NTLM), digest e hash. Vedere credenziali passate in quel modo mi fa letteralmente scarezzo.
No, un sistema del genere non va usato punto e basta. Se qualcuno mette credenziali dentro una POST senza fare un minimo di hash e senza un nonce, cosi’ come sono, e le invia solo perche’ crede che in questo modo SSL lo protegga non ha capito una cippa.
Qualsiasi azienda ha dei dipendenti. Che possono essere felici o meno. Che possono sniffare il traffico o meno. Che possono rivendere la roba o meno ad altri.
Inviare le credenziali in quel modo significa che esse arrivano magari criptate sotto SSL sino al frontend, ok, ma poi vanno in chiaro dal frontend sino all’applicativo. Per fare un esempio significa che, essenzialmente, significa che un operatore qualsiasi della stessa azienda, un indiano da 100 euro al mese, ve le sniffa tranquillamente e se le rivende.
Ora, la password DEVE essere salvata dentro un hash criptato dentro il database sul backend, e trasmessa SENZA essere leggibile durante la POST. In questo modo l’hash con le credenziali arriva illeggibile sino alla business logic, criptato sino al frontend e poi almeno illeggibile. Sarebbe buona norma che l’hash venisse generato aggiungendo una stringa unica, di solito si usa una data molto precisa, in modo da generare credenziali valide una sola volta, un cosiddetto hash “salt”.
Se tutto non si fa, e non viene fatto, l’ultimo dei vostri problemi e’ heartbleed. E cambiando la password vi fate un bel pannicello caldo. E’ un sistema disegnato male ed implementato peggio.
Allora, andiamo ad alcuni concetti di base, ma proprio di base:
- Un sistema che esponga la business logic ad internet senza elementi di separazione sul layer applicativo e’ un sistema insicuro per design.
- Un processo che mandi credenziali senza renderle illeggiili sin dal client e’ un sistema insicuro per design.
di conseguenza, anche se evidentemente avevo sopravvalutato Yahoo, non mi aspetto che esploitando la memoria dei proxy di frontend si trovi molto piu’ dei cookie di sessione.
Questa roba qui sotto:
non e’ una buona ragione per cambiare password. Se e’ vero, e’ una buona ragione per smettere di usare Yahoo. Il problema non e’ che il baco di OpenSSL permette a tutti di leggerla attaccando il server. Il problema e’ che quella roba non viene criptata prima di entrare su SSL.
In queste condizioni, siete ancora soggetti ad attacchi come CRIME e BREACH ( http://en.wikipedia.org/wiki/CRIME_(security_exploit) , http://en.wikipedia.org/wiki/BREACH_(security_exploit) ) ed altri, di cui soffrono MOLTI server al mondo: BEAST colpisce ancora il 71.8% dei server.
| Attacks | Security | |||
|---|---|---|---|---|
| Insecure | Depends | Secure | Other | |
| Renegotiation attack | 5.7% (−0.3%) support insecure renegotiation |
2.3% (+0.9%) support both |
84.7% (−0.4%) support secure renegotiation |
7.3% (−0.2%) not support |
| RC4 attacks | 33.4% (−2.3%) support RC4 suites used with modern browsers |
58.0% (+2.0%) support some RC4 suites |
8.7% (+0.3%) not support |
N/A |
| BEAST attack | 71.8% (+2.2%) vulnerable |
N/A | N/A | N/A |
| CRIME attack | 12.9% (−0.7%) vulnerable |
N/A | N/A | N/A |
quindi no, in ogni caso il dramma della sicurezza sono e rimangono i cookie di sessione. Nel caso di Heartbleed, poi, c’e’ da considerare una cosa. Esso legge la memoria del server di QUEL momento. Il che significa che la possibilita’ di leggerci qualcosa e’ proporzionale al numero di volte che quell’informazione passa per QUEL server.
In una sessione di posta via web, il cookie passa per il frontend (o per piu’ di uno) decine se non centinaia di volte, quando non migliaia. Mentre la password passa una sola volta, e se la sessione era salvata , non passa nemmeno sempre! La possibilita’ che vi freghino il cookie e’ MOLTO piu’ alta di quella che vi freghino la password, ammesso che la password sia in chiaro!
Quindi , ripeto: PRIMA chiudete ogni possibile sessione. POI, se proprio volete rischiare con servizi che non usano degli hash salt per mandare le credenziali nel 2014, potete anche cambiare la password, in una NUOVA sessione, con NUOVI cookie.
Anche perche’, voglio far presente un’ultima cosa: nel caso di autenticazione in due fasi, come capita quando vi fate inviare un SMS per accedere, a scatenare l’ SMS e’ la fine della sessione, ma la cessazione di un cookie associato a quel browser, come fa per esempio Gmail.
Questo significa essenzialmente che se usate l’autenticazione a due fasi, chi si e’ procurato la vostra password NON puo’ entrare perche’ non riceve il codice via SMS: ma nel caso in cui si procurino il vostro COOKIE, non vi arrivera’ proprio nessun SMS, dal momento che viene ripresa una vecchia sessione!
Ora, assumendo anche che voi usiate un sistema di autenticazione a due fasi, con invio di SMS e codice, che vi rubino la password ha poco valore: chi cerchera’ di entrare, non avendo un cookie valido, dovra’ inserire il codice che invece viene inviato solo al vostro cellulare.
Ma se vi fregano i cookie di sessione, non faranno altro che replicare una sessione esistente. In queste condizioni, non viene inviato alcun SMS.
Insomma, il pericolo della cattura di una sessione e’ MOLTO piu’ grande del pericolo della cattura della password. Alla cattura della password potete ovviare semplicemente con autenticazione a due fasi, cioe’ facendovi inviare un nonce via SMS o altro canale sicuro. Ma e’ estremamente difficile tutelarsi dalla cattura della sessione, perche’ nel caso di HeartBleed la sessione viene catturata MENTRE e’ attiva! L’attaccante NON HA BISOGNO della password, quando sa come riprodurre una sessione ancora viva!
quindi si’, e’ MOLTO piu’ importante che resettiate la sessione. Ovvero, che riportiate il browser nelle condizioni in cui accedere al vostro sito preferito richieda SIA la password che l’ SMS di conferma.
Se non usate autenticazione a due fasi, se tutto si basa su SSL+ Password senza salt hash inviate fidandosi solo della robustezza di SSL, onestamente, cambiare la password vi tutela pochissimo.
Quindi, per favore, smettetela di mobbare la minchia: il consiglio che vi ho dato e’ corretto. Terminare OGNI possibile cookie di sessione e’ molto piu’ utile che il semplice cambiamento di password, specialmente se avviene DURANTE una sessione che poteva essere gia’ stata registrata.
Per essere molto piu’ tranquilli, dovreste:
- terminare tutte le sessioni.
- se usate autenticazione a due fasi, con SMS, togliete ogni cookie dal browser, in modo che esso sia “dimenticato”.
- Quando siete dimenticati abbastanza tanto che torna la necessita’ di dare la password e farvi inviare l’ SMS di conferma (o usare il generatore di chiavi ) , allora rientrate , cambiate la password e uscite immediatamente, in modo da invalidare la sessione che avete iniziato con la vecchia password.
questo e’ tutto.
ovviamente, siete liberi di credere ai giornali e limitarvi a resettare SOLO la password. In quel caso, succedera’ che chi ha il vostro cookie di sessione potra’ ancora entrare riesumando una sessione corrente, nel caso in cui il cambio di password non produca una chiusura istantanea di ogni sessione. Se anche passa qualche minuto, l’attaccante ha il tempo di riportare la password come prima sfruttando la permanenza del cookie di sessione.
Avrete un falso senso di sicurezza. Se pensate di essere tranquilli per aver cambiato la password ma non avete terminato la sessione, come capita per esempio a molti client per mobile, succedera’ che voi magari cambiate la password usando il vostro PC, o il vostro cellulare, e una seconda sessione, di un altro PC o di un altro cellulare, saranno ancora disponibili per accessi illegali, a patto che non siano venuti meno i cookie delle altre sessioni. Inoltre, come succede con Gmail, il vostro browser sara’ considerato affidabile perche’ contiene ancora il suo cookie che non e’ legato alla sessione: questo permette ad un hacker di fare per esempio attacchi basati sul dizionario, SPECIALMENTE se le password vengono inviate in chiaro, senza salt hash o Hasty Pudding cipher.
http://en.wikipedia.org/wiki/Salt_(cryptography)
http://en.wikipedia.org/wiki/Hasty_Pudding_cipher#Encryption_and_decryption
In un sistema BEN scritto questo dovrebbe accadere poco, ma nel caso diYahoo, parliamo di un sistema che invia le credenziali in chiaro dentro una post, fidandosi del mero SSL. Quindi, non ci giurerei.
Quando leggo certe email io immagino milioni di persone che si tuffano a cambiare password USANDO SESSIONI GIA’ APERTE (per fare prima!) che sono tutte potenzialmente apribili anche da enti ostili.
E poi magari notare che hanno cambiato la password di facebook sul PC ma sul cellulare “non c’e’ stato bisogno”, e non sospettare nulla, neanche che possedendo la sessione qualcuno gli abbia rimesso la password come prima….
