Newsgroup: it.comp.os.linux.sys
Titolo: VPN Cisco con keyring

Ho visto poco fa un tecnico dotato di VPN cisco
con chiavetta per generazione chiavi tipo quella
delle banche.
Interessante, ma non ha saputo darmi ulteriori info.
1) Sapete di cosa si tratta e dove si compra?
2) Esiste niente di simile anche in ambito opensource
magari con openvpn? In particolare ï¿œ comoda la chiavetta.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 magari con openvpn? In particolare è comoda la chiavetta.
SecurID è un autenticatore che -tra le altre cose- funge da server Radius.
Ergo, qualsiasi cosa possa autenticarsi su radius può usare le
"chiavette"; anche OpenVPN.
-- 
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/

 "chiavette"; anche OpenVPN.
Ottimo. Direi perfetto.
Hai idea dei costi, per caso?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 Hai idea dei costi, per caso?
Per la soluzione RSA?
Alti. Dati (a memoria e con beneficio d'inventario) di qualche anno fa
quando lo installammo da un cliente:
licenza del software + una dozzina di token, circa 12-15K€.
I token durano un 2-3 anni suppergiù, dopodichè vanno sostituiti, a un
costo di qualche centinaio di euro l'uno...


 licenza del software + una dozzina di token, circa 12-15K€.
Quindi ci vuole il loro server più il token.
Leggevo online che si parla di circa 90$ ad utente
con un minimo di 10 utenti, ma non so se il sito è
affidabile, ne dubito.
Eventualmente altre alternative per poter avere accessi
a VPS discretamente sicuri? Se mi dovessero rubare
il computer con sopra i certificati, avrebbero da
indovinare solo la password, statica.
Non dovrebbe difficile fare un generatore di codici
del genere. Se l'orario fosse sincronizzato tra server
e token, si potrebbe prendere la data attuale,
'scombussolarla' ad esempio in YYYYIIMMHHDD,
concatenare una stringa segreta e calcolarne il CRC.
Vien fuori un codice di 8 caratteri che cambia ogni
minuto e che il server sa replicare perchè ha lo
stesso orario della chiave, conosce la stringa
segreta ed anche l'algoritmo usato per generare la data.
L'unico modo per indovinare i codici sarebbe avere
la chiave segreta e conoscere l'algoritmo di
'scombussolamento' della data.


 'scombussolamento' della data.
O fare una analisi statistica di quel che esce da quell'aggeggio e
ridurre lo spazio delle fasi della funzione sottesa. Poi usare quanto
acquisito per "sparare a caso" il prossimo numeretto solo all'interno
dei cluster a probabilità più alta e attendere il sistema al varco.
Se c'è una cosa *molto* peggiore di perdersi i certificati è mettersi ad
ideare meccanismi di autenticazione crittografica senza avere alba delle
basi matematiche su cui vanno basati.
Astenersi.


 Astenersi.
Vero, ma imho bisogna anche vedere l'ambito di implementazione.
Non parlo di una banca, parlo della mia VPN personale
Per poterla bucare si dovrebbero verificare tutte le seguenti
condizioni:
1. mi rubano il computer con il certificato salvato
2. riescono a capire che la password del certificato viene cambiata
ogni 60 secondi
3. riescono ad intuire quale possa essere l'algoritmo che genera
queste
password
4. hanno culo e riescono a generare la prima key.
5. hanno nuovamente culo e beccano anche la password ssh dei server.
Questi passaggi in un range temporale breve, ovvero da quando
mi accorgo che mi han fottuto il computer e quindi revoco il
certificato.
Tutto sto marasma per fare cosa, entrare nei miei server? A che pro?
Non sono una banca, non sono un ente pubblico, ...
Però, avere una password che cambia in 60 secondi, potrebbe
permettermi
di usare lo stesso sistema per più server, evitando di dovermi
ricordare
decine e decine di passphrase.
(ma se uno perde quella chiavetta che succede? chi la trova ha libero
accesso alla VPN?)

 accesso alla VPN?)
