Newsgroup: it.comp.sicurezza.varie
Titolo: sincronizzazione codici

Alcune banche danno una specie di chiavetta che visualizza un codice di sicurezza valido per pochi minuti, utilizzabile per confermare una transazione monetaria via web. Come fa il server a sapere che e' proprio quello il codice valido in quel momento, e non altri? Se l'utente preme per sbaglio due volte il pulsante (oppure la linea cade in quel momento e la transazione non va a buon fine), il server e la chiavetta non sono piu' "allineati". Come si fa a mantenere questo "allineamento"?
Grazie a chi mi rispondera'.

 Come si fa a mantenere questo "allineamento"?
 
Con l'orologio. Il clock è sufficientemente preciso da poter mantenere
una sincronizzazione accettabile per tutto il tempo di vita (in genere
la durata della pila al litio) del dispositivo OTP.
 
saluti sincronizzati
-- 
Dignità e moneta:
http://dottormistero.blogspot.it/2013/04/dignita-e-moneta.html
 

Un bel giorno 
apel...@libero.it
 digitò:

Presumo che oltre a usare l'orario come ti hanno già detto, ci sia anche un
meccanismo simile a quello dei telecomandi rolling code delle auto: siccome
il ricevente conosce in anticipo tutta la sequenza dei codici futuri, non
si limita a confrontare il codice ricevuto col prossimo atteso ma lo
confronta con i prossimi N attesi.
 
Ad esempio i vecchi telecomandi delle auto di solito controllavano non più
di qualche decina di codici, quindi potevi fare gli scherzoni alla gente
premendo il loro telecomando un centinaio di volte lontano dall'auto. :)
 
-- 
Fletto i muscoli e sono nel vuoto.

 meccanismo simile a quello dei telecomandi rolling code delle auto:
 
Viene generato un numero sulla base dell'orario e del codice seriale
dell'OTP, che deve restare segreto (noto solo alla banca), perchè
l'algoritmo è piuttosto diffuso. :(
 
saluti sgamati


 Alcune banche danno una specie di chiavetta che visualizza un codice di sicurezza valido per pochi minuti, utilizzabile per confermare una transazione monetaria via web. Come fa il server a sapere che e' proprio quello il codice valido in quel momento, e non altri? Se l'utente preme per sbaglio due volte il pulsante (oppure la linea cade in quel momento e la transazione non va a buon fine), il server e la chiavetta non sono piu' "allineati". Come si fa a mantenere questo "allineamento"?
 
Puoi vedere qui:
http://it.wikipedia.org/wiki/One-time_password
 
la versione in inglese è più dettagliata.
 
Cristiano

 l'algoritmo è piuttosto diffuso. :(
 
Di solito queste chiavi generano un codice nuovo ogni 30 secondi. Ma 30
secondi sono pochini, per me un drift di un paio di secondi al giorno è
normale (dubito che in queste chiavi ci sia un oscillatore stabilizzato in
temperatura) quindi mi aspetto che già dopo 2-3 settimane l'orologio vada
fuori sync. Ecco perché dico che per me c'è anche un algoritmo tipo rolling
code che controlla anche i codici "limitrofi", magari in un range di
qualche minuto...


 qualche minuto...
 
Dipende dall'implementazione, ma di norma (ovviamente) c'è; in caso di
sfasamento riscontrato l'autenticatore provvede anche a conservare
l'offset associato al dispositivo, in modo da "seguirlo" man mano che va
fuori tempo.
 
 

temperatura)
 
Un quarzaccio vulgaris da 32,768 MHz sgarra di un paio di secondi l'anno,
e in Cina te li tirano dietro: un pacchetto di chewing gum al pancale :-)
 
Il drift c'e', ma si compensa sul lungo periodo. A meno che uno stia, per
tutto l'anno, in Siberia o, beato lui, a Papeetee.
 
Leonardo
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.

 e in Cina te li tirano dietro: un pacchetto di chewing gum al pancale :-)
 
Per ottenere 2 secondi all'anno serve una precisione di poco più di 0.1
ppm, che è totalmente al difuori dalle possibilità dei quarzetti da 32 kHz.
Un OCXO con precisione di 100 ppb costa qualche decina di euro, e comunque
consuma ordini di grandezza di troppo per essere alimentato a pila.
 
