Come implementare password specifiche per applicazione usando gli hash forti?

Question

Come implementare password specifiche per applicazione usando gli hash forti?

#1 da (1 voti)

3

Sto implementando un servizio in cui le password specifiche dell'applicazione sembrano una buona scelta per migliorare la sicurezza. Una domanda su perché e quando potrebbero avere un senso è già stata discussa qui Account Google: implicazioni sull'utilizzo di password specifiche dell'applicazione

Ora, mi interessa il modo in cui, specialmente con hash forti come bcrypt o scrypt.

Presumo che Google, iCloud e amp; Co memorizzare gli hash delle password specifiche per l'app.
Dato che tutte le password specifiche per l'app si associano allo stesso nome utente, significa che si deve confrontare l'hash della password specificata con tutti gli hash noti del nome utente specificato?
Se è così, e dico che uso un algoritmo di crittografia come bcrypt o scrypt con maxtime da qualche parte tra 100 e 200 millisecondi, non dovrei parallelizzare l'hashing & confronto per minimizzare il tempo di attesa nel caso peggiore?
C'è una buona ragione per cui hanno scelto di non utilizzare nomi utente specifici dell'applicazione? per esempio. Ad esempio, ho un account "foo" e ":" non è consentito in un nome utente, perché non utilizzare "foo: bar" come nome utente specifico per app-bar dell'account "foo"? In questo modo, la relazione username < - > la password è di nuovo 1: 1. È perché gli utenti non dovrebbero ricordare più nomi?

Mille grazie per i tuoi pensieri.

authentication passwords google bcrypt scrypt

posta RobS 08.04.2015 - 07:05

fonte

1 risposta

Leggi altre domande sui tag authentication passwords google bcrypt scrypt

L'esecuzione di un servizio DNS abilitato DNSSEC è difficile quanto l'esecuzione di una CA? Connessione a doppia presa

score 1 · Answer 1

Non ho implementato un sistema del genere.
Ma posso ancora rispondere alle tue domande (spero).

Una password diversa per ogni applicazione è una funzionalità utile per migliorare la sicurezza, in modo che una password non ti dia accesso immediato a tutte le app.

Il problema con l'accesso con una password diversa per ogni applicazione è la quantità di password. A Google piacciono 10 app, quindi dovresti ricordare 10 diverse (buone) password che è piuttosto improbabile per un utente standard, che userebbe solo una e la stessa per tutti i servizi (potrebbe anche essere una cattiva). Senza un gestore di password questo onere è impossibile da superare e le persone inizieranno a lamentarsi perché dicono: "Ehi, ho effettuato l'accesso una volta, non è abbastanza !?"

Tecnicamente non c'è (quasi) alcuna differenza di velocità tra più password e una singola password. Se implementassi un sistema del genere, andrei con il secondo approccio che hai menzionato, quindi tagga un nome utente con l'app che sta usando (forse non nella stringa in quanto ciò potrebbe causare alcuni attacchi medi, ma con alcuni dati associati) . Quindi l'utente effettua l'accesso, fornisce la sua password, apre il database delle password dell'app, controlla il nome, esegue l'hash delle password e confronta il tag calcolato con il tag memorizzato. Se corrispondono, concedi l'accesso, se non rifiuti l'accesso.

Se dovessi memorizzare una serie di tag con lo stesso nome utente (che sarebbe stupido in quanto consentirebbe all'utente di utilizzare più password per lo stesso account e quindi limitare la forza alla forza della peggiore password), basta calcolare il tag una volta (supponendo che tu abbia usato lo stesso sale) e cercare le corrispondenze. Se sei stato furbo, hai usato diversi sali e quindi hai introdotto una severa penalizzazione delle prestazioni. (nel peggiore dei casi, il tempo di accesso cresce linearmente con il numero di account), a meno che non sia possibile parallelizzare, il che potrebbe rallentare il log-in degli altri utenti, poiché devono attendere la cpu-time necessaria per il log-in.