Un libro, manuale o tutorial che tratti la sicurezza delle nostre applicazioni?

[seven.7]

Ciao ragazzi, mi stò cimentando nell'argomento sicurezza e sinceramente ho un po' le idee confuse, io programmo in vb.net e ho intenzione di realizzare un sistema di sicurezza basato sulla macchina del cliente (cioè con le chiavi di attivazione relativi al processore del pc...) qualcuno mi può consigliare un libro??? thanks

[W.S.]

mmm sinceramente VB e sicurezza non li vedo molto bene nella stessa frase.

Comunque, molto dipende da cosa vuoi fare, da quello che ho capito ti serve documentazione sulla crittografia (per il riconoscimento dei processi/librerie/DLL/etc), quindi qualche cosa che tratti di algoritmi di hash, cifratura a chiave pubblica e a chiave simmetrica (parole chiave: MD5, SHA, RSA, DES).

Se spieghi meglio cosa dovrebbe fare il programma potrebbe esserci anche altro, si interfaccia con un DB? Controlla solo che il processore sia quello autentico? Viene eseguito all'avvio del client o all'avvio di un determinato programma?

[71104]

Originariamente inviato da W.S.

mmm sinceramente VB e sicurezza non li vedo molto bene nella stessa frase.

perché?

[W.S.]

Originariamente inviato da 71104

perché?

E' solo una mia impressione, non potrebbe essere altrimenti visto che non uso VB. Comunque le applicazioni di sicurezza (sempre secondo me) dovrebbero essere il più minimali possibile, in modo da ridurre al minimo le funzionalità, renderne semplice la manutenzione e quindi ridurre i bug, non mi risulta che VB permetta questo, tutto qui

[71104]

Originariamente inviato da W.S.

E' solo una mia impressione, non potrebbe essere altrimenti visto che non uso VB. Comunque le applicazioni di sicurezza (sempre secondo me) dovrebbero essere il più minimali possibile, in modo da ridurre al minimo le funzionalità, renderne semplice la manutenzione e quindi ridurre i bug, non mi risulta che VB permetta questo, tutto qui

perché?

[W.S.]

Originariamente inviato da 71104

perché?

... Perchè cosa? Perchè non mi sembra che lo permetta? L'ho detto che VB lo conosco poco ed è una mia impressione, al posto di chiedere perchè, dimmi dove sbaglio.
Mi da l'impressione di non avere il controllo su quello che scrivo, disegnare l'interfaccia, cliccare e scrivere cosa eseguire a seguito di quell'evento non mi sembra il modo ideale di scrivere un'applicazione che si occupa di sicurezza.
Mi sembra perfetto per altre cose, per un archivio fotografico o tantissime altre applicazioni client, ma non per applicazioni sensibili.

[PGI-Bis]

Un grande classico della sicurezza è Applied Cryptography, di B. Schneier. Tratta non solo di algoritmi di cifratura ma anche dei "perchè" della sicurezza.

[seven.7]

In sostanza io vorrei realizzare una cosa del genere:
* il cliente acquista il programma e lo lancia su pc che vuole
* preleva il codice che contiene informazioni cifrate sul seriale del processore, del seriale del bios, sul "nome del programma" (questo per poter utilizzare lo stesso sistema si sicurezza sulla stessa macchina altrimenti la chiave sarebbe uguale per ogni programma), ecc...
* invia il codice tramite email a me e successivamente io gli posto un file contente la chiave di attivazione crittografata.
* il cliente riapre il programma e sfoglia il file di attivazione permettendo appunto l'attivazione.
Grazie cmq per l'aiuto fornitomi

[71104]

Originariamente inviato da W.S.

... Perchè cosa? Perchè non mi sembra che lo permetta? L'ho detto che VB lo conosco poco ed è una mia impressione, al posto di chiedere perchè, dimmi dove sbaglio.
Mi da l'impressione di non avere il controllo su quello che scrivo, disegnare l'interfaccia, cliccare e scrivere cosa eseguire a seguito di quell'evento non mi sembra il modo ideale di scrivere un'applicazione che si occupa di sicurezza.
Mi sembra perfetto per altre cose, per un archivio fotografico o tantissime altre applicazioni client, ma non per applicazioni sensibili.

perché?

e va bene ci aggiungo qualcos'altro
(però sappi che il "perché" rimane anche stavolta)

Originariamente inviato da W.S.

Mi da l'impressione di non avere il controllo su quello che scrivo,

di certo non hai quel controllo di basso livello che ti può dare un linguaggio come C o come C++, ma abbi pazienza, provengo or ora da una lunga discussione circa la perfetta inutilità della cosa (vedi thread "sondaggione"). non capisco quale sia il motivo che dovrebbe precludermi la scelta di Visual Basic.NET qualora volessi scrivere un'applicazione "sicura", qualcunque cosa si intenda (applicazione che si occupa di crittografia? di anti-malware? altro?). l'unica cosa che posso dire a sfavore di VB.NET è che se per scrivere tale applicazione fosse necessario utilizzare molte API Win32 allora sarebbe sintatticamente scomodo dichiarare i prototipi di tutte quante; lo dico in base a quanto ho visto circa VB6, quindi potrei facilmente sbagliarmi. se invece avessi ragione ripiegherei sul Managed C++, che mi permetterebbe di includere windows.h e di farmi i cavoli miei, ma difficilmente rinuncerei a .NET se avessi motivo di usarlo.

