Newsgroup: it.comp.appl.access
Titolo: A proposito di cifratura

 
Apro un nuovo post sull'argomento "Criptare decriptare dati sensibili" per 
proporre un esempio concreto.
Il file è in formato Access 97 e può essere facilmente convertito in altre 
versioni ricordandosi di usare DAO e non ADO.
All'apertura rispondere Sì alla domanda di criptare i dati e poi usare 
l'applicativo.
L'esempio consta di due maschere più quella di apertura. I dati sono sempre 
criptati in entrambe le maschere ma con la differenza di una diversa 
modalità di visualizzazione. Per rendersi conto di ciò basta aprire la 
struttura delle due maschere e dare un'occhiata sia all'origine dati di 
"DESCRI", sia della casella combinata che gli stà accanto.
Mi sembra funzioni molto bene lasciando sempre i dati criptati e senza MAI 
toccare la tabella con i dati criptati. Con lo stesso sistema si possono 
creare report, query e quant'altro.
Attendo un vostro commento.
Ciao, Carlo
http://www.frantoiogestione.com/Cripto.zip

 
Un'aggiunta:
se il sitocomune ritiene l'esempio di una qualche utilità puo' 
tranquillamente pubblicarlo.
Ciao, Carlo

 Ciao, Carlo
-- 
Roberto
-----------------------------------------------------
il Sito Comune di it.comp.appl.access
http://www.sitocomune.com
----------------------------------------------------

 Attendo un vostro commento.
Davvero una soluzione pregevole!
E anche concettualmente "banale": ho sputato davvero troppo in fretta la
sentenza  "in realtà con Access è proprio impossibile trovare una soluzione
al problema affidabile"   :-)
Resterebbe da valutare l'impatto prestazionale qualora i campi da decrittare
siano tanti e con un Server SQL collegato via ODBC.
Comunque in monoutenza, sul catorcio che sto usando per spedire questo post,
le prestazioni sono ottime anche su maschera continua (e i records nella
tabella sono un discreto numero).
:-)
Ciao, Simone


Aspettavo proprio una tua risposta...sono contento ti sia piaciuta la 
soluzione.
Qualora fosse necesario riportare i dati in chiaro, nell'unico modulo 
allegato, trovi una sub apposita.
Per le prestazioni ritengo siano più che accettabili fino a 100.000 record. 
Per incrementare ulteriormente la velocità dovrebbe bastare ridurre la 
stringa Password_Key a non più di 10 caratteri.
Non finirò mai di raccomandare una copia di riserva del db che si intende 
criptare.
Ora non mi venissero a dire che le tabelle Access sono aperte a tutti!
Ciao, Carlo 

 ----------------------------------------------------
Ciao Roberto
per la pubblicazione usa il link che ho postato in quanto contiene la 
tabella non criptata.
Ciao, Carlo 

 ha scritto nel messaggio 
news:IYICe.80070$h5.33...@news3.tin.it...

Soluzione molto interessante. Complimenti per la cifratura. ;-) 

 Attendo un vostro commento.
Non è una brutta idea, ma risolve solo parzialmente il problema: i campi
decrittati a Runtime a livello di query sono a sola lettura...
Tirando le somme il metodo che proponeva Simone, basato su temporanei
locali, mi pare l'unico praticabile in lettura/scrittura lasciando sempre
crittato il DB sul Server.
A onor del vero si tratta di una metodologia di lavoro (disconnessa) che
qualcuno ha sempre adottato, indipendentemente dal problema della
crittazione, per quanto oneroso a livello di programmazione.
Cristiano

 tabella non criptata.
Ho scaricato quel database e lo userò come allegato della FAQ.
A proposito, sai per caso a che data è aggiornato l'archivio dei comuni
contenuto nella tabella della tua demo?



Mi sembra 2003.
Ciao, Carlo 


Oramai diventa una questione di principio.
Ho messo in linea un aggiornamento del file di esempio che permette anche la 
modifica dei dati criptati senza l'uso di tabelle temporanee. Questo č solo 
un esempio ma sono sicuro che altri potranno trovare metodi piů "migliori" 
per fare la stessa cosa.
Il link č sempre lo stesso.
Ciao, Carlo
http://www.frantoiogestione.com/Cripto.zip

 per fare la stessa cosa.