I meccanismi tipo RSA SecurID rappresentano essi stessi una coppia
utente/password, in cui il nome utente è (o è associato a) il singolo
token, mentre le password sono composte da un PIN (scelto dall'utente in
fase di attivazione del token e/o cambiato in qualunque momento)
concatenato da un numerillo sputato dal singolo token.
Quindi l'autenticazione avviene sulla base de: il seriale del token
(username) + qualcosa che l'utente SA (il PIN) + qualcosa che l'utente
HA (l'aggeggio spara-numerilli).
Esattamente come con i certificati: common-name (username) + passphrase
(qualcosa che l'utente SA) + certificato (qualcosa che l'utente HA).
La differenza è "solo" che il certificato -in quanto file- lo puoi
potenzialmente copiare, la "chiavetta" no.
Ma dal punto di vista della sicurezza della singola
transazione/autenticazione non c'è molta differenza...


 transazione/autenticazione non c'è molta differenza...
Quindi a livello implementativo, o ci si tiene la soluzione
standard dei certificati protetti da password, oppure si passa
alle chiavette in stile RSA?
non ci sono vie di mezzo?

 
i prezzi dei token mi sa che sono scesi; dopotutto dovrebbero essere 
token simili a quelli che danno in giro per i giochi online:
http://eu.blizzard.com/store/details.xml?id=221003617
che poi dovrebbero essere questi:
http://www.howardcomputers.com/accessories/detail.cfm?id=S6415712
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 non ci sono vie di mezzo?
Di vie di mezzo ce n'č infinite. Il problema č sapere quali sono i
requisiti di quella che vorresti tu... :-)


 
http://www.howardcomputers.com/accessories/detail.cfm?id=S6415712
Figata, ne ho ordinate subito due.
Alla peggio, ho buttato via 50$
Il server di autenticazione è opensource e volendo possono essere
riprogrammate per autenticare su software custom.
Funzionano con VPN sia tramite radius, sia tramite autenticazione
diretta ad /etc/passwd
in sostanza da quel che leggo, si associa uno username al seriale
della chiavetta,
si inserisce la password e subito dopo la chiavetta, la quale
autentica.
se la chiavetta inserita corrisponde a quella associata allo username,
si entra.
Ci son le API per autenticare su PHP, Python, Perl, C, Java ed altro...

 requisiti di quella che vorresti tu... :-)
L'ho trovata (credo).
Poter attivare un concentratore VPN che non si basi solo sul
certificato
ma anche su username, password, ed un 'oggetto' che devo avere
fisicamente
con me (io o i clienti).
Con quel Yubico funziona esattamente così.
Si attiva la VPN, si inserisce la passphrase del certificato.
OpenVPN, approvato il certificato ed attivato il canale, richiede
username e password.
Username e password sono autenticati solo se corretti (ovviamente) e
solo se associati
alla chiavetta inserita, così oltre a dover rubare il certificato,
identificare la sua passphrase
dovrebbero trovare anche username e password di auteticazione ed in
più avere
fisicamente la chiave per generare il codicino random.
Quello che non mi è chiaro, però, è come faccia ad arrivare codicino
random (ed il seriale della chiave)
al server VPN. Inserisco la chiave usb nel pc, e poi? Simula la
digitazione dei tasti?
(un po tipo le pistole seriali per i barcode)

 Alla peggio, ho buttato via 50$
A titolo di cronaca, puoi usare anche dei token software:
http://www.howtoforge.com/openvpn_wikid_strong_authentication
http://www.wikidsystems.com/community-version

 
http://www.wikidsystems.com/community-version
Grazie per il link, me li leggerò con calma.
Comunque sia, no, voglio un token hardware da avere fisicamente con me
o da dare fisicamente al cliente. Devo autenticare la persona, con una
discreta
sicurezza.
Far generare un token via software, implica dover fare un pannellino,
e come sempre accade in questi casi, il cliente da le password alla
segretaria, che
le scrive sul monitor, ne fa la fotocopia, le salva sul portatile etc
etc. E saresti
vulnerabile agli accessi del pannello stesso. Praticamente metti in
piedi un portone
blindato poi lasci le chiavi sotto lo zerbino.
Con un token hardware, noi lo consegnamo al cliente, il cliente firma
la ricezione
del token hardware consegnato nelle sue mani, poi son cazzi suoi. Non
può dire
di certo di aver fatto fotocopie, di averlo salvato sul pc ed aver
perso il computer etc
etc etc etc. Il 99% delle scuse le tronchi sul nascere. L'altro 1% non
ci interessa anche
perchè difficilemnte si risolverebbe, con mezzi "umani".

 wrote in 
