Login sicuro

Pagine → 1 2

gemini

09/03/2009 08:18:06

Sembra intreressante :-)
Magari ricrittando il risultato poi in md5, in modo da ridurre il numero di caratteri...
Ciò mi fa ricordare che devo mandarti un MP. :-)

"Ciò che accomuna le community dei giochi di ruolo online e le cittadine del primo medioevo è la cultura media delle loro popolazioni"

Storie di Agarthi ↗
Un Varco si apre davanti a te, un mondo tra i mondi è a portata di mano. Lasciati alle spalle le certezze, inizia l'avventura!

09/03/2009 12:08:05 e modificato da darkside of breakfast il 09/03/2009 12:09:11

Partendo dal presupposto che sto sviluppando un'applicazione che poi sarà distribuita come os - e quindi ultraleggibile da tutti - il fatto che mi interessa non è tanto che sarà comprensibile il meccanismo, perchè quello è scontato e lo esplicherò io stesso, ma più che altro volevo sapere quanto rischio e quali sono le migliori preucazioni da prendere.
Allora..
Ecco così come è XD
abbiamo un ip criptato in sha512.
Una password che viene scritta nell'input. (in chiaro e non codificata)
Poi, al momento del submit del form:
Passo in sha1 la password (perchè sul db è criptata così), poi la passo in sha512, poi la aggiungo all'ip criptato (da php, quindi non è in chiaro), e ottengo l'hash in sha512 di questa concatenazione.
Sostituisco questo cosone alla stringa di input, faccio partire il form, dall'altra parte eseguo la soluzione uguale ripescando la pass (già criptata in sha1).

Dite che potrebbe andare? XD

ps: grazie per il file js raz, utilissimo :*

World of Warship ↗
MMO gratuito con frenetiche battaglie navali ambientate nel ventesimo secolo. Salpa con la tua nave ed affronta i nemici!

09/03/2009 13:16:15

xenoriss ha scritto: Dark secondo me per un login sicuro Javascript deve essere messo da parte !!!

è impossibile mettere da parte javascript...
Solo con PhP, o qualsiasi altro linguaggio lato-server, la password verrebbe comunque inviata in chiaro (tramite un pacchetto di tipo post).
Bisogna agire sul pre-submit, e, fin dove arrivano le mie conoscenze, so che solo javascript può agire in tempo reale senza la necessità di rinviare la stringa.
Al massimo potrei fare un'applicazione in ajax, ma, per quanto mi riguarda, almeno al login volevo evitare il suo uso.

AlterEgo ↗
Scopri AlterEgo GdR: un incredibile universo narrativo in stile medievale fantasy che cresce, muta e vive giorno dopo giorno grazie ai suoi giocatori!

09/03/2009 13:49:20

xenoriss ha scritto: Hmmm con javascript più sicurezza? Hmmm va boh non insisto...

se hai altre idee puoi pure dirle eh XD
mica parlo ex cathedra :P

New World Order ↗
Diventa un agente del Nuovo Ordine Mondiale e affronta le forze occulte che minacciano il pianeta Terra in questo GDR Urban Fantasy per Mobile!

09/03/2009 18:29:22

Server per far girare java? °---°"

Ad ogni modo no, scomodare java per un login di un progetto open source mi appare eccessivo.
Comunque ho risolto, se a qualcuno interessasse potete contattarmi privatamente :)

Crossout ↗
Tuffati nel mondo di Crossout, il gioco MMO d'azione post apocalittico! Costruisci le tue speciali macchine da combattimento!

09/03/2009 19:24:05

Scusatemi se posto ancora, ma visto l'interesse che ha riscosso questo topic creerò una patch a se' stante con tanto di download e demo :)

mitsunari

09/03/2009 21:18:58 e modificato da mitsunari il 09/03/2009 21:37:52

xenoriss ha scritto: Vedi io per un login sicuro userei JAVA, ma i server per far girare questo linguaggio sono molto costosi, di conseguenza non saprei proprio darti un consiglio...

Prego? O.O
Per far girare un'applet java (jsp) su un server è sufficiente che il tuo provider ti fornisca un'applicazione come (ad esempio) TomCat che, essendo open-source, non vedo come possa far lievitare i costi.
http://tomcat.apache.org/ ↗
Per del puro java, inserito in una pagina html tramite il tag <object>, è sufficiente avere una JVM installata (e, anche qui, la gratuità del progetto è palese).

" Secondo gli antichi, una decisione andrebbe presa nello spazio di sette respiri. "

