Domanda:
Quali sono gli svantaggi dei generatori di password senza stato?
Cookiecutter
2019-07-30 00:13:01 UTC
view on stackexchange narkive permalink

Qualcuno ha esperienza pratica con generatori di password senza stato (gestori) come Getpass?

Sembra che faccia la maggior parte del lavoro dei gestori di password nel cloud, ma si appoggia più sul lato della sicurezza in quanto non ci sono server con password da penetrare.

Esistono molti gestori di password che utilizzano l'archiviazione locale.Puoi sincronizzare quelli utilizzando la tua scelta di servizio cloud (Dropbox, Box, iCloud, Drive, OneDrive, ecc.) O per niente.Tocca a voi
"si appoggia maggiormente al lato sicurezza": non è una valutazione equa.Tutti si appoggiano al lato della sicurezza: questo tipo di strumento ha una funzionalità che mitiga un tipo di rischio.
Se non dipende dallo stato, da cosa dipende?Questo contiene una vulnerabilità?
Io uso Keepass.Uno dei bei vantaggi è che non memorizza semplicemente le mie password.Posso memorizzare molti altri dati su un determinato account, inclusi gli "allegati".Ovviamente un gestore di password senza stato non può essere utilizzato per nient'altro che password che, per me, è una limitazione piuttosto grande
@Alexander Dropbox ha recentemente cambiato il suo piano gratuito per limitare a 3 dispositivi, era perfetto per sincronizzare Keepass.iCloud è solo Apple, Google Drive è meh, OneDrive è basato su Microsoft.
@JMK c'è anche mega.nz (Il proprietario è stato bruciato dall'FBI in passato e ha imparato la lezione. Ora è un servizio paranoico, incentrato sulla privacy dei dati degli utenti: non vogliono sapere cosa memorizzi sul loroservizio in modo che non possano essere incolpati per l'hosting. Se il loro web crawler trova una chiave privata, eliminano automaticamente i dati associati, senza esaminarli.)
Inoltre, se non ti fidi dei servizi cloud, potresti sincronizzare un database di password locale (ad esempio da KeePass) tra i tuoi dispositivi utilizzando un programma di sincronizzazione come Syncthing o Resilio Sync.
@JMK Riesco a mantenere esattamente 3 dispositivi e sincronizzare il mio file KeePass su Dropbox.Ma c'è un altro aspetto negativo: il client Android non carica automaticamente i file modificati.Esistono client di terze parti che lo fanno.Fino a quando non si rompono.
Sei risposte:
Benoit Esnard
2019-07-30 00:24:47 UTC
view on stackexchange narkive permalink

Uso da anni un generatore di password senza stato e penso che ci siano molti inconvenienti:

  • Se la tua password principale è compromessa, tutte le tue password lo sono. In confronto, i gestori di password standard richiedono che l'autore dell'attacco comprometta la chiave master e abbia accesso all'archivio delle password.
  • Se un sito web ha una policy per le password, potresti non essere in grado di generare una password che la rispetti.
  • Se una delle password deve essere aggiornata per qualche motivo, è necessario mantenere quello stato da qualche parte. Ad esempio, devi ricordarti di generare una password per "StackExchange2" invece di "StackExchange".
  • Se hai già alcune password che non puoi modificare (per vari motivi), un generatore di password statico non ti aiuterà.

Per tutti questi motivi, penso che dovresti usare definitivamente i gestori di password standard.