news:f3ae1552-ac5b-4048...@35g2000prb.googlegroups.com
:

aggiungo anche che a seconda del tipo di utenti con cui hai a che fare, 
il 'pezzo di ferro' potrebbe evitarti un po' di problemi con gli utenti 
tosti (visto qui dove lavoro, quando e' partito il sistema con i token 
per l'accesso vpn).
io ho avuto a che fare con almeno un paio di utenti a cui fare entrare in 
testa la complessa procedura 'clicca sul bottone, leggi il numero e al 
posto della password scrivi [pin del token]+[numero che hai appena letto 
dal token]' ha richiesto del tempo.
se avessi dovuto spiegare che a video dovevano avere contemporaneamente 
due finestre (input credenziali vpn + il programma genera token) avrei 
dovuto prevedere 2 o 3 giorni di corso specifico.
n.b.: se l'azienda per cui lavori fornisce anche cellulari aziendali, sul 
modulo di consegna devi scrivere in grasseto, grosso e lampeggiande che 
il pin per il token e' diverso da quello del cellulare e non 
intercambiabile.


 dovuto prevedere 2 o 3 giorni di corso specifico.
Non sono a questi livelli.
Il sistema in questione, però, mi sembra particolarmente semplice.
Ho letto il manuale e la chiavetta emula una tastiera, pertanto basta
inserirla e spingere il bottone. Fine.
Di conseguenza i clienti aprono la VPN, nella schermata di immissione
credenziali inseriscono lo username, selezionano il campo con la
password
e spingono il bottone. Non devono fare altro.

 intercambiabile.
...se poi gli installi l'app per la generazione dei token sul cellulare,
la frittata è fatta :-D


 inserirla e spingere il bottone. Fine.
Fico.
Chissà un keylogger come se la sfanga... :-D


 Chissà un keylogger come se la sfanga... :-D
non gli fa nulla.
non viene inviata la chiave, ma una stringa codificata in AES mediante
una chiave che vai a riprogrammare nella chiavetta.
Lui genera una stringa composta da l'id univoco della chiavetta, il
timestamp,
il numero di sessione, il numero di accensioni.
concatena tutto e critta in AES mediante la chiave che hai
precedentemente
programmato nella chiavetta, quindi il keylogger loggerebbe una
stringa codificata,
che però non potrà più usare perchè la volta successiva il timestamp,
il numero di
utilizzi ed il numero di accensioni non corrisponderebbe.
(e lo stesso problema lo avresti con i token che sparanumerini, ho
visto solo una
banca utilizzare un pad virtuale in flash, che ad ogni utilizzo
scombussola anche i numeri)

 utilizzi ed il numero di accensioni non corrisponderebbe.
Arrivate le chiavette yubico.
Non ho la più pallida idea, però, di come generare la
stringa crittata in AES lato server, tutte le prove che
ho fatto generano una stringa ben più lunga di quella
passata dalla chiavetta.


 passata dalla chiavetta.
Figata! Ci son riuscito.
Sostanzialmente si tratta di:
- leggere l'id pubblico della chiavetta
- verificare che tale ID sia presente in
un proprio database.
- prendere la chiave AES associata al
publicID letto in precedenza (dal db, oppure
leggerla da qualche altra parte)
- decrittare la stringa passata dalla
chiavetta con la chiave di cui sopra
- verificare che il CRC generato partendo
da un campo ottenuto decrittando la stringa
sia valido
- se è valido, leggere il secretID della
chiavetta e confrontarlo con quello associato
nel db (il secretID deve essere associato al
publicID)
- se è tutto valido ,fare il check sul numero di
accessi ed accensioni della chiavetta. Quelli
della chiavetta devono essere superiori a quelli
presenti nel db, altrimenti si tratta di un replay
malevolo (un pirla cerca di autenticare con una
stringa già utilizzata, magari sniffata)
- se tutto è ok, si aggiornano le sessioni su db
e si autentica.
Si tratta di un AES a 128 bit, non sicurissimo,
ma, anche se intercettassero la chiave (con un
bruteforce) dovrebbero anche identificare l'id
pubblico della chiavetta, l'id segreto della
chiavetta ed il numero esatto di accessi ed accensioni
della chiavetta stessa. Se l'utente la usa di frequente,
si riducono le probabilità di una falla tra un
utilizzo e l'altro.
