2

Seems like a trivial question, but I couldn't find other questions that address the following.

So I'm simply asking, how strong would my (super user) database credentials ideally be? I simply figured out, that since all of my connections are done through my app server script files, why shouldn't I just generate a random 40 letters string and use it hard-coded in my script files as a password? The only backside is that if it gets lost somehow then I'll be left with no access to my db. However, it is an option and since I've never seen anyone else mentions it, what is your opinions about it? And if it's not a wise decision, how strong should my db password be?

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?

FLUSHER
  • 373
  • 1
  • 2
  • 6
  • 5
    Hard-coding a password into anything is what we call a "bad idea". Irrespective of how complex the password is, all that someone needs to do is get hold of your script file and they have the password. – baldPrussian Dec 17 '17 at 01:31
  • 2
    The password should be "as strong as possible". At least 128 bits of security is always a good idea. Do you have root on the system where the DB is running? If so, you can always reset the password if you lose it. Just set a nice strong password, keep it in a read-only file or a password manager, and forget about it. Why are you having your scripts connect with a privileged database account, though? – forest Dec 17 '17 at 01:34
  • @baldPrussian I may be lacking knowledge here, but if I need to have my website server run queries against my database server, How can I establish the connection first to the database from the script file without having the password in it? Is there any other way to do it? – FLUSHER Dec 17 '17 at 01:43
  • 1
    @sermonionx I believe you can use public key authentication for connecting to many popular databases, though I'm not a DBA, so I can't say if that's best practice compared to some alternative. Much better than hardcoding your passwords in some script. – forest Dec 17 '17 at 01:46
  • @forest Because I need to perform queries against it.. Is there another way? It's a web server (to your first comment) – FLUSHER Dec 17 '17 at 01:47
  • @sermonionx https://www.postgresql.org/docs/current/static/auth-methods.html – forest Dec 17 '17 at 03:11
  • I think your question might be better answered with more specific information, e.g. SQL Server, or MySQL. Different environments handle things differently. As baldPrussion says, the best strategy is to avoid storing the password altogether. In a SQL Server environment this is possible by using the AD credentials of the person or web server making the connection, so you can avoid having to put the password in a config file. Similarly in AWS EC2 instances you can pass sensitive info to the instance. Adding more specifics might help here. – Darren Dec 17 '17 at 03:14
  • Another common theme I see is a belief of forgetting passwords and to that end I might suggest using a 15+ character password consisting of 4 words in order to make things easier while increasing difficulty to crack, If you need to store passwords though best practice is to keep them away from the machine such as pen and paper in a safe place. –  Dec 17 '17 at 05:16
  • @Darren He specified the SQL server he was using. Check the tags. – forest Dec 17 '17 at 05:22

3 Answers3

2

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

Maximum strength. Based on this answer, a length 100 cryptographically random password with upper, lower, numbers, symbols fits that.

Store it in KeePass or similar.

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. You SHOULD NOT be using that super user account for ANY scripts; you FIRST need to create different user accounts for them, with minimal permissions - and those cryptographically random 40 character upper, lower, number passwords are then pretty good (skip symbols, length trumps character set size, and 40+ is good)

Then, if you can, store them encrypted - openssl can be used in scripts to decrypt on the fly, even if you have nothing else.

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

False. One, that super user password is for emergencies; have your own account as well (for auditability. Two, your scripts use their own less permissioned usernames; those still run. Three, with physical access to the machine, you can always recover and/or reset the super user password - it just takes some work.

Four, it's in your KeePass. Remember?

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?

You remember your very strong personal credential to get into your KeePass, and then copy/paste (or use the awesome autotype feature) the unique, per-username*server password in as required.

Big, highly secure organizations? They use a hardware security module (HSM). Break out your checkbook.

Anti-weakpasswords
  • 9,785
  • 2
  • 23
  • 51
1

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

As strong as possible. Use random passwords as long and as with as many different characters as the database will let you. Do not try to remember them. If you pick passwords that you can easily remember, they are probably to weak.

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

Where and how to store passwords that your script needs access to is a big question. Putting them right in your script files is not the best solution. See this question for a longer discussion.

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

Using different passwords is better in general. Since we have already established that you won't be able to memorize them anyway the added burden isn't that big.

Anders
  • 64,406
  • 24
  • 178
  • 215
0

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

In this context I find it more relevant to how you manage your passwords and secrets. You should ideally set an as strong (and unique) passphrase as possible. With that said, you can reach a high level of entropy by just concatinating words together.

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

That is a viable solution if you make sure that there is unique accounts (not superuser) to your individual scripts, with the principle of least privilege. You should not give more privileges than needed for your scripts to run without permission constraints.

What is really important here is to ensure that they are protected properly if stored in a repository for instance. I'd look at StackExchange's blackbox, or vault from Hashicorp.

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

If you can implement 2-factor authentication for your superuser, any other accounts intended for manual access this becomes less of a concern. This would mitigate many, if not all of the attack vectors you're concerned about. I haven't done this myself for PostgreSQL in particular but there is some write-ups on it online.

See "One-time passwords with Google Authenticator PAM (and friends)".

Anders
  • 64,406
  • 24
  • 178
  • 215
William Sandin
  • 336
  • 1
  • 6