Come garantire che la password sia cancellata sul lato server?

Hai sollevato diversi problemi.

Fiducia del server

Non sai mai cosa farà il server con la tua password una volta che la invii

Riutilizzo della password

Il riutilizzo della password può essere impedito da tu : non utilizzare la stessa password in più punti.

hashing

Se dovessi cancellare la password prima di inviarla al server, la password con hash diventerà la password. Se il server lo memorizzasse e venisse letto da un utente malintenzionato, poteva accedere con esso. Non ha bisogno della password originale, dal momento che il server controlla l'hash. Eviterebbe l'uso della password su diversi siti Web, ma la misura migliore contro quella non è il riutilizzo delle password.

Un protocollo che funzionerà in questa situazione è uno schema di risposta alle sfide. Il server potrebbe inviare una richiesta al client, il client potrebbe annullare la sfida con un protocollo di hashing con chiave (come HMAC + SHA1) e inviarlo nuovamente al server. Il server tuttavia ha ancora bisogno della password per verificare l'hash, quindi deve essere memorizzato.

Se si desidera uno schema in cui non vi siano segreti condivisi tra il client e il server, cercare la crittografia asimmetrica. Potresti fornire al server la tua chiave pubblica e far verificare chi sei crittografando un nonce con la chiave privata. Puoi utilizzare SSL per questo, con i certificati client.

A meno che il fornitore di servizi non ti permetta di vedere il database, no, non c'è modo di garantirlo. Questo ha dimostrato di essere un rischio in passato e senza dubbio lo farà ancora.

Non è possibile fare molto in questo scenario prima che il server prepari la tua password, in quanto ciò rende fondamentalmente la tua password pre-hashata la destinazione che la tua password sarebbe in un ambiente in cui non è stato eseguito il pre-hashing. Il tuo link alla domanda lato server / lato cliente risponde abbastanza bene.

Invece, concentrati meno su una soluzione tecnica e più su una contrattuale - chiedi ai tuoi provider di usare password hash e includi le clausole penali. Il diritto all'audit è un requisito utile.

Non penso che ci sia un modo pratico di testare un server per sapere che memorizza solo gli hash della tua password, ma posso pensare a uno teorico:

Viste le collisioni hash note per gli algoritmi hash comuni (MD5, SHA1), è possibile testare un server per l'archiviazione delle password hash se esso autentica l'utente utilizzando una coppia in una collisione hash.

Esempio: Diciamo che "abc" e "xyz" hanno entrambi hash MD5 0123456789ABCDEF (ovviamente non è vero). È possibile verificare che il server utilizzi gli hash MD5 se è possibile accedere utilizzando sia "abc" che "xyz" come password.

Questo in pratica è inutile per diversi motivi:

