Newsgroup: it.comp.sicurezza.varie
Titolo: Double pwd

Salve, non dovrebbe essere OT....
sto lavorando, dal punto di vista commerciale,
su un sistema di "sicurezza" per la protezione di accessi non desiderati ad
un servizio offerto ad aziende per la gestione dei propri dati in remoto
tramite Internet
La domanda non è troppo tecnica e non si riferisce alla sicurezza delle
macchine dove risiedono i dati, il nostro partner IT sta facendo un lavoro
egregio, ma alla procedura di login da remoto.
Vengono creati vari livelli di accesso a seconda dell'abilitazione a vedere
e/o modificare categorie diverse di dati.
Considerato che a livello emotivo, l'argomento sicurezza delle informazioni
aziendali residenti in remoto, è uno degli ostacoli più duri da superare
nella presentazione del nostro prodotto, abbiamo pensato di introdurre
un'offerta a doppia password.
Ogni account esegue il login tradizionale con userID e password che gli
permette di essere riconosciuto, ma prima di potere accedere il sistema
richiede random una seconda password tra un elenco di 40 alfanumeriche e
case sensitive (esempio "please type password n° 35") che compare in una
lista che viene aggiornata ogni tot settimane e spedita agli utilizzatori.
Scusate ho finito
Il tutto è già in uso, banche, siti ecc... ma pare abbia un buon impatto nel
tranquillizzare i clienti
La domanda...quali potrebbero essere obiezioni anche irrazionali possono
venire poste?
I sw che rintracciano password a forza bruta possono funzionare?
Il problema non si pone a livello di esperti, ma solo a livello di
concorrenti curiosi o dipendenti malfidati e/o licenziati...
ConsiderandoVi esperti, potreste elencarmi tutte le possibili obiezioni in
modo da preparare risposte credibili
Grazie per la pazienza
--
Dodo©
[se un pc non funziona espandilo]

 I sw che rintracciano password a forza bruta possono funzionare?
Di solito non si attaccano sistemi remoti a forza bruta. O per lo meno, un
simile attacco puo' essere fortemente rallentato implementando dei ritardi
in seguito alle autenticazioni fallite ed e' identificabile e bloccabile
prima che possa essere efficace.
Fabio

 Fabio
--
Dodo©
[se il tuo pc non funziona espandilo]
:-)

 
Il problema principale che vedo in questo tipo di approccio è che la 
lista delle 40 password verrà quasi sicuramente conservata in formato 
elettronico o cartaceo nei dintorni dei PC utilizzati per accedere al 
servizio (magari unitamente alla password normale, sic!) e quindi non 
protegge da possibili intrusi che abbiano accesso fisico a questi dati 
(e buona parte delle attività illecite parte dall'interno o da ex-
collaboratori, come tu giustamente sottolinei). 
Senza contare che entrambe le password possono essere intercettate da 
un keylogger (o da uno sniffer se non sono crittografate, ipotesi che 
spero sia da escludere), anche se in questo caso l'uso della "lista" 
obbliga chi volesse introdursi illegalmente a catturare un certo numero 
di password o tentare un certo numero di accessi in un tempo 
relativamente breve (durante la validità della lista), sperando che il 
server gli chieda una delle password catturate.
La lista inoltre (sempre se viene spedita in chiaro) può essere 
intercettata durante il "transito" tra il mittente e il destinatario 
(o, peggio, i destinatari), soprattutto in una rete locale non troppo 
sicura (PC che restano loggati anche se l'utente non è presente, 
accesso alla posta elettronica in pop3 etc.).
Per una soluzione "hardware" puoi dare un occhiata a questo link 
(dovrebbe essere quello di cui parla Fabio Panigatti):
http://www.rsasecurity.com/products/securid/index.html
Oppure puoi considerare la possibilità di implementare lo stesso 
sistema tramite software e costruire un generatore di password che, a 
partire da quella nota al cliente, generi un password valida solo per 
una sessione oppure generi una seconda "password" a partire da una 
stringa fornita dal server dopo il login. 
Questa opzione è più economica (o meglio, potrebbe essere più 
economica, visto che dipende dal numero di utenti e da chi sviluppa il 
software), ma meno sicura, visto che il programma può essere copiato 
senza che nessuno se ne accorga (anche se si può fare in modo che il 
suo funzionamento sia vincolato a uno specifico PC), mentre la card 
deve essere sottratta (ed è quindi probabile che l'utente se ne accorga 
in tempi relativamente brevi).
Un sistema che può essere ancora più sicuro (e rassicurante dal punto 
di vista "psicologico") è quello di fornire al cliente un log degli 
accessi ai suoi dati, in modo che possa essere lui direttamente a 
controllare gli accessi e a rilevare situazioni anomale.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

 controllare gli accessi e a rilevare situazioni anomale.
Log che IMHO deve essere memorizzato anche sul client stesso in modo da 
verificare che i due log combacino (quante volte non ci ricordiamo 
qual'e' l'ultima volta che ci siamo loggati ad un dato servizio?)
Just my 2 eurocents
-- 
HappyCactus - Registered Linux User #209744
http://utenti.tripod.it/happycactus
Made with 100% recycled electrons

 > controllare gli accessi e a rilevare situazioni anomale.
ma infatti, il mio problema è forse troppo commerciale
non si riesce a spiegare che non esiste rapporto tra lo sforzo richiesto per
violare un sistema
ed il reale interesse che dati aziendali di vendita o di trend di mercato
possono avere
ero solo preoccupato dal fatto che potessero uscire obiezioni a caldo,
magari dal responsabile IT che sta appollaiato sullo schienale della
poltrona dell'amministratore che sta firmando il contratto
:-)
Grazie ancora
--
Dodo©
[se non funziona espandilo]

 :-)
