Quanto deve essere strong la password di un database?

Question

Quanto deve essere strong la password di un database?

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Sembra una domanda banale, ma non sono riuscito a trovare altre domande che rispondessero a quanto segue.

Quindi mi sto semplicemente chiedendo, quanto sarebbero forti le mie credenziali di database (super user) idealmente ? Ho semplicemente capito, dal momento che tutte le mie connessioni sono fatte attraverso i miei file di script del server delle app, perché non dovrei semplicemente generare una stringa casuale di 40 lettere e usarla come codice hard nei miei file di script come password? L'unico vantaggio è che se si perde in qualche modo poi mi verrà lasciato senza accesso al mio db. Tuttavia, è un'opzione e dato che non ho mai visto nessuno menzionarlo, quali sono le tue opinioni al riguardo? E se non è una decisione saggia, quanto dovrebbe essere strong la mia password db?

E se utilizzo 3 server di database, di cui 2 sono semplicemente backup, potrei, come best practice, ricordare le credenziali di tutti loro? Usare la stessa password sembra pericoloso se la mia preoccupazione sono gli hacker. Come si comportano le grandi aziende?

passwords postgresql tls databases

posta sermonion x 17.12.2017 - 02:17

fonte

3 risposte

Leggi altre domande sui tag passwords postgresql tls databases

Come verificare se il client SSH non sta registrando i miei dati di accesso? Come fa una telefonata / un messaggio SMS a verificare la mia identità

score 1 · Answer 1

So I'm simply asking, how strong would my (super user) database credentials ideally be?

Il più strong possibile. Usa password casuali il più a lungo e con tanti caratteri diversi come il database ti lascerà. Non cercare di ricordarli. Se scegli password che puoi facilmente ricordare, probabilmente sono deboli.

...use it hard-coded in my script files as a password?

Dove e come memorizzare le password a cui il tuo script ha bisogno di accedere è una grande domanda. Inserirli nei file di script non è la soluzione migliore. Vedi questa domanda per una discussione più lunga.

Using the same password seems dangerous if my concern is hackers.

L'uso di password diverse è in generale migliore. Dal momento che abbiamo già stabilito che non sarai in grado di memorizzarli comunque, l'onere aggiunto non è così grande.

score 1 · Answer 2

So I'm simply asking, how strong would my (super user) database credentials ideally be?

Forza massima. In base a questa risposta , una password di lunghezza 100 crittograficamente casuale con simboli in alto, in basso, numerati, si adatta a questo.

Conservalo in KeePass o simile.

why shouldn't I just generate a random 40 letters string and use it hard-coded in my script files as a password?

Whoa, there, Tex. NON DOVRESTI utilizzare questo account superutente per QUALSIASI script; È necessario innanzitutto creare account utente diversi per loro, con autorizzazioni minime e quelle password crittografiche 40 caratteri superiori e inferiori sono quindi abbastanza buone (salta i simboli, lunghezza supera la dimensione del set di caratteri e 40+ è buona)

Quindi, se possibile, memorizzali crittografati - openssl può essere utilizzato negli script per decodificare al volo, anche se non hai nient'altro.

The only backside is that if it gets lost somehow then I'll be left with no access to my db.

False. Uno, quella super user password è per le emergenze; hanno anche il tuo account personale (per la controllabilità.) Due script usano i loro nomi utente meno autorizzati, quelli ancora in esecuzione. Tre, con accesso fisico alla macchina, puoi sempre recuperare e / o resettare la password del superutente un po 'di lavoro.

Quattro, sono nel KeePass . Ricordate?

And if I use 3 database servers, where 2 of them are simply backups, would I, as best practice, remember the credentials of them all? Using the same password seems dangerous if my concern is hackers. How do big companies deal with it?

Ti ricordi le tue credenziali personali molto forti per accedere al KeePass , quindi copiare / incollare (o utilizzare la fantastica funzionalità di autotype) l'unico , per-username * password del server come richiesto.

Organizzazioni grandi e altamente sicure? Usano un modulo di sicurezza hardware (HSM). Estrai il libretto degli assegni.

score 0 · Answer 3

So I'm simply asking, how strong would my (super user) database credentials ideally be?

In questo contesto trovo più rilevante il modo in cui gestisci le tue password e i tuoi segreti. Dovresti idealmente impostare una passphrase più strong (e unica) possibile. Detto questo, puoi raggiungere un alto livello di entropia semplicemente conciliando le parole insieme.

...use it hard-coded in my script files as a password?

Questa è una soluzione praticabile se ci si assicura che esistano account univoci (non superuser) per i propri script individuali, con il principio del minimo privilegio. Non dovresti concedere più privilegi del necessario per l'esecuzione degli script senza vincoli di autorizzazione.

Ciò che è veramente importante qui è assicurarsi che siano protetti correttamente se memorizzati in un repository, per esempio. Guarderei la scatola nera di StackExchange, o vault di Hashicorp.

Using the same password seems dangerous if my concern is hackers.

Se puoi implementare l'autenticazione a 2 fattori per il tuo superutente, qualsiasi altro account destinato all'accesso manuale diventa meno preoccupante. Questo attenuerebbe molti, se non tutti i vettori di attacco di cui ti preoccupi. Non l'ho fatto io per PostgreSQL in particolare, ma ci sono alcuni articoli su questo in linea.

Vedi "Password una tantum con Google Authenticator PAM (e amici)" .