Pare quasi che io voglia fare il bastian contrario  :-)
Naturalmente non è così: la soluzione che hai pensato è accettabile se i
campi "crittati" sono pochi.
Ma nel contesto di applicazioni in cui buona parte del tracciato record
dev'essere cifrato, non è utilizzabile: sarebbe un grosso passo indietro a
livello d'usabilità che gli utenti non accetterebbero (soprattutto in
modalità tabellare).
Tutto ok invece per la reportistica.
Ciao, Cristiano

"Cristiano" <cristia...@XXXX.it> ha scritto nel messaggio 
news:Tk7De.7052$a5.9...@twister2.libero.it...

Ciao Cristiano
quella del bastian contrario è una tua caratteristica (vedi altre tue 
risposte...) e a me va benissimo...ce ne fossero come te. Solo così si 
cresce e ci si migliora.
Le tue osservazioni sono condivisibili solo in teoria  ma, in pratica, sono 
prive...di fondamento.
Quanti campi intendi criptare? La mia risposta è il minimo per non 
permettere l'identificazione della persona e proteggere i suoi dati 
sensibili...ricordi l'origine di questo post? In un ipotetico database 
ospedaliero (è solo un esempio) basterebbe criptare il solo cognome! Il 
resto dei dati diventa inutilizzabile!
Chissà cosa ne pensa il resto del NG.
Ciao, Carlo

 ha scritto nel messaggio
news:%haDe.181094$75.78...@news4.tin.it...

Io penso che la tua teoria è valida, anche se sarebbe il caso di cifrere
anche il codice fiscale se presente nella tabella; comunque sarebbe il caso
di sapere cosa dicono le norme di legge.



Devo chiedere. Comunque dal CF non è possibile risalire alla persona.
Ciao, Carlo 

 resto dei dati diventa inutilizzabile!
Se ti riferisci all'ambito sanitario (che non conosco) può darsi che basti
proteggere da sguardi indiscreti solo tali campi.
Ma è solo uno dei tanti settori in cui la cifratura dei dati può essere
richiesta.
In tutte le casistiche aziendali (e naturalmente non si parla di PMI), mi
spiace, sei fuori strada
Quindi tu consentiresti a un'estraneo la copiatura di un DB in cui solo le
ragioni sociali dei Clienti/Fornitori fossero criptate?
All'atto pratico qualunque pinco pallino potrebbe eseguire queries sui dati
aziendali per valutare il fatturato della tua azienda, il venduto
raggruppato per Codice Articolo o Gruppo merceologico, leggere le tue banche
d'appoggio, le esposizioni e i castelletti etc. etc. etc.
Quindi, ribadisco la conclusione del post precedente:
"nel contesto di applicazioni in cui buona parte del tracciato record
dev'essere cifrato, non è utilizzabile: sarebbe un grosso passo indietro a
livello d'usabilità che gli utenti non accetterebbero (soprattutto in
modalità tabellare)."
Ciao, Cristiano

 Ciao, Cristiano
Tu quale database proponi? O meglio quale soluzione intravedi per ottenere 
quello che dici?
Ti ricordo che quì sei su un NG per Access e ognuno di noi (quasi tutti), di 
Access, conosce benissimo limiti e difficoltà.
Torno a dirti di restare con i piedi per terra e badare alla sostanza delle 
cose.
Gli applicativi mission critical sono un'altra cosa...qui si parla di come 
proteggere i dati sensibili secondo l'ultima normativa sulla privacy.
Quanto ai post da ...bastian contrario e qualche volta anche polemico ne 
cito solo alcuni per non parlare dell'attuale:
(ribadisco che a me piace...e non intendo minimamente polemizzare)
in un file mde il codice vba di un modulo è recuperabile?
creare pacchetti di setup scaricabili da internet
software access distribuibile
Run Time (Dubbio prima di acquisto)
[A03] Pagina accesso ai Dati: Provider corretto...
CISA1: Documentazioni.
valori univoci: contatore o chiave personalizzata?
Ciao, Carlo.

 modalità tabellare)."