Grazie!Quindi sei passato a un gestore di password standard?Mi sembra che tutto tranne il tuo ultimo punto possa essere risolto associando quei dati a una variabile del sito web
Il più grande vantaggio del gestore di password senza stato è che non è necessario conservare un file aggiuntivo.Se finisci per dover mantenere comunque un file extra per tutte quelle variabili specifiche del sito, questo vanifica il punto di utilizzare il gestore di password senza stato.
@LieRyan davvero.Usando uno di questi dovresti sincronizzare manualmente tra tutti i tuoi computer e dispositivi spostando i file.Nella migliore delle ipotesi ingombrante all'estremo, nel peggiore dei casi un grave problema di sicurezza e forse impossibile (date le restrizioni negli ambienti sicuri sull'introduzione di file esterni).
Il lat con potrebbe essere il peggiore di tutti.Potrebbe essere utile ordinarlo in cima e enfatizzarlo di più, perché le persone usano alcune password davvero orribili, anche per i gestori di password, e mentre un gestore di password dovrebbe essere compromesso da solo (senza il database delle password, la password principale è inutile), qui un compromesso della chiave sarebbe disastroso, in più la chiave può essere forzata da qualsiasi proprietario del sito web se lo desidera (e se fa un'ipotesi corretta sulle impostazioni di hashing della password, che non sono segrete secondo il principio di Kerckhoff).
@Luc ma l'ultimo svantaggio non è così enorme, perché nella maggior parte dei casi le password crittografate sono archiviate da qualche parte online.E qualunque cosa sia, è protetta solo dalla password principale stessa o da una seconda password, che l'utente deve ricordare insieme alla password principale (quindi alla fine in pratica solo una password principale più lunga, che quando viene rubataconsente l'accesso a tutte le password)
Ho lanciato il mio gestore di password senza stato (https://vks.ai/ppm) e non ho avuto problemi.Solo il fatto che se davvero la mia password principale sarebbe mai stata compromessa e le persone sono abbastanza esperte di tecnologia da abusarne.Ma questo è un rischio che sono disposto a correre.Affrontare i punti: finora non ho mai avuto problemi in cui il mio metodo non soddisfaceva la politica delle password (e lo sto usando da alcuni anni).La cosa interessante di StackExchange e poi StackExchange2 è che di solito ti ricordi il numero.Ma se non lo fai, puoi facilmente forzarlo entro 3 tentativi (il massimo che ho raggiunto è 5).
@PascalVKooten potresti prendere in considerazione l'idea di restare con uno che ha avuto un controllo adeguato ... con la tua attuale implementazione, le tabelle arcobaleno potrebbero essere impostate su base per sito per decifrare la password principale
@Qwerty01 Sarebbe troppo lento o troppo costoso da decifrare: questa è l'idea di una funzione di hashing lenta come scrypt e una password principale lunga.Questo farà sì che non abbia senso tentare un attacco arcobaleno.
@PascalVKooten Lo scopo di una tabella arcobaleno è eseguire calcoli costosi una volta: l'unica cosa che impedisce ad altri di farlo attualmente è perché la tua implementazione non è abbastanza ampiamente utilizzata per renderla redditizia.
@Qwerty01 Si utilizzano le tabelle arcobaleno solo quando è possibile riutilizzare i calcoli, il che non è il caso qui.Ma nota che le persone non tenteranno di creare tabelle arcobaleno per funzioni di hashing lente in quanto semplicemente non sarebbero convenienti.Sì, l'idea suona alla grande ... riutilizzare i calcoli ... ma le funzioni di hashing lento sono semplicemente troppo costose per farlo (a meno che non si assumano password principali molto brevi).
@PascalVKooten _puoi_ riutilizzarlo con la tua implementazione ... il sale che usi è il nome del sito, quindi chiunque altro utilizzi quel sito avrà lo stesso sale.
@Qwerty01 Sì, ma il sale non è davvero un segreto.Si basa completamente sulla password principale per la sicurezza.Quindi diciamo davvero che conosci il nome del mio sito (e anche tutti gli altri lo usano), devi ancora fare così tanti calcoli costosi che non ne vale la pena.
Cerchiamo di [continuare questa discussione in chat] (https://chat.stackexchange.com/rooms/96816/discussion-between-qwerty01-and-pascalvkooten).
Ri: punto 3, LessPass (un altro gestore di password senza stato) supporta le opzioni che vengono sottoposte ad hashing e utilizzate come parte della generazione;una di queste opzioni è un numero che puoi incrementare.Risolvono il problema del "dover ricordare" permettendoti di mantenere un database di nome utente / sito / opzioni, ma la generazione della password stessa è senza stato e il database è solo una comodità
* "i gestori di password standard richiedono di compromettere sia le password crittografate che la chiave principale." * - Non lo capisco.Sicuramente solo la chiave master deve essere compromessa (più forse qualsiasi MFA), poiché l'utente deve solo inserire la chiave master (+ MFA) per accedere alle password crittografate.Altrimenti sembra che i gestori di password standard che hai utilizzato richiedano all'utente di memorizzare tutte le loro password per accedere alle loro password.O intendevi che l'aggressore deve sia compromettere la chiave principale sia ottenere l'accesso al database?
@8bittree: Se ti dicessi la mia chiave principale, non potresti fare nulla se non hai già accesso al mio database di password crittografate: non puoi decrittare qualcosa che non hai.Ecco perché entrambi sono necessari!
@BenoitEsnard La confusione qui è probabilmente su ciò che costituisce un gestore di password "standard".Potrebbe essere meglio essere più espliciti, ad es."gestore di password basato su file", per distinguerlo da un "gestore di password basato su cloud" come 1Password, dove si accede al database da remoto.
@BenoitEsnard Questo ha più senso.Ho suggerito una modifica che credo renda più chiara la formulazione.
@BenoitEsnard ma la maggior parte delle persone non copia il file dal proprio gestore di password a mano su tutti i dispositivi che stanno utilizzando ogni volta che si registrano per una nuova pagina?Memorizzi il file molto probabilmente da qualche parte online, dove puoi accedervi con la tua password principale.Quindi solo una cosa deve essere compromessa, o hai molti problemi con il trasferimento di file tramite USB.
Sjoerd
2019-07-30 13:04:40 UTC
view on stackexchange narkive permalink

Ecco due problemi menzionati meno spesso.

  • Determinare il sito web è difficile. Desideri utilizzare una password diversa per a.github.io e b.github.io, ma desideri la stessa password per microsoft.com e live.com o wikipedia.org e wikimedia.org.
  • Modificare qualsiasi cosa rompe le password. Una volta che hai rilasciato il tuo gestore di password e le persone iniziano a usarlo, non puoi cambiare nulla al riguardo o gli utenti non possono più accedere. Il modo in cui vengono gestiti i domini deve rimanere lo stesso, anche se i domini cambiano proprietà. Il modo in cui le password vengono sottoposte ad hashing deve rimanere lo stesso, anche quando viene scoperta una vulnerabilità nell'algoritmo.

Vedi anche il mio post sul blog su questo argomento.

Se rilasci una nuova versione opzionale, le persone dovrebbero cambiare le loro password una volta su tutte le pagine per utilizzare la nuova versione.Non sarebbe divertente, ma si potrebbe fare.- Probabilmente farei la stessa cosa se la mia password principale con un gestore di password basato su file fosse compromessa (poiché il file è solitamente accessibile da qualche parte online)
Kolappan N
2019-07-30 08:47:55 UTC
view on stackexchange narkive permalink

1. I gestori di password forniscono opzioni aggiuntive

Una differenza fondamentale tra l'utilizzo di un gestore di password senza stato e un gestore di password è che i gestori di password possono memorizzare dati aggiuntivi come

  • Sicurezza Domande
  • Numeri di carte di credito / debito
  • Numeri di carte d'identità
  • Chiavi crittografiche
  • Password WiFi
  • Chiavi API , ecc ...

2. Le password esistenti non possono essere ospitate

I gestori di password possono ospitare password esistenti. Ma un gestore di password Stateless ti costringerà a cambiare le password per tutti i tuoi siti esistenti.

Questo è molto importante se vuoi memorizzare le password per qualsiasi account in cui non sei autorizzato a cambiare la password. Può essere una casella di posta dell'ufficio condivisa, una password del server, ecc ...

3. I generatori di password deterministici non possono supportare criteri di password variabili.

Alcuni siti avranno bisogno di simboli obbligatori con password, ma alcuni siti non consentono simboli nelle password. Alcuni siti web come Payback supportano solo il PIN numerico.

Gli utenti devono modificare la password generata o modificare le impostazioni. In entrambi i casi, hanno bisogno di mantenere il tweak o le impostazioni in memoria, il che non va bene.

Per il n. 3, è inoltre necessario registrare quale fosse la politica della password quando è stata creata la password.Ho almeno un account in cui la mia password viola la loro nuova politica sulle password, ma quella vecchia è ancora valida.
Daniel Darabos
2019-07-30 20:16:23 UTC
view on stackexchange narkive permalink

Oltre a quelli già menzionati, un altro problema è che non puoi cambiare la tua password principale . Il passaggio a una nuova password principale richiederebbe la modifica della password su tutti i siti web in cui hai utilizzato il generatore.

MechMK1
2019-07-30 00:45:01 UTC
view on stackexchange narkive permalink

Il problema è che non aggiunge molta sicurezza significativa.

Invece di usare direttamente la tua password, usi una funzione disponibile pubblicamente invece della tua password. Usiamo l'esempio sul loro sito web per una dimostrazione:

Accesso: andromeda
Sito web: milkyway.com
Parola chiave segreta: 2,52 m di distanza

Produce la password: 3q_q(MFWaMGeao+[CX

Puoi dire 3q_q (MFWaMGeao + [CX è la tua password, ma in realtà non lo è. In realtà è a 2,52 m di distanza , il che non è molto entropico. È meglio che usare a 2,52 m di distanza ? Sì, ma non così tanto.

Utilizza invece un gestore di password offline e genera una password effettivamente casuale. Si tratta di tanto lavoro da parte tua e ti dà sicurezza molto più reale.

Per essere onesti, "2,52 m di distanza anni luce" da solo non è la tua password.È distante "2,52 m anni luce" più la consapevolezza che utilizzi Getpass.Ammesso che il secondo componente sia abbastanza facile da usare con la forza bruta, poiché è solo un piccolo moltiplicatore del primo (poiché c'è solo una manciata di popolari algoritmi di generazione di password
@Alexander https: // en.wikipedia.org / wiki / Kerckhoffs% 27s_principle
-1 "non ti dà alcuna sicurezza aggiuntiva" non è vero.Le proprietà di sicurezza sono simili e anche leggermente più forti dell'hashing generale sul lato client (che dovrebbe essere fatto comunque da tutto il software).Non è una soluzione perfetta, ma non è nemmeno inutile.
Ti dà una sicurezza extra, a condizione che la tua password principale * sia * molto entropica.Un gestore di password senza stato impedisce la (fin troppo comune) situazione in cui un sito Web che memorizza la password in testo normale viene compromesso e quindi la stessa password viene utilizzata per accedere ad altri siti che frequenti (sì, il riutilizzo della password è dannoso, ma unl'essere umano comune non riesce a ricordare più di 2 o 3 password ad alta entropia).
@Luc Scommetterei che la sicurezza ottenuta utilizzando getpass è significativamente inferiore rispetto all'utilizzo di una password effettivamente casuale.
@James_pic Contrastare il riutilizzo delle password ** è l'intero punto ** dell'utilizzo di un gestore di password.
@MechMK1 sì, e fintanto che la password principale ha abbastanza entropia, un gestore di password senza stato contrasta comunque il riutilizzo della password.
@James_pic Sì e no.Se presumi che una password / passphrase sia abbastanza forte da non essere violabile, allora potresti anche * usare quella password * per tutto e non perdere troppo.Sì, sei in pericolo che i siti web utilizzino password in chiaro, ma queste stanno scomparendo molto rapidamente.Anche i peggiori criminali usano almeno MD5 ora.
@MechMK1 "* Scommetto che la sicurezza ottenuta utilizzando getpass è significativamente inferiore rispetto all'utilizzo di una password effettivamente casuale. *" Questa non è una scommessa, hai semplicemente ragione su questo.Random è chiaramente migliore di derivato.Tuttavia, la parte "non ti dà alcuna sicurezza aggiuntiva" della tua risposta non è corretta, o almeno è più sfumata di così.L'uso della password in testo non crittografato ti impedisce di riutilizzarla.Inviando un hash salato (dove il nome del sito è il sale), hai un token di accesso univoco per ogni sito.Meglio che riutilizzare la password, quindi sicuramente non "nessuna sicurezza aggiunta".
Quindi questa è la mia ragione per il downvoting, sento che è sbagliato al punto da poter essere dannoso.Qualcuno potrebbe non voler utilizzare un gestore di password (per ragioni che esulano dallo scopo di questo commento) ma potrebbe essere d'accordo con un pwdgenerator senza stato.Potresti scoraggiarli e fondamentalmente dire loro di usare invece testi in chiaro.Quindi non è personale, e se la risposta fosse cambiata per riflettere questo (supponendo che tu veda la logica del mio punto), cambierei anche il voto (supponendo di aver visto la modifica).
@Luc Ho cambiato la formulazione per riflettere questo.L'ho affermato come se non aggiungesse molta sicurezza, ma fosse comunque migliore rispetto all'utilizzo di una password a bassa entropia.
Ben
2019-07-31 22:01:44 UTC
view on stackexchange narkive permalink

Un'altra non l'ho vista menzionata esplicitamente (al momento di scrivere tutte le risposte esistenti sono anche valide):

Se un utente malintenzionato si impossessa di una delle tue password generate, ora può provare violare la vostra password principale, ottenendo l'accesso a tutti i vostri account.

È relativamente facile ottenere una password di basso valore, sia tramite phishing, perdite di password in chiaro (anche Google apparentemente non ne è immune), keylogging su un computer pubblico, WiFi aperto su siti che non utilizzano https, ecc. Il punto centrale dell'utilizzo di un gestore di password è che la cattiva sicurezza di un sito non dovrebbe fornire alcun vantaggio in attaccandoti su un altro sito.

Certo, una password principale abbastanza forte può evitare che questo sia un problema. Ma un gestore di password "tradizionale" non ha affatto questo vettore di attacco.

+1 Questo è l'unico svantaggio che conta davvero.Tutti gli altri sono semplici inconvenienti.
Sono sostanzialmente d'accordo, ma ** se ** la password principale è sufficientemente forte _e_ il gestore di password utilizza una buona funzione unidirezionale (idealmente una funzione di hashing della password come scrypt o giù di lì), allora non dovrebbe essere facile / in grado di brutare-vigore.Detto questo, questa è la stessa discussione sul motivo per cui di solito facciamo l'hashing delle password sui server.L'unica differenza è: tu controlli / conosci i fattori che contribuiscono e puoi (teoricamente) stimare se un attacco di forza bruta avrebbe successo.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...