Gli hash degli hash utilizzati per l'archiviazione delle password sono in pratica? Perché perché no? [duplicare]

Naviga le tue risposte
2

Un ingenuo sviluppatore potrebbe memorizzare direttamente una password nel database, che verrebbe poi confrontata direttamente con la password inviata da un client. Uno sviluppatore più attento alla sicurezza potrebbe invece archiviare solo il hash della password nel database e quindi confrontare l'hash della password dal client. Ma la maggior parte delle persone usa le stesse poche password per i propri account. Pertanto, un sito che richiede un indirizzo email e una password per un account / accesso può quindi avere accesso a tutti gli altri siti per i quali l'utente ha fornito la stessa email + password.

E se il cliente stesse creando l'hash stesso? In questo caso, l'hash verrebbe inviato al server, ma ancora una volta non importa - se so quale hash usi per accedere a google.com, l'hash sarà lo stesso per amazon.com (assumendo lo stesso algoritmo). Che ne dici di accodare una stringa dal server alla password, hashing allora ? Esempio:

  1. Vado su amazon.com e ho chiesto le mie credenziali
  2. Con la pagina di login, amazon invia un guid: 'cdfefe81-d466-49a6-acea-140fa52c0901' (questo può essere associato con l'account utente, o semplicemente avere 1 per tutto di amazon)
  3. Inserisco la mia password, 'safe_password'
  4. Il client aggiunge il guid per creare 'safe_passwordcdfefe81-d466-49a6-acea-140fa52c0901'
  5. Questo è un hash con qualsiasi algoritmo di hash appropriato e quindi inviato al server. All'interno del server, l'hash viene re-hash (con un salt) e confrontato con l'hash nel database per l'autenticazione.

Il vantaggio di questo flusso consente a un utente di utilizzare password uguali o simili per più server e fintanto che tutti i client seguono questo schema, nessun server potrebbe mai conoscere la password effettiva dell'utente, anche se tale server è stato compromesso.

Modifica

Per chiarire, l'obiettivo è proteggere la password dell'utente, supponendo che un server sia completamente compromesso. Se eseguo un sito che richiede il login, ricevendo un hash salato dal client (dove fornisco il salt), anche se un utente malintenzionato ha accesso a tutti i dati sul lato server, non essere mai in grado di trovare la password originale dell'utente, assumendo un buon algoritmo di hashing, che limiti significativamente il potenziale impatto per gli utenti di una violazione della sicurezza.

Un'altra applicazione sarebbe numeri di carte di credito, che sono molto simili alle password. Immagina questo scenario: sono responsabile della convalida dei numeri di carta di credito di Visa per l'approvazione delle accuse. Amazon vuole usare il mio servizio, così come ogni altro importante venditore al mondo. Così dico ad Amazon "Non autenticherò alcuna carta di credito direttamente da un numero, ma ti chiederò di inviarmi una versione hash di una stringa, e visto che ti sei registrato come venditore, qui è un GUID che verrà assegnato al tuo account ". La stringa sarebbe qualcosa sulla falsariga di <cc#>:<expiration>:<GUID supplied *to Amazon* by Visa> .

Quindi questo intero flusso:

  1. Amazon desidera elaborare CC, richiede GUID da Visa
  2. Visa genera GUID, invia ad Amazon e associa il GUID all'account
  3. Amazon invia GUID con la pagina di input della carta di credito all'acquirente
  4. Sul lato client, dopo aver inserito le informazioni CC, questa informazione non viene mai inviata ad Amazon unhashed , invece, il client costruisce la stringa come descritto sopra, la hash e invia l'hash risultante ad Amazon.
  5. Amazon vuole consentire ordini ripetuti, quindi memorizza questo hash nel loro database.
  6. Per l'autenticazione, Amazon utilizza il modello di autenticazione S2S esistente per dimostrare che sono Amazon.com e invia l'hash dal client, insieme al nome, all'indirizzo, ecc. dell'acquirente
  7. Visa riceve l'hash, controlla il GUID di Amazon e trova tutte le carte di proprietà dell'acquirente specificato. Per ogni carta dell'acquirente, Visa ricostruisce e restituisce il numero della carta + data di scadenza + Amazon GUID e confronta l'hash con quanto ricevuto da Amazon.
  8. Visa trova una corrispondenza, dice che Amazon ha il diritto di caricare questa carta e Amazon invia una conferma di detto addebito.

Dato questo flusso, anche se dovessi accedere a tutti i database, server, hard disk, email, traffico in entrata, ecc. di Amazon.com, vorrei mai conoscere il numero della carta di credito dell'utente . Il maggior danno che potrei eventualmente infliggere sarebbe se potessi fare lo spoofing di essere un server Amazon.com, potrei essere in grado di caricare l'utente per conto di Amazon.com, ma presumibilmente questo andrebbe nell'account di Amazon.com, quindi non lo farei probabilmente ne beneficeranno affatto. In una situazione ideale, questo flusso sarebbe parte della logica SSL, in modo tale che solo il sito che implementa qualcosa di questa natura riceve il simbolo di blocco nei browser client (non l'ha pensato interamente, ma sembra plausibile)

    
posta Rollie 24.05.2015 - 12:55
fonte

