algoritmo di generazione della password

La risposta breve è No .

Questo è un classico esempio di Sicurezza attraverso l'oscurità che, sebbene possa funzionare, a volte è considerato una cattiva idea perché non è mai funziona a lungo termine.

Come nella mia risposta alle altre domande si tratta di modeling delle minacce . Considera i seguenti due scenari.

1) Gli utenti malintenzionati hanno scaricato un database di nomi utente e password con tutte le password memorizzate come hash SHA1. Usano tabelle arcobaleno o un dizionario di password comuni e cercano di infrangere le password deboli.

Il tuo sistema è più sicuro? Sì , è improbabile che csbthaapolteotrerrryseect sia in un dizionario delle password.

2) Gli aggressori hanno scaricato un database di nomi utente e password con tutte le password memorizzate come hash SHA1. Hanno come target tu e conosci la tua funzione, o forse la tua funzione diventa selvaggiamente popolare (come quella di xkcd) in modo che gli aggressori eseguano la tua funzione sul loro dizionario.

Il tuo sistema è ancora più sicuro? No le persone cercheranno csbthaapolteotrerrryseect e password simili.

Il principio di Kerckhoffs è spesso usato in crittografia e afferma che

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Questa è una grande aspirazione e viene usata nel fumetto di xkcd. Anche se sai tutto su come genero le password (incluso l'elenco di parole che uso) ci sono ancora 2 ^ 44 possibili password. Inoltre, l'enorme vantaggio dello stile xkcd è che è facile da ricordare e digitare.

a function that only you knew

Beh, una tale bestia non esiste davvero. Anche se riesci a formulare una procedura di "miscelazione" che risiede solo nel tuo cervello, è abbastanza difficile quantificare quanto la procedura è sconosciuta all'attaccante. Se la suddetta funzione esiste come script o file eseguibile da qualche parte, o come descrizione testuale su qualche post di blog o documento politico per gli utenti, allora è straordinariamente ottimista credere che l'autore dell'attacco non lo sappia.

Una parte importante della sicurezza delle password, anche di sicurezza in generale, è quella di sapere che tipo di "sicurezza" si ottiene effettivamente. Ciò significa misure, metriche ... Hai bisogno di queste informazioni perché è l'unico modo per sapere se i controlli di sicurezza valgono lo sforzo. Ad esempio, una password implica costi, in particolare il tempo speso dall'utente per digitare effettivamente quella password. In un contesto aziendale, i costi si traducono in denaro; ma anche per i privati esistono dei costi (ad es. come tempo trascorso, o come esasperazione accumulata dal software stupido). La tua "funzione privata" dovrà essere eseguita nella tua testa regolarmente. Il guadagno in sicurezza sarà sufficiente a compensare lo sforzo extra? Per rispondere a questa domanda, devi sapere che "guadagno in sicurezza" ... e con una "funzione privata", è praticamente impossibile.

L'intero punto di < i calcoli di> entropia indicano una misura di sicurezza valida, matematica e affidabile. L'unico modo corretto per calcolare le entropie è presumere che l'attaccante conosca tutto la cui riservatezza non può essere quantificata. Fondamentalmente, non possiamo misurare ragionevolmente quanto una funzione privata sia privata; per una parola selezionata casualmente in una lista specifica, sappiamo quanto è sconosciuto all'attaccante: l'attaccante conosce l'elenco, non l'indice selezionato casualmente.

Esiste una tradizione diffusa di generare password accumulando operazioni semi-magiche che si presume siano "sicure". Ad esempio, le persone aggiungeranno dei segni di punteggiatura perché credono che un '$' o un ';' ha qualche "sicurezza intrinseca" che è più alta di quella di una "A" o di una "k". Questo si riferisce alla nozione di sicurezza come una sorta di merce che si accumula. Questo è, ovviamente, un modo molto povero di pensare alla sicurezza. Ciò equivarrebbe a garantire la sicurezza di un server Web contro gli attacchi online mantenendo una guardia armata nella stanza del server - e quindi procedendo a "raddoppiare la sicurezza" aggiungendo un'altra guardia. Sarebbe ridicolo, ma quando si tratta di password la maggior parte delle persone è ridicola.

Quindi, sii intelligente: non fare affidamento su rituali i cui benefici non possono essere misurati o addirittura stimati numericamente.

Da un punto di vista crittografico la gente ti dirà che è sbagliato farlo. Non è certamente "più" o "ugualmente" sicuro, ma penso che sia abbastanza sicuro.

Dal punto di vista pratico, per le tue password personali, non è sempre possibile ricordare password come A4q!qtrqFET4KmpVW.?T5"r'&141EFQFSq . Se costringi le persone a farlo comunque, finirai con foglietti o foglietti attaccati a uno schermo. Si può sostenere che mantenere le password su una nota nel tuo portafoglio può essere considerato anche sicuro (non scrivere solo nomi utente e per cosa li usi).

È importante mantenere il tuo sistema segreto e non usarlo eccessivamente, forse solo per quelle password che usi frequentemente. Se puoi, dovresti usare un gestore di password. Non dovresti usarlo per gli account tecnici.

Altri hanno affrontato il fatto che stai violando il Principio di Kerckhoffs. Vorrei suggerire un modo per riformulare la proposta che non lo fa.

Rendi la tua funzione parte della chiave

Se trattiamo la tua "funzione che conosci solo tu" come parte della "chiave", allora non è una violazione del Principio di Kerckhoffs. Cioè, prendiamo la tua "chiave" per avere due parti. La passphrase di input, p e la funzione segreta, f .

La tua funzione è deducibile dal suo output?

Hai intenzione di memorizzare sia p che f ? Probabilmente. Utilizzerai un p e f univoco per ciascun servizio che utilizzi? Probabilmente no.

Cioè, mi aspetto che tu sia tentato di cambiare solo p per diversi casi mentre riusciamo lo stesso f . Questo può essere reso sicuro, ma ciò che descrivi con il tuo esempio non lo è. Questo perché se un utente malintenzionato riceve una coppia di password derivate, ad esempio f ("correcthorse") ed f ("batterystaple"), sarà in grado di capire che cosa è f .

Correggi rendendo la tua funzione una funzione pseudo-casuale

Quindi, se vuoi farlo, avrai bisogno di un f che non sia deducibile dall'hacker che ha n della tua password derivata, f ( p1 ) ... f ( pn ). Ci sono funzioni crittografiche che faranno questo per te. HMAC è ciò che viene subito in mente.

Lascia che f (p) = HMAC ("qualche costante segreto solo tu sai", p)

In questo modo, un utente malintenzionato che diventava vecchio di f (p) avrebbe avuto difficoltà a cercare di scoprire il segreto costante, in particolare se non conosceva p .

Problemi di codifica

Si noti che l'output di f (p) non sarà testo ASCII. Quindi dovresti trasformarlo in qualcosa di usabile come password dove ti serve. È difficile farlo in generale. Ad esempio, se hai usato la codifica base64, dovresti assicurarti che il posto in cui stai utilizzando la password generata accetti tutti i simboli che possono apparire in base64. Allo stesso modo, se utilizzi una rappresentazione esadecimale, potresti non ottenere tutti i "simboli" che alcuni servizi potrebbero richiedere per una password.

Sono questi problemi di codifica il motivo per cui questo sistema non funzionerà come schema generale. Può essere usato e quindi manualmente aggiustato caso per caso, ma ciò significa che puoi usarlo solo per un paio di casi.