War Thunder ↗
Aviazione, veicoli corazzati e flotte militari della seconda guerra mondiale. Parteciperai a tutte le principali battaglie!

09/03/2009 21:44:08 e modificato da darkside of breakfast il 09/03/2009 21:51:27

Ci ho ripensato :P
Scriverò qui una sorta di tutorial.
Ecco il procedimento:

file: accesso.php
PhP

<?php
session_start();
include("../inc/db.php");
function make_seed() {
return (double)microtime()*100000;
} //funzione per genererare il randomize
mt_srand(make_seed());
$num = mt_rand(1, 1500); //primo fattore casuale
$num2 = mt_rand(1, 25); //secondo fattore casuale
$num3 = $num/$num2; //divido il primo per il secondo
$CasualString = sha1($num3); //ne ottengo una stringa alfanumerica indecifrabile
$CasualSubstrString = substr($CasualString, 0, $num2); //della stringa alfanumerica prendo solo quei caratteri compresi tra zero ed il secondo fattore casuale
$_SESSION['SN'] = $CasualSubstrString; //la imposto come variabile di sessione per recuperare la stringa nella prossima pagina
$IpCriptatoEVarCasuale = hash(sha256, $_SERVER['REMOTE_ADDR'].$CasualSubstrString); //ottengo l'hash in sha256 dell'ip concatenato alla stringa casuale alfanumerica
?>

(X)HTML

<form method="post" action="login.php" name="login" onSubmit="submit_login(); return false;">
<input type="text" name="nome" size="45" /> Nome del PG<br/>
<input type="password" name="pass" size="45" /> Password<br/>
<br/>
<input type="submit" value="Accedi!" />
</form>

Molto semplice.. L'unica cosa da notare è il gestore d'evento onSubmit.
JavaScript

ragioniamo assieme:
non si può sniffare il pacchetto tipo post, perchè tanto anche se risalisse all'ip (che è criptato in sha256) c'è il fattore casuale aggiuntivo che rimescola ulteriormente il tutto ogni volta che si aggiorna la pagina.
non è utile utilizzare sistemi di tipo keylogging, perchè tanto il codice viene pesantemente rimescolato insieme ad altri fattori contingenti (ip e randomize).

Per la parte del login (sempre ricordandoci che la pass nel db è già in sha1):
PhP

function criptaPass($pass)
{
$StringaCasuale = $_SESSION['SN'];
$IpCriptato = hash(sha256, $_SERVER['REMOTE_ADDR'].$StringaCasuale);
$PassCriptata = hash(sha256, $pass);
$UnionePassEdIp = $IpCriptato.$PassCriptata;
$UnionePassEdIpCriptata = hash(sha256, $UnionePassEdIp);

return $UnionePassEdIpCriptata;
}

Spero che sia pensato in modo corretto e possa esservi utile.
:)

ps: ovviamente alla funzione criptaPass va passata la password presente sul database, per poi confrontarla con quella ricevuta via post..

RAID Shadow Legends ↗
Plasma i tuoi eroi fino a farli diventare vere e proprie armi viventi e assembla i più epici gruppi d'assalto mai visti finora!

10/03/2009 14:51:44 e modificato da darkside of breakfast il 10/03/2009 15:36:06

mr_faber ha scritto: Se invii una password pre-criptata per non fare intercettare la password in chiaro vuol dire che metti la tua pagina in condizione di accettare e riconoscere la password criptata. Quindi se un malintenzionato intercetta la password precriptata invece che la password criptata puo' comunque andare a manipolare lo script js una volta scaricata la pagina e fare il modo che invii la password precriptata come se l'aspetta il server. Si puo' sempre aggirare.

no, c'è il fattore casuale che si aggiorna ad ogni ri-caricamento della pagina ed è mescolato e criptato in una maniera pressochè vicina all'innarrivabile... Perchè faccio due rand, li fraziono, li passo in sha1 criptandoli per ottenere una stringa semi-indecifrabile, ne prendo in considerazione solo una parte (e la aprte non è mai fissa, ma random) la unisco all'ip e cripto tutto in sha256 (che è tutt'ora indecifrabile al 100%).
Anche se uno arrivasse a prendere tramite sniffing il pacchetto post che invia l'utente x, le variabili associate a questo sono uniche e totalmente randomizzate.

Se modifica la parte js, togliendo un parametro o quello che è, o inviando una stringa fissa presa tramite sniffing, il server riceverà una pass che non corrisponde a quella creata dai suoi calcoli... quindi darà errore :)

roberto_lc