Newsgroup: it.comp.sicurezza.varie
Titolo: Sulla sicurezza delle password

Leggendo questo articolo
http://www.hwfiles.it/news/la-sicurezza-passa-solo-da-password-complicate-microsoft-dice-di-no_33310.html
mi e' venuto in mente che un modo per rendere abbastanza sicure
password insicure sia quello di renderle valide per una tempo molto
limitato obbligando, quindi, l'utente a cambiarle con frequenza.
L'algoritmo, in parole povere, potrebbe creare una scala, diciamo da 0
a 10, per decidere quanto sicura sia una password, ed impostare la
validita' della relativa password da 0 a 10 come conseguenza. Con cio'
si obbligherebbe l'utente a cambiare comunque una password ma per le
password giudicate facili da trovare il tempo di validita' sarebbe
sensibilmente piu' corto di password giudicate piu' difficili.
Sarebbe fattibile un approccio del genere a siti come 
ad.es
.
1. email
2. forum
3. social network
e via dicendo?
Giulio.

limitato obbligando, quindi, l'utente a cambiarle con frequenza.
No, per due ragioni.
Uno: la frequenza di cambio mi protegge ('nzomma) contro un attacco brute
force o il rischio di dimenticarmi la password da qualche parte, dove non
verra' resa nota al nemico prima di un tempo T.
A quel punto, si', cambiarla con frequenza < T mi aiuta/salva.
Due: se io uso come password "lserni" un attacco ad hoc me la trova entro
dieci secondi. Finché il 40% degli utenti usa password come "mickeymouse"
e' inutile che io ogni giorno gliela faccia cambiare in myname, mynameYY,
con YY=ultime 2 cifre dell'anno di nascita, fuck, chucknorris, e via.
===
Quello che potrebbe servire e':
* Un meccanismo di accesso che dia una... certa certezza di chi tu sia, o
  per lo meno, che tu rimanga li'. Idealmente, SSL. A quel punto il brute
  forcing posso farlo solo con una rete distribuita, o troppa pazienza.
* Un meccanismo di throttling pensato bene, per contenere questi attacchi
  - per es.: puoi inserire solo una password ogni X secondi, dove X e' il
  quadrato del numero di tentativi che hai gia' fatto da quell'IP. Adesso
  ti serve una GROSSA rete distribuita per fare bruteforcing o anche solo
  ad-hoc attack.
* Trucchi vili come, in situazioni "sospette", rifiutare una-due volte la
  password GIUSTA. L'utente che sa che e' quella ci riprova - pensando di
  aver sbagliato a scrivere - ma l'attaccante deve triplicarle *tutte* se
  vuole essere sicuro di aver bypassato il problema.
  Oppure, in situazioni "sospette", schermate di "Errore, riprova" sempre
  piu' pesanti. Non lo vedi, ma nella pagina c'e' un commento HTML con il
  base64encode di un megabyte di /dev/urandom, e finche' non scarichi per
  intero la pagina, il form non si submitta. O fallo il bruteforce a otto
  o dieci account in parallelo, troiaio! Dopo un po' non ti basta più una
  linea in fibra.
Questi sistemi qua sopra costano zero o pochissimo all'utente vero, pero'
l'attaccante adesso deve sudare sangue. L'utente buono, neanche sa che ci
sono.
Altre cose che potrebbero diffondersi in futuro:
* Chiavi pseudo-biometriche o token. Potrebbe essere un business: il sito
  ti chiede la password, e tu hai una token key con dentro un chip SHA-1,
  un cronometro e 32 byte di EEPROM con la tua password segreta nota solo
  a {CERTIFICATION_AUTHORITY}.
  Tu immetti le ultime 8 cifre di SHA1("PASSWORD:YYYY:DD:MM:HH:II"), e il
  sito invia USER,SITE,SHA1("SITEPW:8CIFRE") a {CERTIFICATION_AUTHORITY}.
  {CERTIFICATION_AUTHORITY} conosce te (USER:PASSWORD), e conosce il sito
  (SITE,SITEPW). Quindi genera cinque chiavi corrispondenti a -4...+1 min
  da adesso, e i cinque SHA1("SITEPW:8CIFRE(k)"). Se uno corrisponde, gli
  risponde "Fallo passare!"... altrimenti, "Falla passare!" <g>.
  Per un piccolo costo, l'utente ha un token potente... e il sito si puo'
  abbonare al servizio di {CERTIFICATION_AUTHORITY}.
  A meno di scassare la token key e recuperarne la password segreta (e ci
  sono chip tamper-proof) o rubarti SIA l'userpin, SIA la tokenkey, credo
 che il sistema si aggiri difficilmente.
* Sistemi alla KeyLemon.
Leonardo (che ok, ora la fa passare)
-- 
The thoughts of others were light and fleeting,
Of lovers' meeting, or luck, or fame.
Mine were of trouble, and mine were steady:
So I was ready when trouble came.

   risponde "Fallo passare!"... altrimenti, "Falla passare!" <g>.
E' per caso questo il meccanismo adottato da alcune banche che ti
danno una chiavetta generatrice di password monouso? Puoi spiegare
meglio il meccanismo, per favore?
Giulio.

 So I was ready when trouble came.
Sometimes is nice to think of luck,
or to be aiming for the fame,
but for having thought of troubles,
you should not at all be blamed.

  che il sistema si aggiri difficilmente.
Vero, ma l'accesso abusivo lo fai lo stesso.
Trojanizzi il client dell'utente "vero", e fai in modo che ti recapiti i
cookie di sessione dopo che l'accesso l'ha fatto lui.
Da quel momento in poi sei dentro, indipendentemente da quanti salti
mortali l'autore del sito ha fatto fare all'utente per garantire la
"incopiabilità" delle credenziali.
Che è il vero problema attuale dove meccanismi di quel genere sono usati
oggi...
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Puoi spiegare meglio il meccanismo, per favore?
Nel caso della banca, SITO e CA sono la stessa "persona".
UTENTE si fa rilasciare da CA un token (chiavetta hardware) e un PIN.
Quindi, CA conosce (PIN, PASSWORD).
Nella chiavetta tamper-proof e' "archiviata" la password, e ogni minuto
il chip genera una stringa "PASSWORD:ANNO:MESE:GIORNO:ORA:MINUTO", e ne
calcola un hash, lo converte in un numero e ne fa, che ne so, il modulo
un milione. Così ottiene un numero fra 000000 e 999999. E lo mostra. Lo
chiamiamo VARKEY.
SITO chiede a UTENTE due dati: PIN e VARKEY. UTENTE glieli da'.
Per verificare che VARKEY sia giusta, SITO+CA ripete lo stesso conto di
token - solo che, siccome l'orologio potrebbe essere sfasato, genera un
ventaglio di chiavi consecutive. Se una corrisponde, ci siamo. Se no, o
è una chiave falsa oppure è una chiave danneggiata, col clock fottuto.
Volendo essere finisssssimi, CA potrebbe stimare il "drift" del clock e
compensare gradualmente. Se vede che ogni mese resti indietro di 1 min,
fra sei mesi alle 17:25 controllerà con la chiave delle 17:19... ma qui
siamo alla poesia.
Nel caso che SITO e CA siano diversi, e CA non si fidi di SITO (e/o del
mezzo di trasmissione) SITO e CA concordano una password per SITO, e la
comunicazione avviene come dicevo piu' sopra. Se anche intercetti tutto
il traffico, non ne ricavi niente.
Le RSA-Keys di Unicredit, quindi forse anche altre, sono blindate anche
contro un replay attack (due operazioni in meno di 1 m non accettano la
medesima varkey, benche' questa venga altrimenti accettata per un breve
periodo dopo la scadenza), che altrimenti e' un punto debole (IMHO) del
sistema (debolezza improbabile, vabbe').
Leonardo


cookie di sessione dopo che l'accesso l'ha fatto lui.
Vero. D'altra parte e' possibile adottare contromisure: il metodo di
autenticazione Digest usa un nonce, ma e' possibile implementarlo "a
manina" server side. Quando un nonce arriva doppio, capisci che c'e'
qualcuno che sta facendo la festa al tuo cliente.
Ovviamente, trovato l'inganno fatta la legge: il trojan potrebbe per
esempio crashare il browser, o inserirsi nel mezzo riserializzando i
nonce (se po ffa', anche se preferirei svuotare il proverbiale pozzo
nero usando una cannuccia -- patisco di meno).
Comunque, si', se il terminale e' insicuro si puo' far festa tutti.
Leonardo


 So I was ready when trouble came.
Giulio
---


 ti richiederebbero un gigabit di banda.
Come puoi obbligare qualcuno a scaricare 1MB di roba? Non esistono
tool in grado di prevenire cio'?


 ancora un'altra password?
Esatto.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 conto corrente, non alla password di accesso che puoi cambiare.
In realtà, si riferisce allo specifico token che la banca ti ha dato, ed
è "cablata" al suo interno...


 è "cablata" al suo interno...
Ho detto che "si riferisce al conto corrente e non alla password".
Ovvero, è il conto corrente che è legato a quel token, e le procedure
si adeguano, la password è una ulteriore barriera.


you should not at all be blamed.
Non male :-) - il secondo verso ha bisogno di una limatina, e il primo va
accorciato di una sillaba. 'Often nice are thoughts of luck', forse... Ma
non male, niente affatto male.
Naturalmente Housman si sta rivoltando nella tomba :-D


Non esistono tool in grado di prevenire cio'?
No :-D ... al massimo puoi negoziare una connessione compressa. Ma se
nel commento c'e' il base64encode di una sequenza casuale, piu' di un
tanto non la comprimi.


 Leonardo
Beh, considera che l'ho creata in pochi secondi, mentre la chiavetta
mi generava la password monouso :)

 tanto non la comprimi.
