DirectAdmin v1.659

fln said:
old UI were creating an user account with database automatically as well. This user account (that matches DB name) is expected to be used when accessing the DB. Using main DA account and credentials was not a good practice which we are trying to discourage.
Click to expand...
PMA is not the problem. I know the old UI was creating an user too, but we had an option to choose our chosen username and password. In the new UI, there is no option for doing that when creating a db. Need to do extra step to create a new user and assign permission.
 
New UI is designed around the following principles:
  • Each DB should have a separate DB user account. This is to provide a clean separation between different services or domains.
  • Passwords for DB users are not something user need to remember, they need to be auto-generated and added to the website configuration only once.
Of course we still want to be flexible and allow custom / non standard configurations, but currently they require more clicks to achieve.

It would be great if you could share some insight why would you want different DB user names or manually controlled passwords. We could make custom workflow (non standard usernames and manually entered passwords) easier if we get better understanding of motivation why this is needed.
Lets us share the motivation why we want to make custom DB user names or custom passwords more of an exception than a standard way of doing things.

From our experience, using different DB user names (not the same as DB name) most of the time is caused by an attempt to give single DB user access to more than one database. There could be real technical reasons for this, but most of the time this is caused by attempt to have less usernames and password pairs to remember. Again ability for picking a password manually is also more often than not driven by the same goal - trying to have less passwords.

For normal services it is entirely up to the user to choose between auto-generated password or whatever password he wants because he will be entering this password again and again whenever he is using that particular service. For the databases however the situation is very different from normal account passwords. DB passwords are being entered into the website configuration (like Wordpress, Joomla, etc.) and once initial installation/configuration is done password is never needed again. If it is actually needed it can be just picked up from the website config. If website config is not available - user can just create new random password. If he used separate DB user accounts for different DBs changing password of one DB user will not affect his other databases or websites. This makes DB user passwords to be very well suited for being auto-generated.

This might be easy to see for tech savvy users, but for end-users especially not from IT sector when faced with a prompt to enter a password first reaction is to enter the password they will "know" or "remember". Which is a terrible thing to do for databases forcing users down the path of pain:
  • If they use same user/password for multiple DBs it becomes much harder to change the password, because suddenly instead of just re-configuring one of you websites you mush remember to update all the places where this password was used.
  • If main DA user account password was used for DB access it poses a big security risk when user website is compromised. If some attacker got access to the website config, he is now able to gain full control of the user DA account.
To make sure user does not need to remember DB user account passwords having PhpMyAdmin SSO enabled is kind of critical. If user needs to remember something to get access to PMA he will push for allowing him to set a "well known" (for him) password.
 
Everything is much more easier if you flip the situation around. Instead of single DB user account with access to multiple DBs it is much better to have multiple DB users with access to same single DB each dedicated for single DB usage purpose.
@Zhenyapan what strategy do you use to derive the DB username from the database name to make sure they are unique and does not clash? Or do you use single username/password for multiple DB access?
 
I have to do a lot of CMS transfers under different dev- & live-domains. I need to set often the DB PWs which I have already. The old system was perfect, easy and fast. No need to end up with more clicks.
 
fln said:
It would be great if you could share some insight why would you want different DB user names or manually controlled passwords.
Click to expand...
I would start with extra safety. When dbname=dbusername that is already too easy. I don't see the need for automatic creation.
Also if somebody hacked 1 database, they are all hacked when having same username and pass.

Just as it was before was perfect or if a change is required, then better maybe like popup with default credentials as are now, but one has to push a button extra to create of before one pushes that butten, one can change the username and password.

I agree with @johannes and others about this, the old system was perfect.
Don't give up extra safety and ease of use for techs, because some beginner might have a bit more problem's with it. Everybody has to learn. Making it more easy for beginners is not always a good thing.

P.s. how about the list removals issue and the php n suddenly not working anymore?
 
@fln
It's not something to remember, but too easy can be bruteforce easy too.

this how DA generate format "Bu9d4SBBbsQNcJvHfBGV"
it's low secure.

If you want to make easy UI, don't completely remove important thing. Should have option to show them.
 
