"verifica" password

[bonmario]

Ciao a tutti,
scusate se non userò i termini corretti, ma sono abbastanza ignorante in materia ...
In un mio programma fatto con Lazarus, mi hanno chiesto di verificare una password immessa dall'utente.
Vorrei evitare di scrivere la password nel programma o di salvarla comunque in altre maniere, mi è però capitato di leggere che spesso, invece di salvarsi la password, ci si salva un "codice hash" relativo alla codifica della password.
Per caso avete qualche link e/o funzione da consigliarmi per gestire questa cosa?
In passato mi è capitato di fare qualcosa di simile, ma visto che la password che dovevo salvare non era importante, avevo fatto una semplice trascodifica.

Grazie, Mario

[DragoRosso]

Non ho compreso a pieno: vuoi salvare una password e poi in futuro verificare se l'immisione corrisponde a quanto salvato ?

Normalmente come hai detto correttamente si usano le funzioni di hashing, in modo che la password non venga salvata.

La funzione può essere riassunta in questo modo (copiata pari pari da Google ... da verificare verificata !!):

Codice: [Seleziona]

uses md5;

var
  StringaOriginale, HashRisultante: string;
begin
  StringaOriginale := 'La mia stringa da hashare';
  // Calcola l'hash MD5 e lo formatta come stringa esadecimale stampabile
  HashRisultante := MD5Print(MD5String(StringaOriginale));

  // Visualizza o utilizza l'hash (es. in una console o un controllo UI)
  Writeln(HashRisultante);
end;

P.S.: ci sono funzioni più complesse che si possono usare, come la criptatura tramite chiper (simmetrica) o la criptatura assimetrica, ma direi che sono oltre lo scopo.

P.S.2: l'hashing non ti consente di "ritornare indietro" (cioè dall'hash ricreare la password) ovviamente e non è univoco, cioè a diverse password potrebbe corrispondere lo stesso hash.

P.S.3: Occhio agli algoritmi fantasiosi da usare ... devono essere stabili nelle ERE (si, ere geologiche) ossia tra runtime diversi di Lazarus (ossia diverse versioni), diverse versioni di OS (ad esempio criptatura tramite SSL2 ora non più usabile) e diverse versioni di hardware.

[bonmario]

Ti ringrazio per la risposta, do un occhio a quello che mi hai consigliato

Provo a spiegare meglio aggiungendo qualche dettaglio: da un mio programma, devo lanciare l'unzip di un file zip che è criptato tramite password. Lo zip può arrivare da 4 o 5 uffici diversi, al momento non ricordo di preciso, ed ognuno di loro lo crea con una password fissa.
Faccio un esempio con password semplici: l'ufficio di Milano usa come password "pippo", quello di Roma "pluto",e  così via
Chi usa il programma mi ha chiesto, come prima cosa di chiedere da dove arriva lo zip, poi di far digitare all'utente la password e, se non è quella corretta, di emettere un messaggio che mi ha dato lui, se invece è corretta, di far partire l'unzip.
Gli ho proposto di darlo partire comunque, e di dare errore se l'unzip ha problemi nell'estrazione, ma non vuole ...
Volevo quindi evitare di scrivere nel mio sorgente le password "pippo" e "pluto".
Con quello che mi hai detto tu, nel mio sorgente metterei gli hash delle password e, dopo che l'utente l'ha digitata, farei la verifica.

Ciao e grazie ancora

[DragoRosso]

Quello che ho fatto in passato per casi simili ai tuoi è di archiviare l'Hash in un server aziendale (o altro server sicuro) e con un banale programmino server HTTPS (o REST se preferisci) trasmettere ai vari client l'hash su richiesta.

Quindi il tuo programmino invece di avere l'hash a codice se lo andrà a pescare direttamente dal server ogni volta che sia necessario. Poi magari può mantenere una copia cache in memoria per tot tempo.

Puoi semplicemente sfruttare anche un TCPs (quindi un trasferimento da server a client da una porta TCP X) per avere i dati (in raw, xml, json, bson, kson ?son o quanto altro la tua immaginazione possa contemplare).

EDIT: il concetto è che l'eseguibile non deve avere al suo interno dati che possono in un futuro cambiare nel tempo, tanto meno hash, password, credenziali o altro. E' un cattivo modo di programmare. Questi dati dovrebbero stare in un qualcosa di esterno (file o server ad esempio) in modo da poter essere aggiornati senza dover modificare l'eseguibile.

[bonmario]

il concetto è che l'eseguibile non deve avere al suo interno dati che possono in un futuro cambiare nel tempo, tanto meno hash, password, credenziali o altro. E' un cattivo modo di programmare. Questi dati dovrebbero stare in un qualcosa di esterno (file o server ad esempio) in modo da poter essere aggiornati senza dover modificare l'eseguibile.

Sono d'accordo con te al 100%, ma quando "il cliente" vuole qualcosa, e nonostante le tue osservazioni non cambia idea, io rispondo: "obbedisco !"
L'importante è che sia consapevole dei rischi, se poi a lui va bene così, amen

P.S. NAturalmente, per poterglielo fare così come vuole lui, mi ha detto tutte le password 

[tito_livio]

Scusami ma mi sembra che il cliente non voglia che il controllo sulla password venga fatto dal programma di unzip ma vuole che sia fatto dal tuo programma che deve prima chiedere la città, poi fare il controllo password e poi se la password è corretta avviare l'unzip del file.
Secondo me dovresti memorizzare città e relativi hash delle password in un file, anche un file di testo.
Infatti, come dice DragoRosso, se poi vogliono cambiare una password non c'è così bisogno di ricompilare il programma. Addirittura potresti produrre il programma in modo che il cliente potrebbe modificare le password in autonomia.

Poi, se vogliamo essere un po' pignoli, memorizzare l'hash in chiaro (dentro o fuori del programma) non è sicuro.
I vari hash andrebbero salvati cifrati con gli strumenti che mette a disposizione Lazarus come il componente DCPcrypt.
Ciao.