http://xkcd.com/538/
Un Paperino monoURLante.

Un Paperino monoURLante.
Purtroppo pero' qui non siamo nella situazione "1-vs-NSA", in cui xkcd
rulez, ma in quella di "un milione di scimmie contro 1 scammer". E li'
considerazioni tipo il bruteforcing parallelo di password banali vanno
fatte.
Vero è che in quel caso vale anche l'aneddoto dei due esploratori, che
corrono per salvarsi inseguiti da un leone: uno dice "Non ce la faremo
mai! Non possiamo correre piu' di un leone!", e l'altro risponde "Dici
bene, ma... a me basta correre piu' veloce DI TE".


 Comunque, si', se il terminale e' insicuro si puo' far festa tutti.
"quasi tutti", i conti in sofferenza stanno crescendo al galoppo, e se non 
c'è trippa in dispensa...
-- 
Sans
non ho ancora sentito parlare di furto di debiti, anche se ormai mi 
attendo di tutto da questa Italia.

   linea in fibra.
Questa invece te la boccio: per quanto tu possa avere banda, una
botnet ne avrà sempre di più. E in pratica ti stai puntando da solo
alla testa una DOS-gun... senza avere nulla un più di quello che hai
con un semplice tarpitting.
bye!

con un semplice tarpitting.
Si' e no. La DOS-gun ce l'ho puntata alla testa fin dal momento in cui
metto sul sito "index.html": una botnet ha comunque piu' banda di me e
non gli fa differenza richiedermi un milione di index, o mille paccate
di login.
L'unica differenza reale e' che mentre prima un brute-force era "solo"
un brute-force, adesso diventa un DoS proporzionato all'intensita' del
brute-force stesso.
In teoria, sarebbe molto meglio un tarpitting ip-based: ad ogni errore
ti restringo la banda per N secondi.
Pero', in questo modo anche in caso di errori "onesti" rischio di fare
fuori una quantita' di utenti che non c'entrano niente - tipo chiunque
mi stesse usando FastWeb.
E i bruti danno fastidio solo a me e ai propri colleghi di rete.
Con il metodo del DoS forzato, i bruti danno fastidio anche al proprio
ISP, il che migliora le probabilita' che qualcuno faccia qualcosa :-),
e la possibilità del tarpitting ce l'ho comunque sempre; e l'effetto è
abbastanza devastante su ogni singolo zombie, che quindi è incentivato
a darsi una svegliata, se vuol continuare a scaricare da eMule :-D
Sono d'accordo - già l'avevo detto - che non sia un'idea spettacolosa,
ma non la boccerei cosi' subito.
Leonardo


 ma non la boccerei cosi' subito.
