Newsgroup: it.comp.sicurezza.varie
Titolo: Ho fatto alcuni test alla chiavetta.

Ho voluto provare il comportamento della chiavetta nell'home banking
della Intesa Sanpaolo.
 
Prima prova
1 - ho inserito le credenziali e sono entrato in home, poi ho attivato
    l'input della password con un clic;
2 - ho atteso 30", poi ho richiesto un OTP (validità 15") premendo il
    bottone della chiavetta: l'OTP è stato accettato.
 
Quindi l'input resta attivo in attesa dell'OTP, le due cose non sono
"legate" come credevo.
 
Seconda prova
3 - dopo un nuovo accesso all'home banking, ho attivato l'input della
    password con un clic;
4 - ho richiesto un OTP, memorizzato i numeri e fatto scadere, subito
    dopo l'ho inserito: l'OTP è stato accettato.
 
Evidentemente ci sono alcuni secondi in più a disposizione per inserirlo.
 
Terza prova
5 -  con la chiavetta ho richiesto un OTP che mi sono appuntato, poi sono
    entrato in home banking;
6 - dopo aver attivato l'input ho inserito l'OTP ormai scaduto, avviso:
    O-Key non è corretto, premi di nuovo il pulsante.
 
La domanda non  è banale: come possono sapere quando viene generato l'OTP
per controllare la sua scadenza? È questo che rende la chiavetta sicura?
 
X-post & F/up su it.comp.sicurezza.varie
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-deus ex machina-
#v-

 
 
Non credo che si tratti di secondi in più (la tua prova al punto 4) 
quanto il fatto di aver già usato quell'OTP. Al punto 5 non hai 
specificato se, quando sei entrato, hai usato lo stesso OTP che ti sei 
appuntato.
 
 
 
 
-- 
__________________________________________
 
Merely Job: 
http://www.sergiotressino.it/
 
Leisure: 
http://trextrips.altervista.org/
 
__________________________________________

per controllare la sua scadenza? È questo che rende la chiavetta sicura?
 
Butto li, il token come funziona/funzionava?
E' uguale, viene creato un sincronismo tra il generante e il controllante 
che ogni tot generano la stessa psw; magari ci può essere qualche secondo di 
tolleranza.
Gi 
 
 
---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com
 
 

 per controllare la sua scadenza? È questo che rende la chiavetta sicura?
 
Il seed, questo sconosciuto (c).
 

 per controllare la sua scadenza? È questo che rende la chiavetta sicura?
 
Ma per chiavetta intendi quello che si chiama anche token?
In questo caso è temporizzato con un server che non smette mai
di generare gli stessi numeri della tua chiavetta, che ha un orologio 
interno.
Alcuni tokens (forse tutti) infatti dopo tot tentativi vengono bloccati 
e quindi vanno risincronizzati.
 
Questa in realtà è anche la sua debolezza perché se non hai altri
fattori di autenticazione basta avere la chiavetta.
Poi ci sono anche altri metodi di generare l'OTP, più o meno sicuri.
 
Qui lo spiegano bene:
https://it.wikipedia.org/wiki/One-time_password
 
 
bye
 
 
-- 
  "S'io m'intuassi, come tu t'inmii." - Dante - Paradiso IX,81

 chiavetta, che ha un orologio interno.
 
 
Non sono a rolling-code?
 
 
-- 
- Ciao, ho visto le tue foto su Facebook
   chiamami al 347******9
- Non ti sembra esagerato darmi subito il
   tuo numero?
- Sono un chirurgo plastico, posso aiutarti.
 

 
Se capisco cosa intendi forse sì, o simili al concetto di rolling code.
E' parecchio però che non ci ho più a che fare se non per motivi personali.
Era per dire però che in generale la sincronizzazione e la generazione
dell' OTP sono meno misteriose di quanto a volte si creda:-)


Il 03/05/2019 17:39, P/ero ha scritto:

Non so se lo sai, ma la chiavetta HW verrà abbandonata presto in favore 
di un riconoscimento da App Smarphone.
 
-- 
Ciò che so lo dico, ciò che non so lo chiedo!


 per controllare la sua scadenza? 
 
Il sincronismo dell'algoritmo di generazione su entrambi i lati è temporale.
 

 favore di un riconoscimento da App Smarphone.
 
Purtroppo è vero.
Stamattina facendo colazione ho ascolato per alcuni minuti rai3, stavano
parlando delle carte ricaricabili, ed intervistavano alcune donne che
erano state truffate proprio con quella carta.
 
