Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 17
  1. #1
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    86

    Crittografia submit di un form

    Buongiorno a tutti anche oggi ho bisogno di un vostro consiglio, spero che il testo non sia di troppa difficile comprensione e di esprimermi al meglio.

    Mi sto ponendo il quesito di rendere sicuro il passaggio di dati, generato da un submit, di un form che risiede in una pagina HTML, ho scartato l'idea di usare i certificati SSL perchè per me affittare un server con ip privato è una soluzione troppo costosa commisurata all'uso che andrei a farne.

    La mia idea è quella di utilizzare un algoritmo crittografico e delle chiavi che cambiano ad ogni accesso (pubbliche) quindi di crittografare i dati all'uscita dal form, facendoli passare attraverso una routine che utilizza l'algoritmo e che si occupa di inviare anche la chiave di decodifica insieme a i dati cifrati alla pagina destinataria, vado a rappresentare uno schema logico della mia idea.


    Form -- (submit) --> Routine crittografica -> Byte crittografati e chiavi --> Destinazione


    Secondo voi è sicuro questo tipo di trasmissione? Se si come si potrebbe realizzare concretamente? (Ho già un oggetto ASP.NET che crittografa i dati e genera le chiavi).

  2. #2
    a parte qualche discussione che potremmo aprire sulla sicurezza della tua soluzione...
    (simmetrica, asimmetrica.... bla bla bla)

    sei sicuro che il tempo che impieghi per tirare su una soluzione (consiglio asimmetrica) ti costi meno di aqcuistare un certificato ssl?

  3. #3
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    86
    si perchè dovrei anche acquistare per un anno un server fisico o virtuale con indirizzo privato, quindi si senza dubbio. Puoi darmi qualche linea guida? Tengo anche presente che ho già l'oggetto in ASP.NET per crittogradare i dati. Dovrei solo gestire il flusso dei dati e il tipo di chiavi.

  4. #4

  5. #5
    Moderatore di Windows e software L'avatar di URANIO
    Registrato dal
    Dec 1999
    residenza
    Casalpusterlengo (LO)
    Messaggi
    1,290
    Non ho capito, vuoi creare un canale sicuro tra client(pagina) e server oppure devi far comunicare il server con altri server?

    Nel primo caso la routine per crittografare in ASP.net ti serve a poco, i dati vanno criptati lato client, ed essendo pagine web via javascript o applet o altro(con tutti i problemi di compatibilità).

  6. #6
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    86
    Uranio si tratta semplicemente di rendere sicura la trasmissione dei dati fra due pagine, una di form che opera il submit e l'altra che legge questi dati. Può anche avvenire tutto client sicuramente. Perchè hai qualche idea?

  7. #7
    Utente di HTML.it L'avatar di GabbOne
    Registrato dal
    Mar 2006
    Messaggi
    577
    apparte che dare in mano ad un client la crittografia e come dare le chiavi di casa al primo che passa ....

    detto questo , voglio dire (RE: ) che la soluzione di avere un canale sicuro a pagamento è sicuramente la scelta migliore


  8. #8
    Utente di HTML.it L'avatar di U235
    Registrato dal
    Mar 2006
    Messaggi
    1,539
    ciao, per rendere sicuro un canale, devi rendere sicure le chiavi.
    il punto è che per fare ciò ci deve essere un informazione condivisa (chiave simmetrica), ora, siccome la chiave simmetrica non può essere pubblica (se no perderebbe l'utilità ) deve esserci a priori uno scambio di informazioni sicuro tra il client e il server, se tu ad esempio dessi una chiave ad ogni client che si connette, accadrebbe che un ipotetico sniffer in ascolto la intercetterebbe (perchè dovresti mandarla in chiaro sulla rete se no il client non potrebbe conoscerla) invalidando la sua utilità, perchè un hacker riuscirebbe a decrittare il flusso dati esattamente come il client. Per ovviare a questo problema, si usa la crittografia asimmetrica, ovvero algoritmi particolari (non sto qui a spiegare io perchè in rete trovi di meglio....) che permettono, data una chiave pubblica di entrambi, di creare un algoritmo sicuro per lo scambio (in genere) di una chiave simmetrica con cui poi iniziare la comunicazione sicura.
    quindi, per una crittografia asimmetrica, è sempre necessario una terza parte di fiducia che certifichi e comunichi le chiavi pubbliche dei server. da qui la necessità di certificato...

    il client contatta la terza parte di fiducia, questa le restituisce la chiave pubblica del server da contattare (quindi certificherà che stai andando proprio nel server giusto e non su quello di un hacker che ti fa credere di essere il server giusto), con questa chiave, il client, codifica la sua chiave pubblica con la chiave pubblica del server, il server, ricevuto tale flusso, lo decodifica con la sua chiave privata (per comprendere meglio come guarda il funzionameno della crittografia asimmetrica) e a sua volta invia una chiave per lo scambio, codificata con la chiave pubblica del client, a questo punto solo il client può decriptare tale chiave con la sua relativa chiave privata.

    per semplificare :

    il client può decrittare ciò che è stato scritto usando la sua chiave pubblica SOLO con la sua chiave privata (e NON con la sua chiave pubblica stesso) idem per il server. quindi chiunque intercetti dati criptati con una chiave pubblica (anche se fosse in possesso di tale chiave) non potrebbe decriptare nulla!

    se elimini chi certifica che la comunicazione è con il server che il client cercava, elimini anche la sicurezza... a meno chè non trovi un modo per certificare al client che chi stia contattando sia essattamente chi deve contattare (ovvero il tuo server).

    per capire meglio cosa si intende per "fiducia" :
    ad esempio un modo potrebbe essere quello di "telefonare" l'utente informandolo della chiave pubblica da utilizzare (ma il client deve essere sicuro che sia il numero giusto e non quello dell'hacker!) quindi il client "si fida" perchè conosce il numero (o ancora meglio la voce) di chi li comunica la chiave da utilizzare...

    come vedi,una terza parte di fiducia deve esistere sempre, e non può essere svolta da te stesso perchè se un hacker finge di essere te, fingerà anche sempre e comunque di essere quello giusto!

  9. #9
    Moderatore di Windows e software L'avatar di URANIO
    Registrato dal
    Dec 1999
    residenza
    Casalpusterlengo (LO)
    Messaggi
    1,290
    Originariamente inviato da m4rc087
    Uranio si tratta semplicemente di rendere sicura la trasmissione dei dati fra due pagine, una di form che opera il submit e l'altra che legge questi dati. Può anche avvenire tutto client sicuramente. Perchè hai qualche idea?
    Se vuoi rendere sicuro il canale, i dati vanno cifrati PRIMA del submit della form.
    Questo porta a molti problemi, il cient potrebbe non essere compatibile, protocollo di comunicazione etc...

    Quello che vuoi fare è fattibile, ma lunga difficile e probabilmente inutile.

  10. #10
    Utente di HTML.it L'avatar di U235
    Registrato dal
    Mar 2006
    Messaggi
    1,539
    Originariamente inviato da URANIO
    Se vuoi rendere sicuro il canale, i dati vanno cifrati PRIMA del submit della form.
    Questo porta a molti problemi, il cient potrebbe non essere compatibile, protocollo di comunicazione etc...

    Quello che vuoi fare è fattibile, ma lunga difficile e probabilmente inutile.
    Ciao URANIO,
    direi più che altro inutile, tutto sommato non sarebbe un grosso problema usando il DOM con Silverlight, avresti la compatibilità e le classi di System.Security.Cryptography lato client.

    il vero problema è sempre come rendere sicura la comunicazione della chiave di codifica.

    ovviamente, in questo caso, la chiave, andrebbe inviata IN CHIARO insieme alla pagina, per poi essere usata dal client per criptare i dati e fare il submit, ma a quel punto la sicurezza sarebbe già compromessa, perchè un ipotetico sniffer avrebbe già sniffato l'invio della pagina dal server, quindi sarebbe già in possesso della chiave di codifica che utilizza il client al submit.

    @m4rc087
    come già detto, l'unica strada (quasi) sicura è la crittografia asimmetrica, a patto che la comunicazione sia certificata tra i giusti interlocutori.
    Teniamo sempre presente che ci sono fior di matematici che studiano il problema dai tempi di Cesare, ed una soluzione MATEMATICAMENTE sicura ancora non esiste! ( e si! nemmeno ssl lo è matematicamente anche se molto improbabile romperla)

    ovviamente, se trovi il modo di comunicare la chiave di codifica (simmetrica) al client attraverso un canale sicuro si può fare (vedi altri metodi che prevedono l'uso combinato di internet e sms o chiavi hardware, ma anche qui non è sicuro al 100%) oppure, potresti provare a far fungere un secondo server da server di trust utilizzando chiavi asimmetriche, però ricorda che diventa fondamentale che il secondo server sia super sicuro... (in poche parole dovresti far diventare il secondo server come VeriSign , ma a quel punto meglio comprare un certificato e affittare il server dedicato)

    credimi, i sistemi crittografati sono sicuri in proporzione a quanto lo sono lo scambio e la memorizzazione delle chiavi... tutto il resto e fuffa!

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.