Quanto è sicura la derivazione della chiave basata su password in caso di password lunga?

The problem in password based key derivation (PBKD) is that the attacker can guess the password if that password is from user. But in my case I am using some long system based number (not from user) as a passphrase. Is this a right way?

Una password è "una chiave segreta che si adatta al cervello dell'utente". L'attributo principale di una chiave segreta è la sua segretezza, che è una misura di quanti attaccanti non lo sanno. In generale, gli aggressori sono (presumibilmente) super-intelligenti, quindi l'unica cosa che non sanno è pura casualità.

Il problema principale con le password è che i cervelli umani non sono bravi a memorizzare la casualità (sono anche molto poveri nel produrre casualità). Questo è ciò che rende deboli le password: gli utenti malintenzionati possono provare a trovare la password attraverso "indovinare", che in pratica significa provare tutte le combinazioni di casualità compatibile con gli umani.

PBKDF2, come altre funzioni di hashing della password , è pensato per rendere più tollerabile la debolezza delle password, rendendo ogni ipotesi più costosa (sia per l'attaccante che per l'utente normale).

Se, nella tua applicazione, la password non è realmente inserita da un utente ma da una macchina, allora puoi usare una "password" con molta casualità (le macchine sono molto meglio degli umani nel ricordare lunghe sequenze di numeri casuali ), a questo punto l'hashing della password potrebbe diventare abbastanza inutile.

Does modifying the encryption key in my code (say like left shifting or right shifting the key) help in security?

Ti aiuta tanto a ballare con una teiera in testa mentre intonando la gloria di Huitzilopochtli ti aiuterà a indovinare i prossimi numeri della lotteria vincente.

(Se Huitzilopochtli è davvero divertito dal tuo rituale, può darti dei benefici, ma non è conosciuto per il suo senso dell'umorismo.)

How about storing the salt in the code (hard coding)?

Il sale ha senso in combinazione con l'hashing della password: è uno dei metodi con cui le password (che sono intrinsecamente deboli, vedi sopra) possono essere tollerate. Se le tue "password" non sono realmente password, l'hashing della password e il sale sono irrilevanti.

Viceversa, quando salt è rilevante, il suo punto principale e unico non deve mai essere riutilizzato: il codice salato nel codice fa esattamente l'opposto.

Quindi, si può dire che l'hardcoding di un valore salt è una cattiva idea o una cattiva idea very , a seconda del contesto.

ricorda che la sicurezza fisica è importante quanto la logica, se il tuo hardware è relativamente sicuro (o pesante) e sei preoccupato che il disco rigido venga rubato e decifrato quindi usi informazioni hardware come numeri seriali (almeno 2 di loro - che credo lo stai già facendo) in questo modo l'unità non può essere decifrata senza essere nell'hardware giusto ..

per quanto riguarda i livelli e i sali extra, assicurati solo di nascondere gli script di crittografia e decrittografia e un sale codificato dovrebbe andare bene.

Ovviamente non sono al 100% sul tuo scenario, ma a seconda di come funzioni la crittografia, la decifrazione, ecc. dipende da cosa sarebbe un sale praticabile, se puoi rendere dinamico il sale in ogni file, in particolare, ciò significherebbe che anche se hanno rubato l'hardware e hanno indovinato 1 file, non sarebbero stati in grado di decodificare il resto dei file.

Potrei essere in grado di darti alcuni suggerimenti se conoscessi i dettagli dello scenario, ma a volte non dovresti condividere alcune informazioni (ingegneria sociale)

Spero che questo accenda alcune idee.

Un KDF per rafforzare la password è necessario solo se la password stessa potrebbe essere debole. L'esempio principale è quando un essere umano lo ha generato.

Un KDF eseguirà l'hash della password un certo numero di volte. Ciò significa che un utente malintenzionato che ottiene l'accesso agli hash delle password dovrà iterare ogni password per indovinare quel numero di volte, rallentando il loro attacco. Questo ha lo stesso effetto di una password sicura senza KDF. Questo perché lo spazio per le chiavi aggiuntivo che una password con una maggiore entropia avrebbe può avere iterazioni di hash extra sostituite per tenere conto del tempo necessario per interrompere.

Pertanto, una password generata dal computer non ha bisogno di un KDF per allungamento della chiave perché può semplicemente generare una chiave con abbastanza forza da solo. Vai per 128 bit di entropia se possibile, generato da un generatore di numeri casuali crittograficamente sicuro (CSPRNG).

Per quanto riguarda il sale, non ne hai bisogno. 128 bit sarebbero sufficienti per proteggere la password dagli attacchi di hashing intrinsecamente. Le tabelle Rainbow per coprire l'intero spazio delle chiavi a 128 bit sarebbero eccessivamente grandi.

Quando dici "numero basato su sistema lungo", cosa intendi esattamente? Se l'unico input per la tua funzione di generazione di chiavi è una costante statica memorizzata sulla macchina, la tua crittografia non farà nulla contro un utente malintenzionato che ha accesso ad essa. Tuttavia, impedirà loro di sollevare dati e decrittografarli su una macchina diversa.

La generazione di una chiave basata su una password fornita dall'utente garantisce che l'autore dell'attacco richieda informazioni esterne per estrarre i dati dal dispositivo. Ovviamente, questo significa che l'utente deve scegliere una password buona , ma direi che è più intelligente della memorizzazione della password sulla macchina stessa! Se la password è ben scelta (ad esempio una passphrase lunga), l'attaccante non avrà alcuna possibilità di indovinarlo in un migliaio di anni.

La scelta della sorgente chiave dipenderà dal tuo caso d'uso. Potresti anche optare per una combinazione dei due (ad esempio, Windows offre un servizio di crittografia che si basa su un chip di sicurezza nell'hardware e sulla password dell'utente).

I sali vengono utilizzati per rendere più difficile l'attacco dei segreti hash con le tabelle hash pre-calcolate. L'applicazione più comune è l'archiviazione delle password. Se un utente malintenzionato può preparare un ampio elenco di password comuni e i relativi hash, può facilmente cercare gli hash delle password per trovare equivalenti in chiaro. Aggiungendo un salato alla password e tagliando il risultato, ciò rende molto più difficile.

Non vedo come i sali siano applicabili qui, però. crittografa una grande quantità di dati, non l'hashing . Non c'è alcun modo in cui un utente malintenzionato sta costruendo una tabella con ogni possibile file e ogni possibile versione crittografata di esso.

Inoltre ... i sali non sono segreti, dal momento che devono essere disponibili per accedere ai segreti! Potresti riuscire a offuscare i sali (utilizzando nomi di file, ad esempio), ma ricordiamoci la regola d'oro della sicurezza:

La sicurezza attraverso l'oscurità non è sicurezza . Supponiamo che l'autore dell'attacco sappia tutto tranne la chiave.

Questo vale anche per alcune delle altre cose che hai portato in primo piano - fare casini casuali con le funzioni di crittografia non ti farà bene.

Costruisci un sistema robusto, non uno scadente.