Ovviamente c'era l'esperto a consigliarne l'uso; bene da questo argomento
sono passati a parlare della chiavetta e la persona in studio (l'esperto)
l'ha descritta come un mezzo sicuro ed affidabile.
 
Ha poi aggiunto: putroppo la recente direttiva UE ne ha proibito l'uso in
favore delle APP e che ci dobbiamo rassegnare perché è stato privilegiato
l'uso del cellulare *al solo scopo di facilitare le transazioni*.
Più chiaro di così!
 
Aggiungo io: e chi non si adegua e preferisce gli SMS che *paghi* almeno
un *piccolo contributo alla Banca*.
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-audaces fortuna iuvat-
#v-
 
 


Certo, nulla a che vedere con l'OTP. :-)
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-do ut des-
#v-
 
 

"Max max" [by Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101

Si è proprio così:
Algoritmi basati sulla sincronizzazione temporale tra server di
autenticazione e client che fornisce la password: le OTP sono valide
solo per un breve periodo di tempo, il valore da cui viene generata la
OTP è l'ora corrente.
-- 
    * b *
  *   y   *
*   Piero   *
#v+
Se perdi la calma, non la ritrovi fra gli "Oggetti smarriti".
#v-
 
 

 stesso OTP che ti sei appuntato.
 
Ovviamente si, e lo si capisce benissimo.
Dov'è scritto che ne ho generato uno nuovo?
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-cogito ergo sum-
#v-
 
 

 
http://www.avg.com
 
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-cogito ergo sum-
#v-
 
 

 bye
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-audaces fortuna iuvat-
#v-
 
 

> 
http://www.avg.com
 
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-beati monocoli in terra caecorum-
#v-
 
 

 X-post & F/up su it.comp.sicurezza.varie
 
Basterebbe bloccare lato server il codice generato per qualsiasi altra
operazione e costringere l'utente ad aspettare il nuovo OTP.
 

 dell' OTP sono meno misteriose di quanto a volte si creda:-)
 
Uhmm e generare un codice ed inviarlo tramite internet su uno smartphone è più
sicuro? Mi puoi dare un'ordine di grandezza delle sicurezza tra i due metodi? 
 
 

 
 
No non ho idea (non ho guardato) perché abbiano deciso di eliminare i
tokens fisici.
Ci guarderò per curiosità, perché visto come spesso le persone
usano il cellulare non mi sembra un gran guadagno in sicurezza.


 bye
 
Okay, se posti poi le tue impressioni sarebbe utile alla discussione.
Ciao.
 

 Certo, nulla a che vedere con l'OTP. :-)
 
Dovrei anche rispondere? Il seed, ripeto, questo sconosciuto (c) :-(
 
E scrivo anche con le migliori intenzioni...
 

 un *piccolo contributo alla Banca*.
 
Il problema della sicurezza non e' legato certo al pagamento per l'invio 
degli SMS ;-)))
 
 

"ilchierico" [by Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:3.4) Gecko/20100101

Questo c'entra come il cavolo a merenda, come suol dirsi...
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-ad audiendum verbum-
#v-
 
 

 E scrivo anche con le migliori intenzioni...
 
Me l'immagino...
-- 
    * b *
  *   y   *
*   Piero   *
#v+
Ho nascosto qualche grammo di cervello per uso personale.
#v-
 
 

 ha scritto:

Puoi tradurre per noi umani? ;)
 

 due metodi?
 
la generazione web-based è standardizzata e descritta qui nelle sue due 
modalità hmac e totp:
 
https://tools.ietf.org/html/rfc4226
 
 
https://tools.ietf.org/html/rfc6238
 
 

 ha scritto:

Mi viene complicato leggere questi articoli. Potresti darci le tue
impressioni/opinioni in modo piu' semplice? Grazie.
 

 
https://tools.ietf.org/html/rfc6238
 
 
Si, è ovvio che la trasmissione della pass dal cellulare alla banca viene
criptata, come avviene inviandola dal pc.
 
Considera tuttavia, che anche per generare l'opt la banca deve inviarti
per maggior sicurezza¹ un sms, per cui a parità di condizioni preferisco
agire con con due dispositivi diversi.
 
Cito:
¹ - Questo approccio non si basa su due dispositivi diversi, ma su due
diverse applicazioni eseguite sullo stesso dispositivo mobile. Le app
interagiscono tramite la cosiddetta comunicazione app-to-app. Ci
riferiamo a queste applicazioni rispettivamente di app bancarie e app di
autenticazione. L’app di autenticazione richiede e riceve i messaggi SMS.
 
