I want to build a VB.NET application that will connect to a MySQL database.
I was thinking of putting the MySQL password on the My.Setting file, but that's easy to read. Which would be the safest way to put the password on the program?
I don't want to ask for it on start-up, I want it to be embedded on the software, but WHERE?
Wellll..... If it's stored in an automatically program-readable format (aka, the user doesn't have to enter any kind of password or credential to enable the application to make use of said database password), then there isn't exactly a "safe" way since any kind of meaningful encryption requires that the user enter some credential to retrieve the encrypted information. You could store it in a module as Base64 text for obfuscation, but that's not really "safe." At all. It's just encoded differently (NOT encrypted).
The bigger question to me is, is the environment safe? On the back end of a website for example, the password for sql databases is usually stored in-the-clear in the php config files... but that's because the environment is secure: php source cannot be obtained by the public, and trusted users with access to the backend are assumed to be non-malicious.
So, that raises some questions:
Where is the application running from?
Where is the MySQL Database, local or remote?
How many people have access to this database or will be using this app?
These are all considerations that should be accounted for.
One other thing - if you're building a .NET application, there are certain .NET code-obfuscators out there that play with your compiled code to make it quite difficult to pillage once compiled. This may be of interest to you. I believe Dotfuscator ships standard with Visual Studio? You can register for a free account with them.
Related
Guys I'm working on a local system project where I'd use Microsoft access as the database storage.
This application may be distributed among several users with different access layer control.
The direct method to secure the database from manual update is to put a password lock, however I came across this software today: https://www.accessrecoverytool.com/how_to_recover_access_password.html
It simply cracked my password with special character instantly.
May I know if there's any better way to secure a ms access mdb file?
Thank you.
there are many considerations when it comes to security. as E.v.A. has already posted, at a minimum, don't use the old .mdb file format and instead use .accdb or .accde (to compile the front) or.accdr (user only has runtime version).
whether or not the password method for the .accdb has also been publicly cracked I cannot say as I do not monitor such things. Assuming it is the data you are concerned about (rather than the front end code) - then the accdb can encrypt the data so that one must have a front end, with the embedded pw in order to see the data.
One can always put the back end data onto SQL Server Express to then rely upon the SQL Server's security feature set.
I'm writing a c program and need to login to a mysql database. I'm trying to find a simple yet secure way of storing the username and password in the program. The program will make https calls to the mysql server. I just need to be able to include the user/password data and I don't want to store it as a string in the program.
Anyone know a simple yet secure way to do this?
This is on a linux system. raspberry pi debian (jessie).
You should not hardcode username/password into your binary, since it is very unflexible and you will tend to not change this password regularly if you have to recompile the binary each time. Furthermore, binaries are usually not specially read protected, so other users might get your password.
Passing the credentials as program arguments is a bad idea, too, since it might show up in a process list, may be safed in command line histories, may be logged by auditing tools etc. pp., so your password might end up in several places you don't want it to show up.
Your best option is to employ a configuration file with the credentials and give it the minimal rights it needs, so your credentials are safe. A simple library for linux is for example libini, which allows you to store key/value pairs in sections, but there are many other options.
Another quite safe option, which is for example employed by apache for private key passphrases and similar, is to specify a program (usually a shell script), which is executed and outputs the credentials on stdout, which is then parsed by your program. Again, you have to make sure here, that only authorized users/processes may read or execute that script.
I found out after a while that a component used on my website had an unfiltered parameter, in a WHERE condition in the following settings:
Using Joomla! 1.5, latest update.
The component is custom made, fairly small, and after reading its source I couldn't indentify any other security flaws.
The attacker was using SQLMap to do their work, as I saw its user-agent in the log.
MySQL version is 5.1.11
PHP version is 5.1.4
The database user has USAGE privilege.
The server OS is Linux.
After trying the same steps on my own box, I was able to read the database (and since I'm not an expert in sql injection I'm not sure that was all I could do).
My worry is mostly about the session table, would the attacker be able to impersonate a user from it? Aside from that, is there any chance he could have uploaded some payload to my server?
Also, could he have "magically" updated some field through this SELECT query? (No stacked queries available).
Thanks in advance.
If you can read the database, you can dump it with SQLMap and find the hash of the administrator's password.
With that hash, the attacker could crack it (or if it is MD5, find a collision fairly quickly) and login into your administrator account.
From there, your admin account is screwed. The attacker has admin privileges, so consider your site dead. Worse than that, if Joomla is like Wordpress, the attacker can use a custom PHP code in the theme, which allows them to drop to OS level and modify your Joomla installation.
In short, they can screw up your server, as Joomla executes arbitrary PHP code when it is run.
I just realized that there is no best way to hide MySQL string connection password in my executable file, especially in JAR file. Even encrypting it in EXE would only slow down the process (although I'm not sure how much time would it take to get an encrypted password from an EXE file).
So, from my understanding, I need something in the middle that would do the add, edit, delete etc to the database. Seems like a job for REST API or maybe SOAP services.
My question is, which one should I use? Or should I use something else? I was thinking Zend Framework to create those REST APIs. Then, I would use Qt to create a desktop application to call those APIs. But if I proceed with REST, my application would be a 3 tier application. Wouldn't it be better if I just create a web application? Maybe I should just stick to desktop application call those APIs since the application is already finished and I just need to change from connecting directly to MySQL to calling those APIs to perform tasks rather than changing the whole application to a web.
Any advice would be very helpful. Thanks in advance.
UPDATE:
I'm looking for a security that would protect my MySQL password connection.
Obfuscator would only obfuscate the code, it won't hide my string database information which In my opinion can be easily found using grep after decompiling the JAR using tools like JAD.
About my application:
Using a centralized MySQL database
Thousands of user
Contains sensitive information
My client uses Linux and Windows
My server uses Linux
All access are done in LAN, no outside connection (from Internet etc)
My current solutions (comments please):
Using REST APIs (safer since MySQL password is in the server)
Using Qt with encryption to the password
It depends on what kind of security are you looking for. Is this to protect the application from the user? To protect the user's data from other users? To protect multiple users' data from one another? To protect the user's data from an attacker?
In a lot of applications there's nothing wrong with storing the database login credentials in plain text. In other cases, you might try:
encrypting a user-chosen database password using a reasonably strong algorithm, e.g. Blowfish, using a hard-coded key;
having the user provide the password and "log in" to the program each time;
storing the database password in plain-text, but encrypt the data using a hard-coded key;
same as the above, but encrypt each user's data using their own provided password;
same as 2 but store each user's data in their own database with their login info as the database credentials;
storing the data on a secure remote database that users have to log into to access via a SOAP API;
using the native filesystem permissions to protect the configuration file holding the login credentials;
same as #1 but rolling your own really elaborate key-generation system: e.g. run the machine SID or a hardware id through MD5 using a randomly-generated salt, and then using the result to encrypt the login credentials.
Remember, there's no such thing as perfect security, so whatever you settle on doesn't need to be unbreakable. It just needs to be tough enough to break to make the hassle of circumventing the security mechanism exceed the value of the data. So, for example, if the data is a list of the top scores in Minesweeper, then ROT13 would probably be enough.
Edit:
I just want to add that, even if you can't get around having to hard-code an encryption key in your application, there are obfuscators for Java, .NET, and most other popular languages/frameworks. One of the key uses of these tools is to hide sensitive hard-coded strings like encryption keys.
Edit 2:
Given the additional details about the app in question, only 1, 6 and 8 would apply in this case. And a SOAP API is more appropriate for #6 as George rightly pointed out.
I also want to mention that there are Java resource obfuscators that encrypt string literals. This is just one example.
It pretty much depends in what environment your app runs
a) db and client local
b) db and client in a local network
c) db is in the internet
my two cents:
a) I would create a single db user and wouldn't use a password but restrict acces to localhost
b) direct connect to the database is fine but I would each user have to login with his own password and grant only the permissions he needs.
c) It's a bad idea to allow mysql connections to a public server. In this case webservices would be a good solution.
Anyway if your case is b or c I would stick with a login dialog for the user.
Maybe you should have a look at this http://www.greensql.net/ tool.
It is like a firewall but for mysql/postresql
So you can deny anything and only allow queries you want to.
If you are using Java for implementing your database desktop application, I would recommend to use Java DB as the database. There is a few ways of securing it, and there are alternatives to having a password in the connection string. I would recommend to read Java DB Security - Security Features in Java DB Release 10.4
It is easy to deploy your application with Java DB, since you can have much of it embedded in the same jar file. I have used it in a Point of Sale application implemented in Java.
First off, I realize that there is no such thing as a perfectly secure solution (and even if there were, its usability would be crap).
That said, how do you protect your MySQL database from being compromised by someone downloading your code and picking through it? Based on my experience with PHP, it seems obligatory to store it within the code at some point or another, which sends up flags for me. I can see where refactoring to obfuscate variable, constant, and (user-defined) function names could be beneficial, but in the end it'd still be possible to trace through it and find the file with the DB login information.
Ideas?
Usually the MySQL auth information is stored in an external configuration file. The MySQL user used by the web-based app is given limited permissions such as SELECT, INSERT, UPDATE, DELETE and not given permissions such as ALTER, DROP, DELETE. If you want to release the code to the public you would not include your private config file, but a generic/instructional/minimal config file instead.
Storing the MySQL auth info in an encrypted format is somewhat silly, as you'd need to store the private key / unencryption locally as well. If it is trivial for an unauthenticated user to view the code or configuration files on your server the problem isn't the code - it's your server setup & config.
Security can be assisted by storing any hard-coded information (in config files or scripts) outside of the web-root, and by suppressing (on the production code) error messages. That way, hopefully, your users won't see that userValidate() expects exactly three paramaters.
pygorex1 is correct, you should use external configuration files where "external" means a file outside the web root. So even if there would be a configuration error in your web server which would allow the user to see your source code, they would not be able to see the database credentials since they cannot be accessed directly via the browser.
pygorex1 is also right on the user permissions. Limiting the mysql user's access to a minimum is always preferred. Even if a hacker would get the your mysql password and username, he would not be able to do significant damage if the user permissions are only limited to eg SELECT-queries. One thing he forgot to mention was that the mysql user should only be allowed to log in from localhost (or from whatever host the web application is on), never use wildcards in the allowed hosts.