Sì, ho letto dopo, avevo commentato d'amblè. Continuo comunque a
pensare che rispetto al tarpitting ci siano più lati negativi che
positivi.
bye!

 nota solo a {CERTIFICATION_AUTHORITY}.
esagerato :) basterebbe un banale OTP
Al momento della creazione dell'account utente, viene inviato allo
stesso
un PDF generato "al volo" contente il "pad" OTP da stampare; questo pad
conterrà una griglia indicizzata da numeri e lettere e ciascuna casella
di
tale griglia conterrà poi una lettera o un numero
All'atto della creazione dell'account l'utente dovrà inoltre specificare
il
proprio "metodo di lettura" ad es. solo orizzontale, solo verticale, N
simboli in verticale, N in orizzontale ...
Al logon il server richiederà il nome utente; all'immissione di questo
il
server presenterà due "coordinate" relative al "pad OTP" di tale utente
richiedendo l'immissione della password
L'utente, in base alle coordinate e seguendo il proprio personale
"metodo di lettura" procederà quindi ad immettere le lettere/numeri
iniziando dalle coordinate fornite dal server
Nel caso in cui il pad OTP venisse smarrito/rubato l'accesso all'account
sarà comunque protetto dal "metodo di lettura" adottato dall'utente (o
volendo stare più tranquilli, visto che un banale verticale o
orizzontale
è più facile da forzare, impostato dal server)
Un esempio di tale tipo di approccio è
http://en.savernova.com/index.php?id=14