Di solito i quarzetti da 32 kHz hanno una tolleranza iniziale attorno a 20
ppm (1.7 secondi al giorno) che può essere compensata con una taratura
individuale di ogni orologio, cosa che farà senz'altro Rolex o Omega ma
dubito che la facciano i cinesi. :) Poi c'è un drift dovuto alla
temperatura che dipende dal quarzo, ma diciamo un valore tipico di 0.5 ppm
per 10 gradi. Infine c'è l'aging, che aggiunge qualche altro ppm di errore
all'anno.
 
Quindi l'orologio cinese sbaglia tranquillamente anche più di due secondi
al giorno, e l'orologio calibrato al meglio sbaglia probabilmente di una
trentina di secondi all'anno il primo anno, che poi diventano minuti gli
anni successivi.
 
Ora non so a quale dei due limiti si avvicini l'aggeggio del codice delle
banche, ma credo che sia molto più facile usare l'algoritmo pseudo-rolling
code piuttosto che porsi domande difficili su che quarzo ha messo dentro il
subappaltatore della tua chiavetta. :)


subappaltatore della tua chiavetta. :)
 
Hai ragione tu. Ho fatto una prova stupida con la mia, di chiavetta: ho
segnato il codice e l'ho inviato in ritardo. La banca mi butta fuori se
uso un codice piu' vecchio di tre minuti... ma se e' scaduto da meno di
quel limite, il codice e' accettato.
 
Non sono riuscito a capire se usano un qualche sistema di update "anti-
drift", ma non ho fatto troppi esperimenti perche' non ci tengo molto a
chiudermi fuori dal mio conto corrente.
 
Mi ricordavo una precisione maggiore per i quarzacci (ricordo del corso
di Elettronica) - pero' mi ricordavo anche la frequenza in MHz. Si vede
che anch'io ho avuto un "drift", e due secondi il giorno sono diventati
due secondi l'anno, e i kHz MHz :-D
 
Se il drift e' lineare, fra altri vent'anni m'inventero' i quarzi da 32
GHz con una precisione di due secondi al secolo.


 subappaltatore della tua chiavetta. :)
 
Sarebbe semplicissimo usare il sistema S/KEY (usato da alcune banche):
http://en.wikipedia.org/wiki/S/KEY
 
e darebbe un grado di sicurezza molto al di sopra di quanto non serva 
per l'home banking.
Il problema è che il costo del chip per fare l'hash (v. il link) non è 
trascurabile e allora preferiscono usare sistemi molto più economici, 
tipo quelli a tempo o, ancor peggio, tipo quelli con la tesserina con i 
vari numeri.
 
Cristiano

 vari numeri.
 
Il fatto è che la sicurezza delle transazioni su piattaforme home
banking *non è* intaccata sul piano della robustezza crittografica dei
meccanismi di autenticazione, ma dalla compromissione dei client usati
per le transazioni.
 
Sicchè, almeno al momento, focalizzarsi sulla funzione crittografica
usata per la generazione dell'OTP è semplicemente guardare al problema
sbagliato.
 

 di Elettronica) - pero' mi ricordavo anche la frequenza in MHz.
 
Ricordi abbastanza bene, un quarzo ha una precisione di qualche ppm, il
problema della deriva termica si pone solo nel breve periodo, nel lungo
statisticamente si compensa.
 
I "quarzi" da 60 ppm o più sono quelli sintetici, ma credo che neppure
in questo caso si ponga il problema, perchè tutti i generatori di clock
attuali hanno la possibilità di impostare un offset.
 
Ovvero, il problema non è la precisione in ppm ma la deriva costante
dovuta alle imprecisioni di costruzione (frequenza di oscillazione più
alta o più bassa), se però il chip che genera il clock può gestire un
offset stabilito sulla temperatura media, il problema sul lungo periodo
(entro certi limiti) non si pone.
 
Basta una misura automatica a 20 gradi in fase di assemblaggio e
l'impostazione fissa dell'offset conseguente.
 
offset di saluti


 sbagliato.
 
Infatti credo che nessuno in questo thread si sia focalizzato 
sull'adeguatezza delle funzioni crittografiche.
Il *metodo* (non sto parlando della funzione crittografica) della 
tesserina (che è quello che devo usare io) è oggettivamente il più 
debole di tutti, mentre gli altri metodi sono intrinsecamente più 
robusti (primo fra tutti S/KEY), a prescindere dalla funzione 
crittografica utilizzata per generare i numeri da usare per l'OTP.
 
