Oggi mi son ritrovato ad aggiungere alcune classi legate alla cryptografia in un mio assembly di Utilità generali. ...beh non è della cryptografia che voglio parlare che di materiale ce n'è abbstanza a cominciare dall'articolo di Aldo, Costruire un utile wrapper per semplificare l'uso dei CryptoServices (Parte 1) e Costruire un utile wrapper per semplificare l'uso dei CryptoServices (Parte 2).
Il problema che mi son posto è stato se decompiplano l'assembly vedono quale è l'algoritimo di decryptazione... ma poco male mi son detto se lo obfusco il codice si capisce poco nulla. Ohibò mi son detto ma la prima cosa che fare io non è certo decompilare l'assembly! cerchei subito di vedere - senza fare troppi sforzi - se l'assembly mi espone classi e metodi per decryptare l'eventuale stringa cryptata. Cosa mi interessa a quel punto se l'assembly è obfuscato... il mio obbiettivo non è sapere come è stata cryptata una password, a me serve solo decryptare la password per poter hackerare nel sistema :-p
Come impedire che posso succedere questo? Includere la classe di decryptazione come privata/interna e obfuscata in tutti gli assembly che ne hanno bisogno? naaa a me non piace riciclare il codice, sono più per una politica di riutilizzo e quindi di librerie. E comunque anche se si usano classi internal... System.Reflection fa miracoli :-p
Sapevo dell'esistenza di attributi per le limitazioni dei permessi di utilizzo e così mi sono informato meglio: StrongNameIdentityPermissionAttribute. L'attributo permette di limitare l'accesso ad un determitao metodo o classe ai soli assembly che sono firmati da uno specifico StrongName.
La scelta finale quindi sarà:
- firmerò l'assembly con strongname, che fa sempre bene
- decorere le classi della cryptografia con StrongNameIdentityPermissionAttribute impostando la proprietà Action = SecurityAction.LinkDemand
- obfuscerò le stesse classi per impedire intrusioni via Reflector
...manka qlkosa?
posted @ domenica 30 gennaio 2005 17:58