http://en.savernova.com/index.php?id=14
Carino... ma se il pad OTP è smarrito, tempo tre-quattro tentativi ti
beccano.
A meno che l'uso di un metodo di lettura sbagliato[1] triggeri subito
la disattivazione della card.
Leonardo
[1] il 99% degli utenti sceglie comunque "orizzontale, partendo dalla
    casella di inizio, andando verso destra". E peccato che sia arduo
    supportare cose tipo "a salto di cavallo"


     supportare cose tipo "a salto di cavallo"
è per quello che parlavo di far "generare" al server il
metodo di lettura invece di lasciarlo all'utente; alla fine
della fiera basterebbe ... che so ...
due verso destra
quattro in basso
tre verso sinistra
ad ogni modo, e visto che ci siamo, credo che quanto
è reperibile qui
http://ossbox.com/index.php?page=wordlist
http://ossbox.com/arcmd5/
possa far comprendere quanto sia importante l'uso
del "sale" in fase di calcolo degli hashes :)

tre verso sinistra
Quello mi pone due problemi: uno, che il punto di partenza viene ristretto
a una zona anche molto più piccola (in questo caso non si possono usare le
ultime quattro righe, le prime tre colonne e le ultime due).
Due, che l'utente 'un se lo riòrda e lo scrive da qualche parte, di regola
sul retro della OTP card.
Token per token, sarei per distribuire una OTP key. L'unico vantaggio, nel
caso della OTP card, è se l'utente può stamparsela da sé.
Leonardo


 nel caso della OTP card, è se l'utente può stamparsela da sé.