Cristiano

 di randomize è la solita, anche la sequenza di numeri random è la stessa
 
E' il principio utilizzato per il protocollo S/KEY. La differenza 
sostanziale rispetto a quello che dici è che i numeri "casuali" (che 
casuali non sono) sono protetti con un algoritmo crittografico.
 
Cristiano
 

 usa e getta (valido solo per quella transazione).
 
[cut]
 
Esempio: il tuo PC ha un trojan che permette all'aggressore di vedere 
ciò che fai. Ti ha anche cambiato il DNS.
Mentre stai sul sito della banca, da remoto "vedono" ciò che scrivi e 
quindi al momento di immettere il numeretto della chiavetta...ZAC! ti 
chiudono la connessione e proseguono i truffatori ;)
Ah da notare che con sto sistema hanno fregato pure chi si connette da 
cellulare e usa le chiavette OTP; infettato lo smartphone (non iPhone 
che io sappia).
 
Per inciso, IMHO le chiavette sono scomode e utili sono alla banca che 
così paga di meno di assicurazione.
Che senso ha l'home banking se devi portarti dietro una cavolo di chiavetta?
 
 
ciao
Gabriele
 
 

 usa e getta (valido solo per quella transazione).
 
Infatti è solo pieno... :-(
Zeus, Citadel e diversi altri trojan; ti lascio il divertimento di
scoprire che fanno e come lo fanno...
 
 

 scoprire che fanno e come lo fanno...
 
Nota: osserverai che, in tutti i casi, il meccanismo messo in atto da
questi trojan non consiste nell'attaccare il meccanismo autorizzativo
(indipendentemente dal fatto che si tratti di OTP, OTP-like o
"tesserine") bensě semplicemente nel bypassare il problema ingannando
l'utente attraverso lo strumento che l'utente usa per accedere al
servizio (ovvero, in linea di massima, il browser).
 
A dimostrazione, appunto, che il meccanismo di autorizzazione č
-indipendentemente dal metodo applicato- di gran lunga la cosa piů
robusta nell'intero sistema home-banking; il cui punto debole sta altrove.
 


Proseguono a fare cosa? Il numeretto lo scrivi dopo che hai impostato 
tutti i dati del bonifico o di quello che è. Loro possono solo 
divertirsi a cambiare l'importo verso un beneficiario che hai scelto tu.
Almeno per come funziona l'home banking che ho io.
 
Cristiano

 servizio (ovvero, in linea di massima, il browser).
 
Io sto leggendo, ad esempio, qui:
http://en.wikipedia.org/wiki/Zeus_%28Trojan_horse%29#FBI_crackdown
 
in cui si parla del trojan che consente di rubare le credenziali per 
accedere all'home banking e di rubare migliaia di dollari per volta.
Ma se al momento di autorizzare la transazione i pirati non conoscono 
l'OTP da usare, cosa rubano?
Questi trojan funzioneranno sicuramente per particolari situazioni, ma 
in altri casi non la vedo così semplice farsi fregare i soldi con un 
trojan. Forse penso troppo solo al mio tipo di home banking, ma per fare 
un bonifico bisogna inserire il beneficiario ed autenticarlo tramite 
l'OTP che la banca ti manda sul cellulare, poi devi usare i numeri del 
tesserino... Insomma, ce ne sono di cose da compromettere!
 
Cristiano

 Compromissione di che tipo? 
 
Tipo un attacco MITM?
 
 

 tesserino... Insomma, ce ne sono di cose da compromettere!
 
No.
Basta il browser e la giusta tempistica.
 
Semplifico, ma il funzionamento è all'incirca questo: mentre l'utente
sta effettivamente utilizzando il proprio homebanking, il trojan (che
gira sulla macchina stessa) provvede ad inviare alla banca una richiesta
di bonifico.
 
Ovviamente, la procedura della banca richiede di autorizzarlo attraverso
l'inserimento di PIN, OTP e quant'altro, in una pagina che descrive cosa
sta avvenendo, sicchè all'utente basta leggere per capire che qualcosa
non va.
 
A questo, tuttavia, provvede nuovamente il trojan: preleva da un sito
"altro" (controllato da chi ha eseguito il setup della botnet) del
codice JavaScript e lo carica come parte della pagina di homebanking.
Questo JS provvede ad eseguire l'overlay di parte della "pagina vera"
(quella mandata dal webserver della banca), mettendo al posto del
messaggio originale un messaggio innocuo che non lasci intendere
all'utente cosa sta avvenendo[1].
 
Al che, di fatto, l'autente autorizza, senza saperlo, l'esecuzione di un
bonifico.
 
Le varianti si sprecano, ma pressappoco il meccanismo è questo per
tutti, tanto che al riguardo si è coniato il termine
"man-in-the-browser", inteso come variante dell'usuale MITM.
 
 
Riguardo all'efficacia, le banche normalmente sono molto restie al
divulgare dati reali su questo genere di eventi, quindi temo ti tocchi
fidarti... ;-)
 
 
 