disegnare l'interfaccia, cliccare e scrivere cosa eseguire a seguito di quell'evento non mi sembra il modo ideale di scrivere un'applicazione che si occupa di sicurezza.

scusami ma veramente non resisto: perché?
non vedo che problemi potrebbe comportare l'uso di un ambiente di sviluppo RAD nella realizzazione di questa fantomatica applicazione "sicura", qualunque cosa si intenda.

Mi sembra perfetto per altre cose, per un archivio fotografico o tantissime altre applicazioni client, ma non per applicazioni sensibili.

che è un'applicazione sensibile? un'applicazione contenente dati riservati? anche un archivio fotografico potrebbe esserlo, no? anzi tipicamente le mie foto sono sacrosantissimi cavoli miei, no?

[71104]

Originariamente inviato da PGI-Bis

Un grande classico della sicurezza è Applied Cryptography, di B. Schneier. Tratta non solo di algoritmi di cifratura ma anche dei "perchè" della sicurezza.

giusto per chiarire: i miei "perché" sono riferiti a quanto scritto da W.S., non alla sicurezza

[71104]

Originariamente inviato da seven.7

In sostanza io vorrei realizzare una cosa del genere:
* il cliente acquista il programma e lo lancia su pc che vuole
* preleva il codice che contiene informazioni cifrate sul seriale del processore, del seriale del bios, sul "nome del programma" (questo per poter utilizzare lo stesso sistema si sicurezza sulla stessa macchina altrimenti la chiave sarebbe uguale per ogni programma), ecc...
* invia il codice tramite email a me e successivamente io gli posto un file contente la chiave di attivazione crittografata.
* il cliente riapre il programma e sfoglia il file di attivazione permettendo appunto l'attivazione.
Grazie cmq per l'aiuto fornitomi

chiarissimo: vuoi evitare la pirateria creando un sistema di attivazione del programma, nulla di più comprensibile.

le singole tappe che tu hai descritto credo che siano tutte fattibili in VB.NET, ma siccome non ho mai usato quell'IDE o linguaggio che sia non so darti suggerimenti specifici.

quello che posso suggerirti parlando però in generale per rendere più robusto il tuo sistema di attivazione è di distribuire il software in forma criptata e di vendere le chiavi di decifratura. la procedura di attivazione potrebbe essere effettuata via internet dall'installer in maniera del tutto automatizzata: l'installer estrae i vari files da installare (tutti criptati), li installa, si connette ad un tuo server, permette di effettuare il pagamento, preleva una chiave, ed infine decripta i files installati. inoltre puoi anche avvisare l'utente che è illegale fare reverse engineering dell'installer al fine di scoprire la chiave, e che se tu scopri che la chiave che hai venduto a lui è stata volontariamente leakata (tipo se te la ritrovi su eMule ) allora è perseguibile penalmente.

per impedire che venga leakato tutto il programma in forma decriptata anziché la sola chiave potresti mantenere criptate delle parti vitali anche dopo l'installazione; la chiave di decifratura verrà mantenuta sul computer locale e verrà utilizzata ad ogni avvio per decifrare le informazioni ancora criptate. in tal modo se anche ti ritrovi il programma in chiaro su eMule ci saranno comunque delle parti criptate che sarà possibile decriptare solamente utilizzando la chiave venduta a quell'utente, il quale utente mettendola su eMule correrebbe il rischio di essere perseguito (a ciascun utente viene venduta una chiave diversa, perciò se su eMule trovi una certa chiave non è che ci sono tante possibilità sul colpevole ).

[W.S.]

x seven.7:
perfetto, ti basta usare un po di crittografia.

x 71104:
Per l'applicazione oggetto di questo thread (ora che ho capito cosa dovrebbe fare) non vedo neppure io ste grandi differenze tra C o VB visto che si tratta di prendere dei dati dal sistema, cifrarli e decifrare altri dati.
Per applicazioni sensibili intendo quelle applicazioni che non devono assolutamente fallire la loro esecuzione, quelle che non devono entrare in stati non previsti per intenderci. Più un linguaggio mi garantisce il controllo di quello che scrivo, più riesco a prevedere il comportamento del programma. Meno risorse esterne uso, minore è il rischio di includere porzioni di codice bacato che magari, normalmente, nemmeno vengono usate dal programma.
Ovviamente tutto va mediato con tempo/costo a disposizione, non pretendo certo di scrivere tutto da zero ogni volta. Purtroppo non sempre "ingegneria del software" e "sicurezza" vanno nella stessa direzione.

