Database Naming Best Practices

Cableguy

Cableguy

Expert
Licensed User
Longtime User
Hi guys,

Since this topic i way too wide and not platform specific, I'm posting it here.

I need to create a "remote" Database, that will sit in my VPS, which is almost unused at the moment.
So the question popped up :
What is the best naming practice in order to not make it too easy for hackers to find it?
I've been searching about this all over but i find is Database structure naming best practices...
What I'm asking is for best practices in naming the DB itself!

Thanks in advance
 
I don't think you should be bothered about this. Instead, I advise you delete the default user in MYSQL and create a new user with restricted access to the database and use a hard enough password for this user then if you access the database from your laptop and you have a static IP you can restrict that user access to just your IP address.
 
FrostCodes said:
I don't think you should be bothered about this. Instead, I advise you delete the default user in MYSQL and create a new user with restricted access to the database and use a hard enough password for this user then if you access the database from your laptop and you have a static IP you can restrict that user access to just your IP address.
Click to expand...
I understand that, but this BD is to be used in a "comunity" app I'm designing, along with a "in the device" local DB...
Since my experience with DB is very limited, specially security wise, I was just wondering...
To my knowleadge, any DB can be brute forced open, with enough time... So my aim is to make my DB just as "unspecific" as possible in its naming.
 
Cableguy said:
I understand that, but this BD is to be used in a "comunity" app I'm designing, along with a "in the device" local DB...
Since my experience with DB is very limited, specially security wise, I was just wondering...
To my knowleadge, any DB can be brute forced open, with enough time... So my aim is to make my DB just as "unspecific" as possible in its naming.
Click to expand...

I am not familiar with mysql db but I am not sure also you are referring in a mysql db. For the SQL Server that I know of and .NET backend in order for an SQL Server to be brute force attacked the hacker has to know both the address of the server and the username or JUST figure out a way to download your web.config file (in .NET). Therefore it is a good practice to encrypt in .NET the connectionstring. I would be completely surprised if there is not something similar in PHP if you are reffering to PHP+MySQL as backend. What I do even more is that I never use in line query with user inserted data in order to avoid SQL Injection (instead I use parameters). A third measure is to make the life of a hacker a hell by inserting an X seconds sleep in thread if it sends a wrong username password values for the backend which means kiss fast responses necessary for attacks good bye. Also a good measure would be to keep the IPs of the users that send wrong credentials or tamper with your backend code and if within the Y last minutes do that a couple of times then disable their access to all the code executed by returning an empty string. This will also torture the hacker which will be forced to change IPs continuesly every Y tries.
 
Last edited:
Cableguy said:
I understand that, but this BD is to be used in a "comunity" app I'm designing, along with a "in the device" local DB...
Since my experience with DB is very limited, specially security wise, I was just wondering...
To my knowleadge, any DB can be brute forced open, with enough time... So my aim is to make my DB just as "unspecific" as possible in its naming.
Click to expand...

You can try an create an API where you can rate-limit the DB access or in the MYSQL manager, you can set this rate limit directly.
And you make sure no one can access the database without the API so that way it runs only locally.

This is just my thoughts on how I would have gone about it :)
 
Last edited:
JA, Hmmm, @hatzisn

Has few strategies there. If you're running a server then you will already appreciate that its about keeping the hacker out of the house, not what number room your lunch is in.

So, I wouldn't worry about what the DB is called (give a randomised 128-bit word for all it matters). Best practice lies at another level.

Of course if it involves PHP make sure that the scripts' folders are secure. @hatzisn doesn't seem to mention firewall rules. I've used the IP capture strategy before that restricted access to within a limited IP range (but that's from PHP and works in browser limitation mode obviously.

But, naming was about convention rather than "best practice" - which I've never seen listed as an relevant issue - well, just never seen it mentioned, full-stop. (but, then, I don't read much.)

Cableguy said:
along with a "in the device" local DB...
Click to expand...
I guess this means SQLite? on the phone. So if there is a TX between the server and the phone that represents a transmission interception risk point. That's a different debate. [[start a new thread ?]]

I guess best practice involves naming things so that you remember that name in six months time - when the maintenance headache hits you.
 
You must log in or register to reply here.
Back
Top