[1] Per rimanere perfettamente in topic con questo thread, un messaggio
pressochè perfetto potrebbe essere "L'orologio della tua chiavetta si
sta disallineando; reinserisci nuovamente PIN e OTP per sincronizzarla".
 

 Fine della storia.
 
Magari! :-(
 

 fidarti... ;-)
 
Non mi tocca fidarmi; mi fido perch� il metodo usato dall'home banking 
che utilizzo io � sicuro, nei limiti del ragionevole e ribadisco ci� che 
dicevo: non vedo alcun tipo di compromissione che possa inficiare una 
transazione basata su un codice usa e getta; adesso aggiungo l'ovvio: a 
patto che il metodo sia studiato bene.
 
Cristiano

 Tipo un attacco MITM?
 
Il protocollo S/KEY ï¿œ vulnerabile ad un attacco MITM, ma (a quanto ne so 
e per quello che ho constatato personalmente) le banche utilizzano un 
metodo che aggiunge altri fattori ai protocolli derivati dall'S/KEY 
(tipo l'utilizzo di un telefonino "validato"). Tali aggiunte consentono 
di mantenere la complessitï¿œ dell'attacco MITM ad un livello non 
inferiore rispetto alla complessitï¿œ di un attacco per invertire l'hash.
 
Cristiano
 

 patto che il metodo sia studiato bene.
 
 
Il problema � proprio il fatto che "studiarlo bene" non � sempre cos�
semplice... :-(
 
Il meccanismo autorizzativo che utilizzi una notifica out-of-band (come
l'SMS), ad esempio, � perfetto per chi usa l'home banking per finalit�
private.
 
Ma � difficile pensare di applicarlo pari-pari ad un accesso homebanking
ad uso aziendale, dove le operazioni non sono una manciata al mese ma
possono facilmente raggiungere le decine al giorno ed operate da persone
diverse...
 


Si, cominciano a diffondersi, ma sono ancora una minoranza. In ogni 
caso, se l'attaccante intercetta l'accesso alla banca, sicuramente 
aspetterï¿œ che la prima fase di autenticazione (quella in cui in genere 
si usa il secondo fattore di verifica) sia terminata. Non ho ancora 
visto banche che richiedono la conferma tramite il secondo fattore 
durante una fase dispositiva, al massimo richiedono un secondo codice o 
una parte di esso
 
 

dall'orario no?
 
Credo ci siano chiavette cosi' - devi premere un pulsante per fargli tirare
fuori il numero. Ne vidi una che pareva una carta di credito.
 
Ma la mia e' tipo orologio al quarzo anni '80, un display con scritto sopra
 
	123456
 
e ogni minuto scatta una cifra nuova. Usa un hash di qualche tipo piuttosto
buono, anche: ho da qualche parte un file con ottomila codici consecutivi e
ha passato un ballino di test statistici [1].
 
Leonardo
 
[1] in particolare, la chiavetta non usa un Mersenne Twister. Non che fosse
    un gran rischio - stacci tu, dieci ore a fotografare una chiavetta - ma
    cosi' e' ancora meglio.


tutti i dati del bonifico o di quello che è.
 
Eh... no:
 
Cliente > Truffatore:	"Login alla banca. Ecco user e pass"
Truffatore > Cliente:	"Sei loggato"
Truffatore > Banca:	"Login alla banca. Ecco user e pass" (e funziona)
Cliente > Truffatore:	"Dammi il saldo"
Truffatore > Banca:	"Dammi il saldo"
Banca > Truffatore:	"Ecco il saldo: XXYYZZ EUR"
Truffatore > Cliente:	"Ecco il saldo: XXYYZZ EUR"
Cliente > Truffatore:	"Voglio fare un bonifico"
Truffatore > Cliente:	"Mandami i dati"
Cliente > Truffatore:	"Ecco i dati: CANISTRACCI OIL LTD., 100 EUR"
Truffatore > Cliente:	"Impostati correttamente (seee). Dammi il PIN"
Cliente > Truffatore:	"Ecco il PIN"
Truffatore > Cliente:	"Gentile Cliente, c'e' stato un problema. CLICK"
Truffatore > Banca:	"Voglio fare un bonifico"
Banca > Truffatore:	"Mandami i dati"
Truffatore > Banca:	"Ecco i dati: TRUFFI E SBUFFI, XXYYZZ EUR"
Banca > Truffatore:	"E' l'intero saldo! Sei sicuro?"
Truffatore > Banca:	"Sicurissimo"
Banca > Truffatore:	"Impostati correttamente (sigh). Dammi il PIN"
Truffatore > Banca:	"Ecco il PIN"
Banca > Truffatore:	"Bonifico inviato. Annullabile entro le ore 20"
Truffatore > Banca:	"Logout"
Truffatore > Banca:	"Login con dati errati, ancora, e ancora!"
Banca > Truffatore:	"Tre tentativi errati. CONTO BLOCCATO"
 
...e ora basta che il cliente non riesca a sbloccare il conto fino al
momento critico, e il truffatore l'ha ripulito come un fischietto.
 
Per essere sicuri, il cliente dovrebbe avere un crittografatore molto
piu' flessibile, dove inserire per es. IBAN e importo, e che generi a
questo punto un hash con il codice OTP della banca.
 
A quel punto, anche intercettare il codice non serve a niente perche'
quel codice puo' approvare solo ESATTAMENTE QUELLA transazione, e non
qualunque transazione avvenga in quell'arco di 60 (o 180) secondi.


 qualunque transazione avvenga in quell'arco di 60 (o 180) secondi.
 
Non ho capito bene cosa intendi dire, ma credo che stai dicendo qualcosa 
di simile all'S/KEY e derivati.
 
Cristiano
 

tramite un numero che la banca mi manda sul telefonino
 
Si', l'ho letto dopo. Questo ovviamente protegge l'operazione: in effetti,
non e' neppure necessaria la chiavetta a questo punto. E ovviamente adesso
e' il telefonino che e' il punto debole.


 E ovviamente adesso e' il telefonino che e' il punto debole.
 
S�, ma � talmente poco debole (per il nostro scopo) che � quasi forte 
:-) (ovviamente, mai quanto lo � l'hash).
 
Cristiano

On 21/11/13 23.12, Cristiano ha scritto:

Ed è in questa fase che già si sono visti in passato compromissioni di 
smartphone!
Invece con un "vecchio" cellulare, sei più sicuro se usi il PIN 
aggiuntivo che arriva via SMS.
 
ciao
Gabriele
 
 

 aggiuntivo che arriva via SMS.
 
Il mio dovrebbe avere una decina d'anni; credo di stare sicuro a 
sufficienza. :-)
 
Cristiano
 

 sufficienza. :-)
 
se NON è uno "smartphpone" e/o usa un OS proprietario o comunque
"obsoleto" ... vai tranQillo :D
 


 
Per una cosa del genere bisognerebbe bucare contemporaneamente sia il 
PC (per effettuare la prima parte dell'attacco) che lo smartphone della 
vittima. Quante possibilitï¿œ ci sono?
 
 

E firefox non si accorge che il certificato SSL del truffatore è farlocco?
 
Diciamo che se si dispone del pieno controllo sulla navigazione della vittima,
e se la vittima non ha il sito di homebanking direttamente nei bookmark, e non
ha installato plugin tipo CertPatrol, si puo'... spostare il problema :-)
 
Su un WiFi "captive portal" si puo' fare apparire un tripudio di popup, fino a
questo (cliccate pure, ma non cliccate "OK"), ma con tanto di istruzioni prima
per compilarlo correttamente
 
http://aegis-ca.rcub.bg.ac.rs/repository/ca.crt
 
e pagine successive di verifica che tu l'abbia fatto davvero.
 
Dopodiche' vai su 
www.paypal.com
 (192.168.0.1), e ti arriva un certificato che
e' valido quanto una banconota da venti euro[1], e autentico quanto una da 31.
 
Con alcune app, e in alcune circostanze, non vedi neanche il dialog.
 
Leonardo
 
[1] che sono venti euro solo se ti fidi della BCE, se no e' carta straccia


 dall'hacker) sarebbe uscito sul token.
 
Non penso che un unico server di una banca si possa permettere di 
calcolare miliardi di hash per ogni utente. Immagino che qualcosa come 
100 mila o anche 10 mila iterazioni sia il massimo ammissibile (quante 
transazioni potrà mai fare un utente?).
Il mio dubbio era nel senso opposto a quello che dici tu, cioè se è il 
caso di consentire più di 1 o 2 codici di disallineamento, ma forse una 
decina di codici è una tolleranza accettabile.
 
Cristiano

 Ma firefox non si accorge del certificato SSL farlocco?
 
Non tutti hanno Firefox (ma anche gli altri browser avvisano in caso di 
certificato non valido) e, soprattutto, non tutti fanno caso agli 
allarmi lanciati dalle eventuali protezioni e decidono di proseguire 
comunque la navigazione sul sito incriminato.
Come sempre accade, l'anello piï¿œ debole di solito ï¿œ  quello che si 
trova tra il monitor e la sedia
 
 

 e comunque salterebbe alla prima scansione di un buon antivirus.
 
Difatti le vittime di questo tipo di attacchi sono di solito utenti 
abbastanza inconsapevoli e piuttosto superficiali in fase di lettura 
degli avvisi. Insomma, quelli che, quando arriva una mail tipo "tua 
Carta Postamat e' guastata. Prego clika cui per efetuare richiesta di 
cambio tua Carta postepay. Basta inserire tutti tuoi codici secreti e 
noi manda te nuova carta postematpay con corriere della sera espresso 
in meno di 24 ora", loro ci cliccano subito e seguono tutte le 
istruzioni alla lettera, o per lo meno, ci pensano su un bel po', colti 
da panico... finchï¿œ non realizzano che loro manco ce l'hanno il conto 
alle Poste (ma sarï¿œ quello di mia moglie? E allora perchï¿œ mandano gli 
avvisi a me? Cosa ha combinato quella lï¿œ?).
 
 

 del codice di firefox avvelenato.
 
Non farei troppo affidamento su questo, perché il pirata investirebbe il 
tempo necessario a scrivere versioni leggermente diverse del browser in 
modo che l'AV non possa disporre delle firme e molto probabilmente 
neanche l'euristica si accorgerebbe di qualcosa.
Sono convinto, invece, che un firewall con HIPS sarebbe più efficace, a 
meno che nel PC compromesso non sia attivo un rootkit.
 
Cristiano

 che il certificato ssl sia valido anche se non lo ï¿œ.
 
Dipende sempre dal metodo che usa la banca; se il pirata non viene messo 
a conoscenza di una parte della transazione (ad esempio utilizzando il 
telefonino per un otp), mi pare molto difficoltoso per il pirata fregare 
i soldi.
 
Cristiano

 che hai fatto l'aggiornamento o c'e' qualcosa che non va?"
 
Ci sono antivirus che fanno questo?
Ho visto che l'HIPS di Comodo lo fa, ma non sapevo che lo facessero 
anche gli AV.
 
Cristiano


 
Quante possibilità non lo so, ma abbastanza da far rubare nel 2012 via 
trojan Eurograbber ben 36 milioni di euro (quelli noti, almeno) dai 
conti correnti europei a banche che pur usavano il sistema della 
conferma via SMS!
Eurograbber è il primo che mi è venuto in mente, cioè questo:
http://www.cs.stevens.edu/~spock/Eurograbber_White_Paper.pdf
 
 
ciao
Gabriele
 
 
 

 se si dispone del pieno controllo sulla navigazione della vittima
 
...non serve addirittura il "pieno controllo sulla macchina". Basta avere un
access point/router vulnerabile, e un utente un po' gonzo.
 
Poi sappiamo tutti che questo genere di cose si fa con la pesca a strascico:
avendo MILLE access point vulnerabili, speri di trovare un CENTINAIO di user
un po' gonzi.
 
Leonardo


 keylogger o intercettazione che tenga. Cosa ne pensate?
 
Una tastiera virtuale dovrebbe bastare nella maggior parte dei casi. 
Poi molte banche chiedono solo una parte del codice. Un eventuale 
intruso dovrebbe sniffare una lunga serie di sessioni per mettere 
insieme il codice completo