Imerio Moretti ‐Matr. 738932Relatore: Prof. Paolo CeravoloCorrelatore: Prof. Stelvio CimatoCorso di laurea in Sicurezza Sistemi e Reti Informatiche – corso onlineA.A. 2010 – 2011
PROPOSTA #1 - WEB APPLICATION SERVER SIDE
1. Il “motore” dell’applicativo è tutto su server;2. i client vi accedono tramite browser e connessione internet.
PROPOSTA #2 - WEB APPLICATION CLIENT/SERVER SIDE
1. Il “motore” dell’applicativo si trova su client e su server ;2. ogni client è dotato di un proprio applicativo autonomo “motore client”. Può
salvare su una base dati esterna i propri dati “motore server”.
ARCHITETTURE
PROPOSTE
PROPOSTA #3 – MEDIAZIONE TRA LE DUE PRECEDENTI ARCHITETTURE
1. Della prima architettura si tiene la portabilità di un applicazione Web gestibile inambito server da qualsiasi host in grado di connettersi ad Internet ;
2. per venire incontro alla seconda architettura si decide di dare la possibilità discaricare in locale, in formato XML, i propri dati criptati salvati su server e tramitesemplici pagine HTML coadiuvate da funzioni JavaScript dar la possibilitàall'utente di avere sempre con sé in locale il suo archivio di password consultabileindipendentemente dalla connettività Internet.
ARCHITETTURE
PROPOSTE
VANTAGGI1. si ha un'applicazione indipendente dall’host. Basta un client dotato di browser e
connessione internet;2. i dati si trovano sul server quindi indipendentemente dall’host che potrebbe
rompersi, perdersi, essere rubato rimarrebbero sempre a nostra disposizione con un host sostitutivo anche se improvvisato;
3. una volta scaricati i dati in locale nessun client è costretto ad avere una connessione Internet per accedere ai propri dati.
SVANTAGGI1. i dati potrebbero trovarsi unicamente su server. In tal caso se non avessimo a
disposizione un accesso a internet, saremmo impossibilitati ad accedere ai nostri dati;
2. i nostri dati sensibili verrebbero archiviati su di un sistema indipendente dal nostro controllo. È necessario un rapporto di fiducia nei confronti dei gestori del servizio;
3. la sicurezza dei nostri dati dipende dalle vulnerabilità del server che li ospita .
ARCHITETTURE
PROPOSTE
XHTML CSS XML JAVASCRIPT DOM AJAX PHP WAMP
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
FUNZIONAMENTO
DEL
PROGRAMMA
L'utente a questo punto dovrà solamente cliccare sul file “cliccare_qui.html” in modo da permettere al proprio dispositivo di aprire una finestra del browser che richiede la password di decrittatura
Una volta inserita la corretta password di decrittatura e cliccato su “decritta pw”, l'utente dopo un messaggio di elaborazione in corso…
… potrà vedere su schermo la relativa decrittatura dei dati presenti nell’XML crittografato.
Verranno implementate ulteriori gradi di sicurezza per
esempio in fase di registrazione sarà
previsto un controllo a livello di immagini
CAPTCHA (Completely
Automated Public Turing test to tellComputers and HumansApart ).
Verrà previsto un servizio e‐mail che
permetterà all’utente di: 1) confermare la propria volontà di
registrarsi al servizio 2) modificare e gestire le proprie credenziali di login 3) rimanere
aggiornato tramite una reportistica di log sulle
modifiche/accessi effettuati con la sua credenziale alla base
dati.
Verrà previsto un sistema di
generazione di log atto a registrare i tentativi di login andati a buon fine
e non riusciti.
Migliorie a livello di interazione con
l’utente: 1) migliorie grafiche dell’applicativo 2) migliorie logiche (per esempio
evitando di salvare l’md5 nella base
dati).
Migliorie sull’aspetto della portabilità lato
client.