L'esempio dell'album fotografico: certo, se volessi custodirci delle immagini che non voglio condividere, allora vedrei di scriverlo in modo adeguato e PERSONALMENTE non userei VB.

Perchè? Perchè no

[71104]

Originariamente inviato da W.S.

Per applicazioni sensibili intendo quelle applicazioni che non devono assolutamente fallire la loro esecuzione, quelle che non devono entrare in stati non previsti per intenderci.

e tu dimostrami che le applicazioni scritte in C o in C++ sono bacate o crashano statisticamente molto meno rispetto a quelle scritte per piattaforme managed (ma ROTFL, si come no... esempi nell'altro thread, giustappunto )

Più un linguaggio mi garantisce il controllo di quello che scrivo, più riesco a prevedere il comportamento del programma.

si come no, fermo là tu questa va adeguatamente dimostrata. io per esempio la ritengo un falsissimo mito, qualcun altro nel leggerla potrebbe avere avversioni feroci di natura religiosa, a qualcun altro ancora potrebbe venire l'orticaria.

ora spiega al forum della Programmazione di HWU: come mai lavorare in un linguaggio dotato di aritmetica dei puntatori fa sbagliare di meno?

leggasi anche ultima riga della firma dell'utente PGI-Bis.

Meno risorse esterne uso, minore è il rischio di includere porzioni di codice bacato che magari, normalmente, nemmeno vengono usate dal programma.

benissimo, questa è un'argomentazione statistica validissima che accetto volentieri. e obietto: ma a te che ti frega dei bug del framework .NET, ammesso che ce ne siano? in caso il cliente si lamentasse tu digli che è colpa di Microsoft e che affinché tu effettui una segnalazione alla suddetta azienda ti sarà necessario un piccolo compenso extra.

cosa conviene di più a te, completare il lavoro per il cliente in un terzo del tempo buttando a qualcun altro (cioè a Microsoft) tutte le tue responsabilità di sicurezza, o perdere le ore sulle access violations? io dico pensa a fare bene ciò che devi fare tu, che al resto ci pensano gli altri.

L'esempio dell'album fotografico: certo, se volessi custodirci delle immagini che non voglio condividere, allora vedrei di scriverlo in modo adeguato e PERSONALMENTE non userei VB.

ci scommetto allora che io riuscirei a farlo prima di te

Perchè? Perchè no

siamo in un forum di nerd; "perché si" e "perché no" sono risposte vietate con rigore, pena il ban della persona.

[W.S.]

Originariamente inviato da 71104

ora spiega al forum della Programmazione di HWU: come mai lavorare in un linguaggio dotato di aritmetica dei puntatori fa sbagliare di meno?

Fermo pure tu , io non ho parlato di sbagli del programmatore. Io parlo della capacità del linguaggio, se lo si usa in modo non corretto è un altro discorso.

Originariamente inviato da 71104

in caso il cliente si lamentasse tu digli che è colpa di Microsoft e che affinché tu effettui una segnalazione alla suddetta azienda ti sarà necessario un piccolo compenso extra.

cosa conviene di più a te, completare il lavoro per il cliente in un terzo del tempo buttando a qualcun altro (cioè a Microsoft) tutte le tue responsabilità di sicurezza, o perdere le ore sulle access violations? io dico pensa a fare bene ciò che devi fare tu, che al resto ci pensano gli altri.

Certo, infatti per quelle applicazioni che ritengo "non critiche" non mi faccio problemi. Se voglio fare bene un sistema di sicurezza però DEVO prendere in considerazione i rischi e decidere sul da farsi.

Originariamente inviato da 71104

ci scommetto allora che io riuscirei a farlo prima di te

siamo in un forum di nerd; "perché si" e "perché no" sono risposte vietate con rigore, pena il ban della persona.

Sicuramente finisci prima tu, ma io (qualche mese dopo) avrò il mio programmino super-nerd in asm !

[71104]

Originariamente inviato da W.S.

Fermo pure tu , io non ho parlato di sbagli del programmatore.

tu hai parlato di riuscire a prevedere meglio il comportamento del programma. non vedo che influenza potrebbe avere la cosa sullo sviluppo dello stesso se non quella di riuscire ad inquadrare meglio il funzionamento di ogni singola parte commettendo così meno errori, cioè introducendo meno bugs. hai praticamente detto che se il linguaggio ti permette un migliore controllo del funzionamento di basso livello del programma allora riduci la possibilità di commettere errori. altrimenti ho capito male questa frase, rispiegamela:

Originariamente inviato da W.S.

Più un linguaggio mi garantisce il controllo di quello che scrivo, più riesco a prevedere il comportamento del programma.

Certo, infatti per quelle applicazioni che ritengo "non critiche" non mi faccio problemi. Se voglio fare bene un sistema di sicurezza però DEVO prendere in considerazione i rischi e decidere sul da farsi.

se veramente lo facessi opteresti comunque per una piattaforma managed nel 99% dei casi.

Sicuramente finisci prima tu, ma io (qualche mese dopo) avrò il mio programmino super-nerd in asm !

questa si che è fortuna...