2 risposte

2

Il tuo schema non funzionerebbe così com'è, perché il server Amazon non ti ha autenticato quando arrivi ancora nella pagina di accesso. Quindi deve lasciare che il browser del tuo cliente decida come creare un guid unico. Se il server ha provato a calcolare una guida univoca basata su attributi noti come l'indirizzo IP o l'impronta digitale del browser, non sarebbe possibile connettersi da più dispositivi o posizioni.

Tutti i browser su tutti i dispositivi dovrebbero quindi elaborare i GUID in modo simile in modo che gli utenti possano ottenere una guida coerente. Ciò significa che gli utenti si autenticano sul proprio dispositivo, in un modo o nell'altro. Supponiamo che guid sia una combinazione di credenziali utente trasmesse al browser e il nome di dominio di ciascun sito Web per impedire lo spoofing. Ora puoi creare password univoche, con due forti vincoli:

  1. non gestisci siti con più nomi di dominio
  2. hai bisogno di attrezzature compatibili

Il primo problema potrebbe essere risolto facendo in modo che browser e siti comunichino elenchi di domini attendibili come per la politica Same-Origin e API pubbliche per i browser per interrogare i domini trusted di un dominio "padre" utilizzato come seme per algoritmo guid. Questa è principalmente infrastruttura, niente impossibile.

Il secondo problema è più serio. Il tuo obiettivo originale è quello di rendere inutile lo spoofing della password, o in altre parole di far generare a tutti i client credenziali univoche per utente / dominio (nel qual caso, a proposito, viene sostituita l'intera idea di una password). Se questo dovesse essere adottato, avresti bisogno di tutti i siti web e tutti i client per essere immediatamente compatibili. In caso contrario, gli utenti riscontreranno situazioni in cui è necessario fornire una password univoca basata sulle guide a un sito, ma non possono calcolarlo o dove possono calcolare una password basata sulle guide, ma devono utilizzare una vecchia password stegabile.

Nota come hai importato uno dei principali problemi dei gestori di password che creano password uniche: devi mantenere l'accesso al gestore per evitare di essere bloccato! Se si desidera mantenere un livello di compatibilità che consente di connettersi con la vecchia password stegabile, tale password potrebbe essere falsificata e riutilizzata.

C'è comunque un'applicazione alla tua idea, tuttavia: l'esclusiva di una guida in cima a una password originale potrebbe dare ai siti Web un livello leggermente più elevato di confidenza che tu sia un cliente legittimo e non una parodia. Questo suona bene, ma non è necessariamente sufficiente per i grandi fornitori di servizi, che sono spesso confrontati a dispositivi compromessi e non solo con password rubate. Un dispositivo compromesso fornirebbe a un utente malintenzionato un mezzo per generare tutti i tuoi guids per tutti i tuoi siti Web (dal momento che il tuo segreto può essere estratto). Alla fine, hai gli stessi inconvenienti e la stessa superficie di attacco di un gestore di password, perché è praticamente quello che hai creato!

    
risposta data 24.05.2015 - 14:42
fonte
0

Continuo a pensare, il problema non è ancora stato risolto. Qual è la risorsa che stai cercando di proteggere? la password o l'hash della password? È l'hash della password / password memorizzata o durante il transito?

Alcuni disconnect / o requisiti di chiarezza

I go to amazon.com, and am asked for my credentials. With the login page, amazon sends a guid: cdfefe81-d466-49a6-acea-140fa52c0901' (this may be associated with the user account, or just have 1 for all of amazon)

Non sei sicuro di come identificare il cliente. Forse, se hai il server per chiedere username e password uno alla volta, questo potrebbe funzionare, ma se i campi username e password sono serviti dalla stessa pagina, potrebbe no. Mantenerlo uguale per tutti gli utenti potrebbe vanificare lo scopo.

La chiave è che questo dovrebbe essere un processo ripetibile su tutti i dispositivi, client noti / sconosciuti ecc. e non è

I enter my password, 'safe_password'. The client append the guid to create 'safe_passwordcdfefe81-d466-49a6-acea-140fa52c0901'. This is hashed using whatever hashing algorithm is appropriate, and then sent to the server. Inside the server, the hash is re-hashed (with a salt) and compared with the hash in the database to authenticate.

Quindi, se la password 'safe_password' è nelle mani di un utente malintenzionato attraverso un sito Web compromesso, questo processo lo fermerà dall'account amazon.com?

Questa soluzione potrebbe avere un posto, come gli ambienti autenticati della macchina client.

    
risposta data 24.05.2015 - 16:38
fonte

Leggi altre domande sui tag

chrome app (javascript) - memorizzazione della password di crittografia in memoria GPG: impossibile crittografare le chiavi del DSA 3072