Leggi questo riferito a banca intesa sanpaolo:
https://www.intesasanpaolo.com/content/vetrina/it/catalogo-prodotti/maggiori-informazioni-o-key-smart.html
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-do ut des-
#v-
 
 

 impressioni/opinioni in modo piu' semplice? Grazie.
 
la mia opinione è che sia adeguatamente sicuro.
penso anche che chi non attiva l'autenticazione a due fattori, laddove 
disponibile, per via di queste seghe mentali sui cellulari, sia un gran 
pirla.

 OTP è l'ora corrente.
 
se ricordo bene, dovrebbe accettare il codice generato nello slot temporale T 
corrente, ma anche il precedente e seguente. Ovviamente se inviati nel periodo 
di validità a cavallo di 2 slot (periodo = 2 slot), questo per tollerare 
eventuali fuori sincrono minimi tra chiavetta e server.
 
Disegnino: '+' =periodo di validità di un codice
Slot tempo     |  T1  |  T2  |  T3  |
Codice 1  ---+++++++++++++---|------|-----
Codice 2  -----|----+++++++++++++---|-----
Codice 3  -----|------|---++++++++++++++--
               |      |      |      |
 
Le prime chiavette che ho avuto generavano token validi 30", le ultime 15".
 
-- 
Sans

 15".
 
Come le mie.
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-deus ex machina-
#v-
 
 

 Puoi tradurre per noi umani? ;)
 
Ma veramente?  é_è
 
 
Ciao,
un TJL73 e le basi...
 
-- 
"L'indifferenza è il miglior modo per farti capire
 che non conti nulla."

 e quindi vanno risincronizzati.
 
Se il token č a rolling code, ok; ma, se č a TOTP, mi chiedo come ciň
possa avvenire, in quanto l'OTP viene generata in base al time-stamp
(oltre al seed), quindi, come fa il token a sapere che quell'OTP non č
stata utilizzata oppure il server a sapere che su quel token sono stati
generati N codici OTP non utilizzati?
 
A meno che sia un mix tra rolling code (anche solo con un contatore
incrementale di OTP generate) e TOTP.  Ź_Ź
 
 
Ciao,
un TJL73 che, in tal caso, potrebbe avere un senso...
 
-- 
"Contare sul segreto di un algoritmo [crittografico] č un grosso errore.
 Ci sono montagne di letteratura a riguardo,
 inutile affrontare il discorso ancora una volta."
                                                    -- Cristiano su ICSC


-- 
"La risposta è sempre all'interno del problema, non al di fuori."
                                                     -- Marshall McLuhan

 -- 
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
M'hanno regalato un libro, ma si sono dimenticati del software.
#v-
 
 

 generati N codici OTP non utilizzati?
 
No beh mi sono decisamente espresso male: mi riferivo a tentativi
sbagliati in fase di autenticazione (era una VPN), e dopo tre,
l'accesso non era più consentito.
Bisognava quindi chiamare a casa per far "risincronizzare" i tokens,
ma adesso che mi ci fai pensare probabilmente non aveva niente a che fare
con l'aspetto tecnico dei tokens RSA.


 Il seed io lo conosco come nodo per trasferire file:
 
Seed significa "seme" e il suo significato dipende dal contesto.
 
In crittografia, il seed č tutta un'altra cosa.
 
E' esattamente come se parlassimo di sale e tu mi dicessi che si trova
in cucina; anche qui dipende dal contesto: in crittografia, la salatura
non rende il risultato "piů gustoso", bensě "piů sicuro".
 
 
Ciao,
un TJL73 che consiglia una ricerca contestuale...
 
-- 
"Saggio č colui che cerca il sapere nell'esperienza,
 furbo č chi lo cerca su Google."
                                                          -- EL (Jesper)

 un TJL73 che consiglia una ricerca contestuale...
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
Alzhaimer e... cammina.
#v-
 
 

 anche scritto, ma io non l'avevo presa. L'età purtroppo...
 
intendeva una definizione che è specifica della crittografia.
il salt sono dei byte, generati casualmente, che vengono aggiunti (ad 
esempio) durante la generazione di un hash per rendere sicuro l'hash 
medesimo.
sicuro significa che non è possibile risalire dall'hash all'informazione 
originale, ne con il processo inverso dell'algoritmo ne per confronto con 
altri hash generati (la casualità infatti permette a parità di dato di 
generare hash sempre diversi e mai riproducibili).

 riproducibili).
 
Si, questo lo sapevo.
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-panem et circenses-
#v-
 
 

 Puoi tradurre per noi umani? ;)
 
Seed = seme.
 
Sarebbe il caso di rispolverare come funzionano le famose "chiavette" OTP.
 