Giusto, meglio essere previdenti. ;)


 
E' però abbastanza difficile farlo se il client accede ai dati tramite 
un semplice browser (e magari non sempre dallo stesso PC).
Forse può essere utile spedire un email (magari all'utente e al suo 
amministratore) o un SMS per segnalare il collegamento appena terminato 
il login. E' una rottura di scatole, ma potrebbe consentire di rilevare 
immediatamente accessi non autorizzati (sempre che chi prova ad 
accedere non sappia del "trucchetto" e non sia in grado di intercettare 
gli e-mail e cancellarli) se il cliente controlla la posta in tempo 
reale o perlomeno con una certa frequenza (e attenzione).
Comunque anche un semplice log periodico potrebbe far balzare 
all'occhio accessi effettuati dal terminale di un certo utente quando 
questo non era presente (se gli utenti accedono con un IP fisso 
potrebbe essere necessario che un potenziale intruso abbia accesso 
fisico al PC o almeno alla rete locale) o accessi effettuati da PC 
diversi da quello normalmente utilizzato (il server potrebbe generare 
dei certificati per i client). 
Se l'utente passa per un proxy o per qualche tipo di gateway il log di 
questo potrebbe essere "incrociato" con quello del server (ma questo 
permette solo di escludere accessi da PC esterni o comunque non in 
grado di passare per il proxy/gateway comune).


 cosa intendi [...]
Intendevo dire che una volta che voi avete consegnato le card al cliente,
questo deve avere una sua procedura interna per gestirle. O se la scrive
da solo (ma in quest'epoca di outsourcing e' facile che non abbia al suo
interno gli skill per farlo) o se la fanno fare fuori (che so: da voi:)).
Fabio

 contratto 
Tieni presente che il cliente tende (giustamente) a moltiplicare di 
molto il valore dei _suoi_ dati, rispetto a quello che puoi considerare 
tu che li consideri solo da un punto di vista "tecnico".
E come metro per il "valore" dei dati non devi considerare quello di un 
generico e ipotetico "intruso", ma quello di chi potrebbe trarre 
vantaggio dall'accesso ai dati o dal loro danneggiamento.
Ad esempio il database con l'elenco dei clienti è un "bene" aziendale 
molto prezioso e l'idea di perderlo, vederlo danneggiato o passato alla 
concorrenza preoccupa chi da quei dati ricava contratti, ordini e alla 
fine della fiera quattrini.


 dei certificati per i client).
Ma pensate davvero che dopo avere massacrato noi sul tema sicurezza
venga davvero, in azienda, dedicata una persona che effettua questi
controlli?
Io non so valutare a fondo, anche nella nostra azienda ci siamo divisi le
competenze
ma vi garantisco che dal punto di vista commerciale è un problema
Mi va bene creare un sistema sicuro
ma è anche vero come dite che "rendere sicuro il server è solo il primo
passo"
come penso in tutti i settori
se implementi troppo il sistema vai fuori mercato con il prezzo
o meglio
non sei più competitivo con i grossi sitemi proprietari
che non ti proteggono manco per nulla
ma sono *branded*
potenza del marchio


 Ciao, veritą per veritą...speravo in una risposta, ma non ci credevo,


 un semplice browser (e magari non sempre dallo stesso PC).
Infatti, direi impossibile. Certo le premesse parevano altre...
A mio parere, la soluzione potrebbe essere in una applicazione client che 
risiede su CDRom e un'autenticazione basata su smartcard e doppia chiave 
per attivare un tunnel criptato. Una specie di doppio SSL...


 Lo so che il 99% di loro usa IE, lo so.....
In questo senso credo che una maggior sicurezza sia dato anche 
dall'applicativo utilizzato, IMHO potrebbe essere un programma su CDROM 
che non fa uso di browsers (o ha il proprio motore integrato)


 che non fa uso di browsers (o ha il proprio motore integrato)
se il vero problema è lo sniffer ok, lo dobbiamo considerare...
ma come facciamo a fare funzionare un applicazione in locale (che sia su CD
Rom o su HD non cambia)
che possa aggiornarsi sui dati per cui dalla sede centrale ad esempio è
stato fatto un update 1 ora prima
sto andando un pò a caso, e magari si capisce che sarebbe meglio parlaste
direttamente con le persone che si occupano della realizzazione
così perdiamo un pezzo non piccolo del messaggio marketing su cui abbiamo
costruito il lancio del prod.
non so se avete avuto esperienze analoghe
ma che cosa è meglio rischiare, la domanda è tendenziosa, forse un pò troppo
da venditore
rischi un cliente evoluto che ti sniffa informazioni (probabilità 1/100)
o rischi di andare fuori bersaglio
perchè alla fine un applicativo su cd o su hd
diventa un installazione
e caschiamo nelle licenze d'uso
spero di non esserci andato io fuori bersaglio
:-)
sto camminando su un terreno minato e non vorrei dire strafalcioni


Grazie a tutti
ci lavoro
mi fermo qui...grazie del 3ad
--
DodoŠ
[se non funziona espandilo]

 sto camminando su un terreno minato e non vorrei dire strafalcioni
Si discute proprio per dissipare i dubbi! ;)


anche se te lo rubano gli mancherebbe la password per utilizzarlo.
Esatto, UserId personale piu' password composta da 2 parti: una parte
codice personale e una parte e' il pin rilasciato dal token.
ciao
-- 
Giacomo Savastano