• Fallirebbe il test se il server salasse correttamente i suoi hash (es. hash ("abc") = hash ("xyz") ma hash ("abc" + salt)! = hash ("xyz" + salt)
• AFAIK non sono noti collisioni di hash per SHA1, che è di uso comune.
• Sarebbe ancora più difficile ottenere una collisione hash per valori conformi alle restrizioni delle password comuni (ad esempio le password possono avere solo numeri e lettere e avere una lunghezza massima)
• Anche se il server memorizza un hash della tua password per l'autenticazione, non conferma che il server non stia memorizzando la tua password in testo semplice da qualche altra parte (ho visto le password visualizzate nei file di registro di sistema e web, database log di replica, file di dati di sessione, ecc.)

In pratica dovresti dare per scontato che i siti web stiano sbagliando, e quindi non dovresti usare la stessa password per diversi siti web.

Non puoi. Il server può fare tutto ciò che vuole con i dati che gli vengono inviati. Anche se afferma che i dati sono sicuri con esso, non puoi dire se questo è effettivamente vero. Quindi ti fidi del server che gestisce la tua password in modo appropriato. O fai i tuoi arrangiamenti e usa una password diversa per ogni sito.

Al meglio queste password sono anche completamente diverse tra loro in modo tale che non è possibile estrapolare da una all'altra (cioè senza prefissi / suffissi evidenti). È possibile utilizzare un gestore di password per generare e ricordare quelle password. E poiché molti di questi sono incorporati nei browser, aiutano anche a prevenire il phishing in quanto le password memorizzate sono associate a determinati siti / URL.

Sia che si utilizzino password diverse per siti Web diversi e / o un gestore di password per generare / ricordare tali password, dipende dalla propria percezione del rischio.

Personalmente uso un gestore di password e quindi ho una password diversa per ogni sito. L'ovvio lato negativo è che posso accedere solo a un paio di siti senza, e. g. quando non sono alla mia macchina Ma visto che uno di loro è anche un fornitore di OpenID, sono felice di poter accedere anche alla Stack Exchange Network.

So che questa non è una risposta che cercavi, ma dal POV dell'utente non hai molte opzioni - accedi o non accedi ?! Tuttavia, perché non utilizzare una password univoca su ciascun sito e memorizzarla in un'applicazione portachiavi?

Ricordare la password per ogni accesso è, siamo seri, non un'opzione reale oggi (quasi tutti i siti richiedono registrazione e registrazione). Tuttavia, se si utilizza l'applicazione portachiavi, è necessario solo ricordare la password principale. Il rovescio della medaglia è, ovviamente, un singolo punto di errore (ma, ovviamente, lo stesso vale per utilizzare la stessa password tutto da capo ovunque).

Una di queste applicazioni è keepass

Come tieni traccia di tutte le tue password? - Q su SU.stackexchange

Un modo per determinare come un provider sta memorizzando la tua password è quello di "dimenticare" la tua password. Su un sito configurato correttamente, anche l'amministratore non dovrebbe essere in grado di scoprire la tua password poiché l'unica cosa che viene memorizzata è l'hash salato della password.

Quasi tutti i siti che consentono agli utenti di creare un account offrono un meccanismo per recuperare l'accesso a tali account nel caso in cui un utente perdesse o dimenticasse la propria password. Un sito web configurato correttamente ti sfiderà a rispondere a domande di sicurezza e poi a reimpostare la tua password, mentre un sito definitivamente interrotto ti ti dirà la tua password.

Non sicuro al 100%, molti falsi negativi ma zero falsi positivi.

Non puoi, ed è per questo che OpenID esiste - perché come utente hai solo due opzioni se vuoi usare siti che richiedono l'accesso senza: 1) fidati di loro, 2) usa una password unica per ogni sito.

Non puoi essere sicuro che il server cancellerà la password prima di memorizzarla. @Rory sottolinea che è un requisito ragionevole che potresti provare a far rispettare con mezzi non informatici, ma non è realistico credere che tutti i server faranno le cose correttamente. La soluzione non è quella di utilizzare la stessa password (o password che possono essere indovinate l'una dall'altra) per due siti distinti.

Le password "distinte" possono essere generate da una "password principale" con una funzione di hash crittografica (ad esempio, hai hash la concatenazione del nome del sito e la password principale - ci sono modi per fallire, ma il principio è valido) . Il software esiste per quello. Oppure puoi memorizzare password generate casualmente in un file, simmetricamente crittografato con una password principale. Il software esiste anche per questo. Potrebbe richiedere diversi moduli (un file crittografato, una connessione SSH a un server che ospita il file della password, un'estensione del browser che utilizza una funzione di hash crittografica; ...).

In ogni caso, è difficile fare solo nella tua testa (maledire quel cervello biologico!), perché richiede di fare calcoli estesi e / o ricordare molti elementi casuali.

Io sostengo, tuttavia, che lo scenario "fallo nel tuo cervello" è non realistico . Perché vorresti calcolare l'intera cosa nel tuo cervello? Questo perché la macchina locale su cui si sta per digitare la password non ha il software necessario installato; è una macchina casuale, diciamo, un cybercafe. Hey aspetta ! Stai per digitare la tua password su una macchina cybercafe ? Una macchina che potrebbe essere piena di keylogger e altri malware? Ora questa è una cattiva idea. Non c'è bisogno di un server scritto male, in queste condizioni: sei abbastanza bravo a fare cose non sicure da solo.

Quindi la necessità di uno schema di derivazione / archiviazione delle password che puoi eseguire "nel tuo cervello" è in realtà una necessità per poter fare qualcosa che è abbastanza stupido, per quanto riguarda la sicurezza. Quindi non farlo. Se non riesci ad accedere a una memoria oa un generatore sicuro per le password per sito, non sei in un contesto in cui potresti utilizzare comunque la password indicata.

Se comprendo correttamente la tua domanda, allora:

1. Non c'è modo di garantirlo. Immagino che potresti forse scrivere un'estensione del browser lato client (forse un'iniezione javascript farebbe?) Che cancellerebbe il valore di ogni password-textbox prima di inviarlo. Posso ancora vedere come potrebbe avere problemi. Ma sarebbe un inizio.
2. C'è una soluzione più semplice che utilizzo - non utilizzare una password diversa per ogni sito, ma utilizzare una password diversa per ... come metterla ... livello di sicurezza di un sito? Cioè, usa la stessa password per tutti i siti in cui non ti interessa se viene rubato (come blog, forse la rete stackexchange, ecc.), Ma usa password individuali per i siti che sono davvero sensibili alla sicurezza (come i siti web delle banche, paypal , eccetera.). In questo modo hai ancora diverse password da ricordare, ma dovrebbe essere una quantità gestibile e può essere resa ancora più facile da ricordare utilizzando le passphrase.

used on other sites.

Utilizza una password unica per sito, problema risolto.

Il metodo migliore che ho visto per proteggere le password per siti diversi è semplicemente utilizzare un gestore di password con una password generata.

Un altro metodo che ho visto è quello di ricordare una singola password e cancellarla con il dominio del sito come sale. L'hashing può essere fatto con un'ampia varietà di servizi online, basta sceglierne uno che supporti l'utilizzo di un sale e preferibilmente non utilizzare MD5. La maggior parte delle persone pensa che tu stia usando una password generata casualmente prima che si rompano l'hash.

Mentre di solito è impossibile dire se una password è memorizzata in testo normale o no, il controllo del metodo di recupero della password può darti qualche indizio. Se è possibile recuperare la vecchia password in una e-mail, la password è sicuramente archiviata in testo normale (o una crittografia reversibile).

La crittografia o l'hashing del lato client di solito non sono efficaci perché il codice lato client e tutti i segreti che utilizza sono disponibili per chiunque possa ispezionare: un utente malintenzionato può visualizzare l'origine, eseguire il Javascript con Firebug ecc.

Non puoi sapere che cosa fa il server con le password e se le blocca correttamente, quindi vale la pena di essere paranoico sulle tue password. Ti consiglierei di scrivere i tuoi segreti importanti e tenerli nel tuo portafoglio (suggerimenti di Bruce Schneier - [1]) o utilizzare un'app mobile come 1Passwd.

[1] link