No, non funzionano per magia, generano i numeri a caso utilizzando lo 
stesso algoritmo presente nel server, in modo che la chiavetta generi lo 
stesso numero che genera il server della banca, per ogni periodo di 
tempo prestabilito.
 
Quindi il punto debole e' sempre l'umano che conosce il seed/seme 
dell'algoritmo generatore di numeri.
 
Quindi una ipotetica banca bloccando tutte le chiavette di chi ha paura? 
Semplice: di chi puo' conoscere a priori il seed e l'algoritmo usato per 
generare il codice numerico, quindi un informatico che abbia lavorato 
per la banca o per il costruttore delle chiavette.
 
Semplice, no? ;-D
 
Basterebbe usare un AS-400 (cattiva questa) ma non perche' sia un 
sistema proprietario sicuro e blindato, anzi blindatissimo (c) Full 
Metal Jacket.

 Questo c'entra come il cavolo a merenda, come suol dirsi...
 
E invece non l'ho scritto io che ti secca pagare per ricevere gli SMS 
dalla *tua* *stessa* *banca.*
 

 Le prime chiavette che ho avuto generavano token validi 30", le ultime 15".
 
E allora le banche hanno veramente paura.
 

 pirla.
 
Penso anche io che tu non abbia considerato altri fattori di difesa ma 
non per questo voglio scrivere per forza queste cose.
 
Se non altro perche' non mi piacciono i flame e voglio vedere fin dove 
arriva la conversazione in pubblico.
 

 ha scritto:

Infatti il pirla sei tu:
http://www.televideo.rai.it/televideo/pub/notiziasolotesto.jsp?id=1242815&pagina=100&sottopagina=1
 
Per il resto no comment, segaiolo ;)
 

 ha scritto:

La realtà supera ogni fantasia:
http://www.televideo.rai.it/televideo/pub/notiziasolotesto.jsp?id=1242815&pagina=100&sottopagina=1
 
 

 Per il resto no comment, segaiolo ;)
 
segaiola lo dici a tua madre e tua sorella.
 
fup

 arriva la conversazione in pubblico.
 
se non ho considerato altri "fattori di difesa" non hai che da citarli, 
siamo qui nel posto giusto per discuterne, flamer è chi flamer si fa.
d'altronde io credo che qui in tanti non consideriate altri fattori di 
rischio diversi dai virus. i data breach, ad esempio, è all'ordine del 
giorno che dai siti vengano sottratte credenziali. password criptate, si 
spera, ma pur sempre in mano a chiunque e talvolta non criptate in modo 
adeguato (alcuni algoritmi di hashing sono aggredibili con il cosiddetto 
"rainbow attack").
 
 

 
http://www.televideo.rai.it/televideo/pub/notiziasolotesto.jsp?id=1242815&pagina=100&sottopagina=1
 
 
è una falla gravissima.
detto questo, se vuoi approfondire ben venga, ma se è funzionale a
svalutare l'autenticazione a due fattori (di cui stiamo parlando) 
non stai rendendo un buon servizio.

 banca o per il costruttore delle chiavette.
 
Mi hai ricordato un lavoro che feci tanti anni fa (a cavallo millennio), agli 
albori dell'operatività via telefono. Si trattava di generare un PIN di 
autenticazione che non venisse salvato in nessun DB e che venisse calcolato al 
volo con elementi non tutti conoscibili da alcuno degli addetti al progetto.
Alla fine passò la mia soluzione. Calcolato con i seguenti elementi:
1 - ID interno alla banca della posizione del correntista
2 - Data di nascita del correntista
3 - Data di rilascio del PIN
4 - Numero incrementale di rilascio del PIN
5 - Seme segreto generato una-tantum dal direttore della banca con un 
programmino dedicato che, dopo aver calcolato con altri elementi casuali l'hash 
derivato, lo criptava in codice al primo avvio. Successivamente rispondeva con 
l'hash al programma principale al momento della verifica. Per evitare errori o 
manipolazioni, il generatore del seme lo avevo progettato monouso: ci voleva 
una password per farlo girare (data al direttore per inserire un numero a 10 
cifre) e poi si bloccava, nel senso che si rifiutava di rieseguire il codice se 
un flag interno diceva di essere già stato eseguito. In caso contrario, tutti i 
PIN della banca avrebbero dovuto essere riemessi, in quanto non ci sarebbe 
stata possibilità di recuperarli per la validazione.
 
