Pagina 2 di 2 primaprima 1 2
Visualizzazione dei risultati da 11 a 18 su 18
  1. #11
    Io, non mi fido di nessuno, generalmente neanche di me stesso, inoltre, si, ho ben chiaro cos'è un exploit, ma proprio per questo motivo non faccio affidamento al codice se ho bisogno di una concreta e reale sicurezza

    Fatto quest'appunto, ti pregherei di rileggere quello che ho scritto prima, nello specifico la frase:

    ...se al database ci accedono per una falla delle pagine php possono accede anche al file...
    Se riescono ad accedere al database, tramite un exploit del codice php, possono, teoricamente, accedere anche ai file presenti sul disco (se non direttamente da codice php con una query di tipo load file, se non è disabilitato). Proprio perché è facile scrivere cattivo codice (per fare un banale esempio ... spesso viene effettuata l'inclusione di file il cui nome dipende direttamente da una variabile che invia il browser senza però controllare nulla o quasi nulla) il sistema che hai proposto è solo un "workaround" al problema reale, ma, attenzione, non perché l'idea sia cattiva, ma perché, parlando di sicurezza, non si possono mettere punti fermi, ovvero non si ci può fidare dell'hoster, che potrebbe avere falle o fare raccolta di questi dati, cosi come non si ci può fidare del programmatore, che potrebbe aver scritto del cattivo codice, e via dicendo.

    La soluzione che ho proposto era proprio per evitare questi problemi, ovvero utilizzare un algoritmo di crittografia con chiave pubblica/privata cosi da tenere la chiave pubblica sul server stesso e la chiave privata su una smartcard: una volta che la chiave privata sta sulla smartcard e questa è collegata al computer del responsabile la perdita dei dati può essere causata solo un errore suo (ma a quello si può fare veramente poco)! Anche se ci fossero tutti i bug di questo mondo, dato che è sufficentemente provato che RSA è affidabile e la complessità aumenta con l'aumentare della dimensione della chiave, i dati personali e delle carte di credito sono crittografati e tranne che l'attaccante ha a disposizione un considerevole capitale per acquistare un grosso parco macchine per craccare i dati si può stare tranquilli (ma si può intervenire anche su questo in certe misure)
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  2. #12
    Utente di HTML.it
    Registrato dal
    Apr 2004
    Messaggi
    3,709
    Dunque... intanto secondo me puoi comunque usare una tecnica hash (che NON è la funzione hash e basta, che nell'uso comune non effettua una vera e propria crittografia com'è stato giustamente annotato... ecco perchè ho parlato di VARIANTE... c'era un motivo) ed eventualmente anche solo una semplice funzione hash se il controllo di corrispondenza della carta può essere effettuato al momento del pagamento (di persona dicevi): in questo caso l'albergatore reinserirà la carta di credito e potrà verificarne la corrispondenza con quanto memorizzato nel db.

    Se invece è assolutamente necessario risalire al numero della carta (ma perchè? Eventualmente spiega bene questa motivazione) allora - come già ti hanno suggerito - devi usare un algoritmo che consenta la decrittazione delle informazioni... il "classico" sistema con chiavi asimmetriche si presta bene... potresti anche criptare il codice usando Mcrypt (v. http://www.php.net/manual/en/functio...odule-open.php)

  3. #13
    All'albergatore serve il numero della carta di credito per richiedere il prelievo in caso, ad esempio, di prenotazione annullata o per la caparra ... insomma, serve il numero della carta di credito, il codice di sicurezza, il proprietario ed infine la scadenza

    l'utilizzo della crittografia con chiavi asimmetriche lo consiglio anch'io, però ripeto: affinche sia utile la chiave che usi per la lettura non deve risiedere sul server altrimenti non serve a nulla e puoi usare una crittografia a chiave simmetrica (come blowfish, serpent, aes e via dicendo)
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  4. #14
    Utente di HTML.it L'avatar di henry78
    Registrato dal
    May 2001
    Messaggi
    1,264
    nel mio caso il codice è scritto bene (SPERO!!!)...

    mi guardo un pò delle funzioni che suggerite per criptare in modo reversibile i numeri della carte; comunque non mi pare una brutta idea dividere i 16 numeri in altrettanti campi magari giocando con la data di inserimento - il problema rimane la chiave di decriptazione... se violano il server e arrivano ai files, difficile riuscire a difendere i dati.

    Tra l'altro, se cancello dei record da un db mysql, le informazioni sono cancellate in modo irreversibile? Oppure, come accade per i file, si riesce con specifici software a risalire ai dati?

  5. #15
    l'utilizzo della crittografia con chiavi asimmetriche lo consiglio anch'io, però ripeto: affinche sia utile la chiave che usi per la lettura non deve risiedere sul server altrimenti non serve a nulla e puoi usare una crittografia a chiave simmetrica (come blowfish, serpent, aes e via dicendo)
    io non posso far altro che auto-quotarmi la chiave privata sulla smartcard e si ci accede tramite browser, tramite software ... insomma ... vedi tu ^^

    puoi fare poi tutti gli altri giochi che vuoi, ma la realtà è che l'unico modo sicuro a prova della stragrande maggioranza di bug del codice (se il bug riguarda specificatamente l'operazione di codifica ... che so ... non fa la codifica ... ecco li siamo punto e accapo) è la crittografia con chiavi assimmetriche

    a parte questo, qui puoi trovare informazioni specifiche riguardo l'eliminazione
    http://dev.mysql.com/doc/refman/5.1/en/delete.html

    nello specifico
    In MyISAM tables, deleted rows are maintained in a linked list and subsequent INSERT operations reuse old row positions. To reclaim unused space and reduce file sizes, use the OPTIMIZE TABLE statement or the myisamchk utility to reorganize tables. OPTIMIZE TABLE is easier to use, but myisamchk is faster. See Section 12.5.2.5, “OPTIMIZE TABLE Syntax”, and Section 4.6.3, “myisamchk — MyISAM Table-Maintenance Utility”.
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  6. #16
    Utente di HTML.it L'avatar di henry78
    Registrato dal
    May 2001
    Messaggi
    1,264
    a parte questo, qui puoi trovare informazioni specifiche riguardo l'eliminazione
    http://dev.mysql.com/doc/refman/5.1/en/delete.html

    nello specifico

    ho letto ma non riesco a capire.. (forse a causa del mio non perfetto inglese)

    in pratica, se faccio un semplice delete di un record, le informazioni sono recuperabili? Oppure posso considerarlo cancellato per sempre?

  7. #17
    il delete non implica, automaticamente, la cancellazione fisica dei dati ma gli dice a mysql che può riutilizzare quello spazio se può

    usando però una query di OPTIMIZE TABLE, dopo il delete, tecnicamente le tabelle vengono ricostruite e risistemate eliminando lo spazio inutilizzato ma comunque occupato
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  8. #18
    Utente di HTML.it L'avatar di henry78
    Registrato dal
    May 2001
    Messaggi
    1,264
    Originariamente inviato da daniele_dll
    il delete non implica, automaticamente, la cancellazione fisica dei dati ma gli dice a mysql che può riutilizzare quello spazio se può

    usando però una query di OPTIMIZE TABLE, dopo il delete, tecnicamente le tabelle vengono ricostruite e risistemate eliminando lo spazio inutilizzato ma comunque occupato

    Grazie! Veramente gentilissimo

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.