Pagina 3 di 11 primaprima 1 2 3 4 5 ... ultimoultimo
Visualizzazione dei risultati da 21 a 30 su 102
  1. #21

    Re: Re: perchè è più sicuro queto login ?

    Originariamente inviato da mark2x
    Non è del tutto vero, esistiono anche sistemi di One Time Password, e leggendo la pillola pensavo avessi implementato un sistema simile..
    certo, e le spedisco pure a casa le chiavette stile UniCredit ...


    Originariamente inviato da mark2x
    per quanto riguarda il solo login, non è vero..
    one time password, se è la chiave tipo PayPal o UniCredit (che ho da più di un anno) non è un discorso affrontabile in un forum ... sicuramente non in questo dove sai bene che la gente ancora stenta a usare escape_string e si fa trapanare i siti anche dai meno abili ...


    comunque, già che l'hai tirata fuori, one time password si usa solitamente per le sole operazioni, non per il login (sempre tu stia parlando di quello che intendo io).

    Lo stesso sito UniCredit, utilizza questo metodo per effettuare il login, no salvataggio dati sul PC (in javascript), no invio in chiaro ... in pratica era stato preso proprio come spunto per questa pillola.

    Quindi, questo tipo di login è più sicuro ? Sempre, poi bisogna vedere sotto cosa c'è, più cose ci sono, più questi piccoli stratagemmi potranno aumentare ulteriormente la sicurezza .... di poco o di molto non importa, ciò che conta è che l'aumentino
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  2. #22
    Utente di HTML.it L'avatar di mark2x
    Registrato dal
    Nov 2005
    Messaggi
    1,940
    sempre tu stia parlando di quello che intendo io
    Sì e no, intendo cose più terra terra.

    Client Server
    +------------------> username
    stringa <--------------+
    +------------------> firma (password+stringa)

    [.:: JaguarXF ::.]
    __________________

  3. #23
    ah ... ok, stai parlando di una salt presumibilmente random, beh, in effetti questa potrebbe essere ulteriormente sicura (e di semplice implemnetazione) ... se avrò tempo e modo di scrivere un esempio aggiungero questo tuo consiglio volentieri, documentandolo, a questa pillola
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  4. #24
    Utente di HTML.it L'avatar di mark2x
    Registrato dal
    Nov 2005
    Messaggi
    1,940
    Io avevo una certa intenzione di farne un articolo per Html.it se e quando mai ne avessi avuto tempo e/o voglia e se mai fosse interessato alle ALTE SFERE ....
    Magari lo possiamo anche fare a due mani... ma... in questo momento ho altri programmi (professionali per l'azienda) che mi aspettano ancora vivisezionati ...

    Magari se qualcuno dei due fa qualcosa, lo scrive qui, oppure ci mAssaggiamo in pvt.

    aloha

    P.S.: per il metodo, non è sicuro, ma sicurissimo, la sua unica """vulnerabilità""" sta di fatto che è a chiave pvt.

    [.:: JaguarXF ::.]
    __________________

  5. #25
    Originariamente inviato da mark2x
    Magari lo possiamo anche fare a due mani...
    veramente ho già fatto una classe server ed una client in grado di fare a grandi linee quello che mi hai consigliato ( rigorosamente rivisto secondo me ) ed ho già una demo disponibile compatibile XHTML 1.1 tutti i browsers in circolazione (non usa nemmeno Ajax e fa remote scripting vecchio stile ) e virtualmente WAI-AAA compatibile ( l'xhtml generato è WatchFire "ready" ... anche se WatchFire non potrà mai vederlo )

    Ti spiego brevemente cosa fa, così mi dici se va bene prima che lo posto:

    1 - genero il form in automatico dal JS poichè senza JS la firma di invio non è fattibile, quindi è un raro caso di indegradabilità del codice

    2 - quando l'utente scrive user e pass (altrimenti non accade niente) lo script richiede una pagina server (senza inviare ovviamente alcunchè) la quale invia in callback javascript una salt generata da md5(uniqid(rand(), true)) (volendo anche sha1 ma siccome anche lo script server è compatibile con quasi tute le versioni di php ho preferito, per la demo, md5, comunque modificabile a proprio piacere)

    3 - una volta ricevuta la salt lo script hasha lo user, hasha la pass ed in fine invia al server un hash di (salt + hashuser + hashpass) ... dove salt è , come mostrato, già hashata.

    4 - questa stringa univoca presumibilmente indecrifabile per chiunque anche trovasse la salt intermedia, verrà confrontata, dopo le giuste verifiche, nella tabella ... qualcosa tipo

    SELECT id FROM user_list WHERE MD5(CONCAT('{$salt}', user, pass)) = '{$stringaclient}'

    dove user e pass sono dati già hashati in database, ovvero l'esempio da per scontato che in db non ci siano dati in chiaro (ma forse anche lo user è un pelino eccessivo ... magari quello lo lascio non hashato, tanto la stringa è comunque incomprensibile)

    5 - se il db trova un solo id con quella corrispondenza rimanda l'utente alla pagina a questo punto sbloccata.


    Il tutto basato su un'unica var di sessione ... probabilmente non indispensabile ma non saprei, in fondo devo ancora postarlo.

    Fammi sapere cosa ne pensi se puoi, grazie
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  6. #26
    uhm, ripensandoci forse le sessioni non servono ... meglio sessioni o stringhe che viaggiano indecrifabili ? :master:
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  7. #27
    andrea, quel sistema non va bene, visto che la stessa stringa md5, come è ovvio che sia, può essere ottenuta con stringhe in ingresso diverse, per cui quella SELECT potrebbe restituire più record.

  8. #28
    Originariamente inviato da skidx
    andrea, quel sistema non va bene, visto che la stessa stringa md5, come è ovvio che sia, può essere ottenuta con stringhe in ingresso diverse, per cui quella SELECT potrebbe restituire più record.
    in realtà il sistema prevede sha1, ho usato md5 inizialmente solo perchè sha1 è disponibile da PHP 4.3.0 in poi ... dici che anche con sha1 c'è il rischio di collisione ? (presumo di si ... ma con quanti utenti ?)

    Il fatto è che uso una salt ... quella che spesso dicono sia la cosa più sicura


    creaUnivocoDa(idUnivoco + nome + univocoPassword)

    dove idUnivoco dovrebbe essere sempre univoco (uniqid(rand(), true)) , l'hash password può anche (in teoria) non essere univoco (se si ammettono utenti con password uguali ma almeno diverso username) e di conseguenza la stringa risultante dovrebbe per forza di cose essere univoca ... o no ? :master:
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  9. #29
    scelta di md5 a parte ... una query di questo tipo per soffrire di collisioni bisogna aver fatto un abbonamento annuale con la sfortuna, giusto ???

    codice:
    $query = sprintf(
    	"SELECT id FROM user_list WHERE %s(CONCAT('%s', user, pass)) = '%s' AND %s(user) = '%s'",
    	$hash, $salt, $login, $hash, call_user_func(array(new SecurityForm, 'hash'), $user)
    );
    
    // $hash => a seconda della funzione di hash scelta sarà MD5 oppure SHA1
    // $salt => l'hash della salt generata con uniqid(rand(), true)
    // $login => l'hash della "firma" di login - hash(salt.userName.hash(password))
    // SecurityForm->hash($user) => l'hash del nome utente (sql injection free)
    In pratica verifica tramite la salt che la stringa login sia presente ed in più verifica che il nome utente in grado di generare la stringa di login, una volta hashato, sia identico all' hash inviato dal client del proprio nome utente ... qualcosa tipo ...

    SELECT id FROM user_list WHERE MD5(CONCAT($salt, user, pass)) = $login AND MD5(user) = $user

    dove la pass in db è salvata già hashata (lo user resta in chiaro)


    dovrebbe essere sufficiente ? ... nel frattempo ho anche tolto le sessioni per evitare problemi di cookie o altro ... dite che basta per blindare un banale login ?


    poi il discorso che se un altro utente conosce user e pass .... ovvio che entra comunque
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  10. #30
    ok ... continuo il monologo ... ho pensato che in questo modo un bruteforce sarebbe comunque non impossibile ... dato che salt, user e login viaggiano in chiaro, seppur hashati, tentare di trovare la pass o l'hash della stessa (doppio bruteforce) non è un'operazione proprio impossibile

    $tentativo = 12345;
    $hash = md5($tentativo);
    if(md5($salt.$utente.$hash) === $login)
    ... trovata pass

    quindi a questo puntoi presumo che qualunque firma sia reversibile, una volta letto la salt che per forza di cose viene inviata al client .... dico male ? non vorrei aver fatto uno script che di fatto aumenta di poco la reale difficoltà nel risalire ai dati, rispetto quanto avevo già fatto un anno fa ... l'unica cosa che mi viene in mente è che così la salt è sempre diversa ad ogni accesso, ma serve veramente a qualcosa ? :master:


    [edit]
    SELECT id FROM user_list WHERE MD5(CONCAT($salt, user, pass)) = $login AND MD5(CONCAT($salt, user)) = $user

    togliendo l'invio in chiaro di user sostituendolo con un hash($salt.$userName) ... bisogna prima fare brute forcing per l'utente

    $tentativo = 'pippo';
    if(md5($salt.$tentativo) === $user) {
    // trovato utente
    $tentativopass = '12345';
    $hash = md5($salt.$tentativopass);
    if(md5($salt.$tentativo.$hash) === $login)
    ... trovata pass
    }

    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

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.