Riassumendo: il personale IT della banca conosceva 1 e 2, mentre 3 e 4 erano 
nel DB locale del call-center (isolato: unica interazione esterna era il server 
della banca che di notte sovrascriveva alcune tabelle locali del CC);
gli operatori del call center (dipendenti della banca) conoscevano 1, 2 e 3;
il direttore conosceva il seme inserito ma non il risultato di 5;
il programmatore conosceva l'algoritmo, ma non il 5 (ipoteticamente da 1 a 4 
solo se fosse stato fisicamente sul posto, niente teleassistenza per prudenza).
 
Lo stesso programma veniva usato sia per autenticare l'accesso (3 tentativi), 
sia per stampare la busta chiusa col PIN da dare al cliente.
 
So che per almeno 10 anni ha funzionato senza incidenti.
 
-- 
Sans

 Metal Jacket.
 
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-summum ius summa iniuria-
#v-
 
 

"ilchierico" [by Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:3.4) Gecko/20100101

Ti stai sbagliando, non l'ho mai scritto che mi secca pagare gli sms, il
mio scritto che hai citato era solo una considerazione sulle pratiche che
usano le banche per far soldi.
 
Ho optato per gli sms, disponibile a pagarli, perchè ritengo più sicuro
per me usare questo metodo, e quando non mi andasse più, potrò sempre
cambiarlo.
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-beati monocoli in terra caecorum-
#v-
 
 

 segaiola lo dici a tua madre e tua sorella.
 
Vedo che ti rode tanto. ROTFL!
 

 non stai rendendo un buon servizio.
 
Modifichi la discussione. L'autenticazione a due fattori ok ma su sistemi
android collegati a internet tramite app non va bene. Pirla. 
 

 ha scritto:

Salvo che una condizione di attacco del genere può essere replicata con una
facilità estrema. L'articolo diceva "basta una telefonata non risposta".
Direi che questo evidenzia una condizione di fragilità estrema.
I flamer sono quelli che iniziano ad offendere in una condizione di arroganza,
tra l'altro, immediatamente smentita dai fatti.
 

 cambiarlo.
 
Alla luce di quanto successo le banche, e credo siano poche, che abbiano
adottato il sistema degli sms a pagamento dovrebbero avere un ripensamento.
Il problema sarà far ricevere l'sms su un dispositivo non collegato ad internet.
 
-- 
Questo messaggio e' frutto di fantasia e non deve essere
collegato a persone o a fatti reali. Serve solo come spunto 
di riflessione.
 

 installato. ciaone.
 
P.S. se è vero che hanno attaccato un'app di grande diffusione e di cui tanto si
era parlato come sicura e come tale idolatrata cosa assicura che non ci siano
altre app infette. Personalmente mi convinco sempre piu' che banca e smartphone
non possano convivere, se collegate ad internet. Almeno con questi attuali S.O.
 

 non collegato ad internet.
 
Infatti, li ricevi con un "vecchio" telefonino che di internet non ha
assolutamente nulla, ed inserisci il codice nel PC.
Se questo è quello che che intendevi, se no, spiega a cosa ti riferisci.
-- 
    * b *
  *   y   *
*   Piero   *
#v+
-carpe diem-
#v-
 
 

 Vedo che ti rode tanto. ROTFL!
 
no è che io e te non abbiamo mai mangiato la pappa insieme, quindi 
cortesemente questi toni usali con i tuoi cari i quali sono sicuro 
apprezzano moltissimo.
 

 tra l'altro, immediatamente smentita dai fatti.
 
io non ho insultato nessuno. mentre correggimi se sbaglio mi sono preso 
un paio di volte di pirla e una volta di segaiolo da uno che, nonostante 
i ripetuti e pazienti chiarimenti, ancora risponde "dove vai? son 
cipolle".
comunque sì, sono arrogante al punto di dire che per me i tuoi contributi 
vanno diretti nel pattume.
 

P/ero <ppi...@woow.it.INVALID> ha scritto:

Si, intendo questo. Ormai siamo troppo abituati ad avere lo smartphone collegato
pperennemente per ricevere la notifica (qualunque programma esso sia) che
scollegarci per motivi di sicurezza sarebbe "chiedere troppo". :) anzi :(


 apprezzano moltissimo.
 
Pure tu, non lanciare la pietra e poi la ritiri "generalmente". ;) 
 
 

 vanno diretti nel pattume.
 
Fanne quello che vuoi. Personalmente non mi disturba affatto.
 
 

 fino a quando non ci sarà un sistema operativo "decente".
 
 
niente, non ce la può fare. 
 
https://i.imgur.com/6LlqCea.png
 
 

 
https://i.imgur.com/6LlqCea.png
 
 
Non apro link, mi dispiace.
 
 

 android collegati a internet tramite app non va bene. Pirla.
 
Ecco, lo sapevo, io! ;-D