Mi spiace che il Th rischi di finire a pugni ... la questione è interessante
e piuttosto articolata.
Purtroppo l'essenza del discorso che hai fatto è valida, personalmente ti
correggerei solo su un aspetto: anche parecchie PMI (gruppo di aziende che
non comprende solo gli idraulici!)  hanno esigenze di crittaggio dei dati, o
comunque lo vedrebbero di buon occhio...
Tuttavia il metodo di Carlo mi piace molto, anche se è vero che non sarebbe
accettato dall'utenza in fase di scrittura.
D'altra parte la metodologia che utilizza temporanei locali (la cosiddetta
modalità disconnessa) comporta un lavoro di sviluppo notevole, quindi non è
facile consigliarla così ... come se nulla fosse :-)
Probabilmente sul sito comune si dovrebbe accompagnare l'esempio di Carlo
con un documento che svisceri la faccenda in tutte le sfaccettature.
Faccenda purtroppo delicata.
Saluti

 valori univoci: contatore o chiave personalizzata?
Prendo atto della tua definizione di bastian contrario e polemico, ma ti sei
decisamente allargato.
Solo in un paio di quei Thread ci sono virature polemiche e mai gratuite.
Nel Th attuale stiamo bisticciando per un motivo semplice: vuoi a tutti
i costi aver *ragione* su una faccenda più complessa di quanto tu avessi
inizialmente ipotizzato.
Dovresti prenderne atto e meditare un pò di più prima di premere "invia".
La tua affermazione  "Gli applicativi mission critical sono un'altra
cosa..." o
"cerca di stare coi piedi per terra"  mi ha davvero colpito, molto colpito.
Due ipotesi alla luce di tali sparate:
1)  Sei un neodiplomato con tanta voglia di cazzeggio.
2)  Sei un esperto conoscitore di Access, annessi e connessi, e hai
un'esperienza sul campo.
Dato che delle due ipotesi è la seconda quella valida, la conclusione è una
sola: "ti sei solo lasciato prendere la mano, scambiando osservazioni
realistiche per altro".
Per me la cosa è comunque finita qui.
Cristiano

 comunque lo vedrebbero di buon occhio...
In effetti per PMI io tendo a considerare ditte che vanno dall'imbianchino
all'idraulico  :-)
Ciao, Cristiano


Ciao Simone
credo che dovrň dotare l'esempio (a proposito hai scaricato l'ultimo?) di 
una ricca premessa.
Prima fra tutte il suo uso. Se ne consiglia l'uso con db che non superino i 
100.000 record e dove i campi da criptare siano al massimo due o tre. Se 
proprio č indispensabile criptare piů campi, si possono ridurre i caratteri 
della Password_Key (che deve essere cambiata ad ogni applicativo). Fare 
sempre una copia dei dati originali e organizzarsi per copie giornaliere 
(peraltro previste dalla normativa vigente).
Ovviamente tutto č valido se si deve utilizzare Access...
Ciao, Carlo 


In ultimo una personalissima considerazione. I NG sono fantastici non solo 
per la ricchezza degli argomenti trattati e per l'enorme aiuto che se ne può 
ricavare ma anche perchè, nella lettura di un post, ognuno legge se stesso, 
il proprio stato d'animo, legge la propria interpretazione dell'altro. A 
volte si prendono lucciole per lanterne solo perchè è il proprio essere a 
condizionare la chiave di lettura...l'intonazione...è molto facile 
sbagliarsi nel giudicare: spesso è un giudizio di se stessi.
Ma proprio per questo lo scrivere e il leggere è istruttivo.
Quando leggo lo faccio con la mia voce...(interiore). (caspita che pensiero 
filosofico! Ma da dove mi escono!)
Forse quando si scrive si dovrebbe adottare il linguaggio HTML che specifica 
bene tutte i parametri e la giusta formattazione del testo, onde evitare 
fraintendimenti.
Se la cosa può servire voglio "specificare" che il mio è solo spirito di 
collaborazione...un aiuto reciproco alla causa della programmazione in 
Access (dalla versione 1 e 1.1 la mitica), senza null'altro.
Ciao, Carlo 

 Ciao, Carlo