fln said:
@Zhenyapan what strategy do you use to derive the DB username from the database name to make sure they are unique and does not clash? Or do you use single username/password for multiple DB access?
Click to expand...
usually I have each website in separate account, easier to backup/restore also when hacked due to bad plugins -only one website affected. For DBs - different usernames/dbnames also I always add extra symbols to DB password generated by DA.
 
Richard G said:
Also if somebody hacked 1 database, they are all hacked when having same username and pass.
Click to expand...
Each DB uses different password. Leaking password of one DB does not compromise other DBs. Usernames are not part of the password, and should not be considered to contribute to the security of the system.

jamgames2 said:
it's low secure.
Click to expand...

At the moment DA uses random password generator that ensures ~116 bits of entropy. This is insanely high for passwords, and approaching the limit which is commonly used for crypto systems (128 bits). So guessing DA passwords requires similar amount of attempts to just guessing industry standard AES128 encryption key, which is believed to be not feasible with current technology. When 128 bits limit is reached it is easier to attack the crypto primitives used for password hashing rather than the password itself.

DA password generator picks 20 symbols out of 55 symbols dictionary. It is equivalent to log2(55^20) ~= 116 random bits.

For comparison passwords having 64 bits of entropy are considered safe. Scientists believe there are 7.5 x 10^18 grains of sand on our planet earth. Passwords with 64 bit entropy has more combinations. Using entropy of 128 bits is overkill making it easier to attack other parts of the system. Using higher entropy is just ?‍♂️.

Using passwords with all possible symbols also comes with some hidden costs:
  • If passwords contains special symbols like quotes are hard to enter into the application source code as quotes are usually used to enclose the password string. When passwords contain such symbols user needs to additionally escape them with backslashes making the real password and password entered into PHP source file to not be the same.
  • If password contains backslashes adding them directly to the source code might cause problems as well as symbols after \ can be interpreted as escape sequence by the programming language. So backslashes needs to be escaped with additional backlashes.
  • Some applications also require special escaping of other symbols, for example ! and $ in bash, golang uses DB connector DSNs which use @ and : symbols.
  • Double clicking a password with special symbols usually selects just the part of the password up to the first symbol making it harder to select for copying.
  • Passwords that include similar looking symbols can be error prone when being entered manually, for example "Il" are two different characters, one is capital i and other is lowercase L
That is why we specifically tuned our password generator to make sure that our generated passwords are easy to work with but at the same time strong to the point that it makes no sense making them longer. So what they lack in special symbols they make up by being longer. If we included all the symbols we could achieve our target entropy with shorted passwords, but passwords would be less convenient to work with.

Hope this gives you more insight why DA auto-generated passwords are in this specific format. And ensure you there is not much value in changing them after they were generated.
Still there could be some other reasons for using custom password. We might consider making it easier to use not auto-generated password. But strength of the password is not one of them.
 
Zhenyapan said:
usually I have each website in separate account, easier to backup/restore also when hacked due to bad plugins -only one website affected.
Click to expand...
This is exactly what the DB system does by default. It creates a new user account for each DB for exactly this reason. The DB name and user name are the same to make it easier to work with. Using different user names does not make the system more secure - unless same password is being used, which we are trying to prevent by auto-generating password by default.
 
I am not sure if there is still misunderstanding or something else, but @fln is focusing on one user for one db, which is NOT in my question. My request is letting us to choose the username, please do not automatically create an username with the same name with db name.
fln said:
Using different user names does not make the system more secure
Click to expand...
It does. I don't know how it is now, but in the old days, with cPanel, when creating an account, the default name was first 8 characters of the domain. I really hated it. And nowadays, dictionary attacks happen all the time. It seems much more easier to run scripts with that purpose. So, using different names for user and db, it helps to make the system more secure. Thanks for explanation about password generator, its purpose is making a hard-enough password for avoiding guessing / dictionary attacks, is that correct?

I don't know about others, but when I create a db, I usually choose a random name, combining lowercase, uppercase and numbers, it's not something that is easy to remember. Then I need to copy the names to the application. That means I will copy the names and password anyway in the old or the new UI. That's why I would do copy twice, one for user, one for db, rather than using the same name for user and db. It does make the system more secure when the system is under dictionary attacks.