Nel caso di "savernova" c'era (al momento sembra non attiva) l'opzione
per stamparsi la propria card; in qualsiasi caso, l'esempio che ho fatto
prevedeva proprio la generazione al volo di un PDF contenente la card
da stampare

>> Token per token, sarei per distribuire una OTP key.
dimenticavo...
si, è un'alternativa; considerando che ad oggi si trovano
SDK per le smartkeys (incluse quelle RFID) basterebbe
usare una di queste impostando un determinato numero
di OTP in modo da forzare la sostituzione della card dopo
un determinato tempo (alla fine uno deve anche mangiare)
il problema è che a quel punto ti serve un lettore mentre nel
caso di "savernova" lo hai già "incorporato" :)

il s/w fosse abbastanza furbo da evitare tali combinazioni
That's what *I* said :-)




No, mi riferivo appunto ai token con lettore, tipo questo:
http://www.partnerdata.it/it/otp-starter-kit.htm
Eviterei l'RFID.
http://www.pcworld.com/article/119661/does_your_car_key_pose_a_security_risk.html
Credo che esistano degli "OTP pad" sia per SymbianOS che per
iPhone. L'algoritmo e' sempre lo stesso (si carica dentro al
pad un PIN, e ci si dimentica; il server ce l'ha; poi, viene
generato un codice di 6/8 cifre (alfa)numeriche basandosi su
SHA o MD5 di PIN.YYYY.MM.DD.HH.II[.USER_AUTH].
http://www.itunes.com/app/vipaccess
Dato che SHA/MD5 ci sono anche in Javascript, e' semplice il
porting su quasi ogni dispositivo moderno browseruto. Non e'
possibile pero' usare il VIP di Verisign per il proprio sito
senza pagare pegno a Verisign.


 iPhone. L'algoritmo e' sempre lo stesso (si carica dentro al
si ok; ma se perdi (o ti rubano) il "pad elettronico" o il telefono
siamo
punto ed a capo, anzi, non hai neanche il "reading method" che, per
quanto poco, per lo meno un /pochino/ ti salva il cuBo

 usare una di queste impostando un determinato numero
oppure vedere se per caso questa roba qui
http://www.openauthentication.org/specifications
possa essere utilizzata :D


[cut]
Beh ma questo mica sarebbe un male  :P
ciao,
Gabriele

Beh ma questo mica sarebbe un male  :P
'un dici mia male neanche te ]:-D


 limitato obbligando, quindi, l'utente a cambiarle con frequenza.
cut
Io, vermente, mi sono sempre fatto altre domande:
è un ovvio bene che la finestra di pw, sul presupposto che qualcuno o 
qualcosa stia spiando il monitor, visualizzi al posto della password una 
serie di asterischi invece dei caratteri alfanumerici digitati, ma poi, 
anche ammesso di non inserire permanentemente una password in qualche 
anfratto del filesystem presente sull'HD, chi mi assicura che un 
trojan-keylogger-stealth, insediatosi in background nel sistema, non vada a 
leggere, dentro le RAM, i blocchi ASCII dei caratteri digitati e poi li 
invia, lungo la rete, sempre in background, da qualche parte?
Voglio dire: non è affatto necessario aprire un qualche tipo di browser per 
esser certi che in background il PC non combini qualcosa in rete: prendete 
per esempio un windows XP non registrato. Dopo un certo numero di 
riaccensioni del PC, di punto in bianco Xp si blocca: esce una banalissima 
finestrina che invita a connettere il pc ad internet e, fatta la connessione 
ed inserita sempre in quella finestra il product-key, ecco che la 
registrazione avviente e tutto riprende a funzionare. Immaginiamo se tutto 
sia possibile, con le password, in sottofondo, senza che l'utente ed il 
firewall se ne accorgano.
Sarebbe possibile?