Come mai non deve superare i 100.000 record?
Ciao, Napoleone 

 (peraltro previste dalla normativa vigente).
Già: purtroppo la faccenda è variegata e non esiste una soluzione semplice
ed esaustiva per ogni esigenza.
Comunque, indipendentemente dalle visioni su come gestire con Access
databases crittati, gli algoritmi di crittazione- decrittazione sono ottimi
e potranno tornar comodi anche in scenari diversi.
Purtroppo la compilazione P-Code di Access incide negativamente sulle
prestazioni di crittazione a Runtime molto più di quanto non accadrebbe in
Delphi (o in VB6 in compilazione nativa).
Ciao: Simone


Il limite è solo per opportunità nel senso che, a runtime, la decifratura in 
una combo come nell'esempio allegato, impiega circa 1 secondo per 50.000 
record e circa 3 secondi per 100.000. Si ipotizza che il limite di tre 
secondi sia l'attesa massima che un utilizzatore è disposto ad accettare 
senza lamentarsi troppo. Riducendo i caratteri della Key questo tempo si 
riduce.
Una strada per velocizzare di moltissimo la decrittazione è quella di creare 
query temporanee e salvate dei dati decrittati e usarle per alimentare le 
combo di ricerca. Le query andranno poi eliminate alla chiusura del db. 
Questa strada potrebbe esporre comunque i dati sensibili a lettura qualora 
per un qualsiasi motivo non si riesca ad eliminare le query temporanee.
Ciao, Carlo 

 sarebbe accettato dall'utenza in fase di scrittura.
Non ho capito a cosa ti riferisci qui.
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 ha scritto nel messaggio 
news:r8nDe.27073$TR5....@news.edisontel.com...

Ciao Massimaliano
se hai scaricato l'ultima versione di Cripto.mdb, ti sarai accorto che è 
stata aggiunta una maschera per le modifiche.
Forse Simone si riferiva a questa nel senso che per modificare un valore 
criptato si è reso necessario aprire una nuova maschera di modifica...
Ciao, Carlo
http://www.frantoiogestione.com/Cripto.zip

 
http://www.frantoiogestione.com/Cripto.zip


 MAssimiliano Amendola            
www.accessgroup.it
E' necessario evitare di decriptare e criptare i dati ogni volta che si 
fanno modifiche perchè potrebbe esporre il db ad occhi indiscreti. In questo 
modo i dati restano sempre criptati. Forse non è l'unico sistema ma è stato 
il primo che mi è venuto in mente. Si potrebbe anche usare una inputbox.
Ciao, Carlo 


e se grazie ad access qualcuno in Italia fa l'Olio buono ci guadagnamo tutti 
...!
E' scontato che alla prossima CISA tutti i condimenti saranno forniti da 
Carlo.


Ci puoi contare!
Ciao, Carlo 

 Ciao, Carlo


 Saluti


 Ciao: Simone


 Ciao, Carlo
Ciao
Roberto

 Roberto



Sì sono d'accordo, bisogna rispettare le normative vigenti.
Tanto per divertimento ho provato a vedere quanti cognomi riuscivo a tirare 
fuori avendo un CF che inizia per MMS.
MASSONI; MASSA; MASSAUA; MISSONI; MASSETE; MOSSAD; MOSS; MISSURI; MASSONE; 
MISSO; MESSORI.
Effettivamente in una piccola comunità, avendo il sesso e la data di 
nascita, non dovrebbe essere difficile risalire alla persona...anzi con la 
sola data di nascita in una piccola comunità di 5, 6 mila persone sarebbe 
semplicissimo: quante persone saranno nate il 25/12/1970? Una, due? Molto, 
troppo facile. Forse conviene criptare anche il CF.
Ciao, Carlo 


--
Ciao
Galliano.

 ha scritto nel messaggio
news:qJsDe.8851$a5.1...@twister2.libero.it...

OK, grazie!
Pubblicherò anche questo URL sul Sito Comune.


 ha scritto nel messaggio 
news:0XlDe.86875$h5.36...@news3.tin.it...

Grazie.
Napoleone 

 statistico.
Statistiche tue comunque ... immagino affidabili quanto la tua visione di
"dati sensibili".
Ciao, Cristiano