About one user for one db, again, you just make it more complicated for end users. Right now, if they want, they can still assign one user for all DBs with full access. So, the goal of one user for one db is not completed yet, while you have already removed option for us to choose our own username and password.
 
gate2vn said:
So, using different names for user and db, it helps to make the system more secure.
Click to expand...
It seems you are trying to use DB username for the purpose of what password is supposed to do.

If password is weak, then randomly generated user name could be considered an extension to the password (since you have to guess both username and password). If password is strong, it is perfectly fine for the username to be predictable. Same goes for DB names. For auto-generated names one would have to guess all three components, DB name, DB user, and user password.

Storing secrets in usernames or DB names is not a great strategy since it is usually much easier to reveal it than to reveal password. For example depending on website configuration, if DB error is encountered it might just show the username and DB name which was used to attempt connecting to DB. While passwords are not usually leaked into logs and error messages since everyone know they are supposed to be sensitive information.

It is much easier if you just use most meaningful DB name (and username), for example your domain and then use auto-generated password for protection.

For example all Linux systems does have `root` user account. Would you rather rename your `root` account or use strong password for it? Using random names just makes it much more harder to use since there is one more thing to know/remember/configure.
Thanks for the feedback @johannes, @jamgames2, @Zhenyapan, @gate2vn. We will search for ways to make it easier to use non-standard flow and provide custom DB user name and custom password.
 
About password with special characters, if I am correctly, when putting the password inside double-quotes, it will be read as a normal string. So, if you can generate a password without double-quotes, it would be fine. Something likes m8S&h<DG2jS?1h=MDj1. If there is any special app which is not allowing these special characters, then the owner can create another password. But I don't know if there are many apps like that?
 
fln said:
It seems you are trying to use DB username for the purpose of what password is supposed to do.
Click to expand...
Well... let's not assume what each other is trying to do :) Assumption can lead to many misunderstandings and we will need to write back and forth. My idea is just to make more secure system, and my feeling is that the old way is better than the new one. You have done an extra step with password generator, but if you can bring the old way with username, it would be great. Thank you.
 
fln said:
Would you rather rename your `root` account or use strong password for it?
Click to expand...
In DA the main account is admin and there are lots of users changing the admin name to another name. Less bruteforces, no matter what the password is. Even with root, there are several options that users can not try to login as root, for this reason. Like disable root login, use ssh keys and such things.
I understand the password idea and that it should be secure enough, but we could change the name before too.

So I agree with @gate2vn with bringing back the old way with username or like the suggestion of @ericosman to make it a switchable option.
Due to you answer in #74 it seems you are going to look for some solution so thats fine with me then too.

I would still like to know from post #56 if this is a bug, or confirmation if it's investigated. It seems to have slipped attention due to the database discussion.
 
@Richard G, the extra n parameter does nothing, and it stopped working once da build php command was updated to accept optional PHP version.

Thanks for pointing removals list not showing PHP versions. This is confirmed regression and will be fixed in next release.
 
In my previous post about password strengths I have made a claim that 116 bits of entropy we use in random passwords is insanely high. Here is a more practical approach to illustrate its strength.

Connection to DB to check if password is valid takes ~0.5 millisecond. Lets assume we have sci-fi super-computers and are able to check if password is valid 500 000 times faster. It would be password check in 1 nano second (roughly being able to tell if password is valid in 3-5 CPU cycles):
  • On average to brute force DA generated password one would need to try half the combinations, it is (55^20) / 2 = 3.207921958×10³⁴ attempts.
  • With our hypothetical super computer in one year we can check: 1 year * 365 days * 24 hours * 60 minutes * 60 seconds * 1000 milliseconds * 1000 microseconds * 1000 nanoseconds = 3.1536×10¹⁶ password combinations.
  • So brute-forcing single password would take (3.207921958×10³⁴) / (3.1536×10¹⁶) = 1 017 225 380 000 000 000 years to finish.
  • In about 4 500 000 000 years our sun will die.
  • Our universe to his day is 13 800 000 000 years old (time since big bang).
  • Time to brute force the password on our sci-fi computer is 7 3711 984 times longer than the age of the universe as we know it.
I hope these calculations are more relatable then the grains of sand example. There is no practical need to change auto-generated password to make it stronger.
 
You must log in or register to reply here.
Back
Top