I have the gist of how to connect to a MySQL server, however my dilemma is using passwords. Here are some of the things I am looking at.
Architecture will be 1 core service which as of right now will be set up as a digest authentication service. Note: In the future I will also have it set up for kerberos authentication.
The service will have a schema it will need to be able to access in MySQL. Also the micro services will have their own schemas that they will also need to be able to access.
The database will be localhost initially but will eventually be moved (in production) to a separate server altogether.
Given the requirements above, I cannot give the services users that are restricted to localhost and have no password associated with them (nor would I want that in the event the server was hacked). So how can I have access to the database without using any plain text passwords (I don't want it stored in the code)?
Maybe I am just not understanding something here that could make my life so much easier so again I look towards the wisdom of the many here. Thanks in advance!
Some things that I should maybe mention: I plan on using go-martini as my http router, I'd like to be able to set up OAuth Provider, I will need to manage user sessions and authentication (right now not as important as I'm trying to get the core part of the service setup)
Edit: To clarify some information;
I do not have an AD, kerberos, or any other LDAP service to use and would be hard pressed to set them up at this time in a VM I use for development.
The service should not be dependent on any of those items as SSO is a much later requirement in this project.
Strictly speaking it will be deployed in environments where there are none of those available and this is non-negotiable.
I also am specifically developing the services in Go and the clients in React.
Note: I do not need someone to correct MY question. I would appreciate it if you do not change the context of my question to suite the answer you wish to give me. That is not what StackOverflow is about, it is also quite rude to do that. Thank you.
Related
So I have the website that provides the API for logging in/registering/etc. And I have the MediaWiki set up at my server.
I need to disallow MediaWiki registration and only allow logging people in through our API. So, when the user tries to login, no request to MediaWiki db for the user should be done, instead the request to our API should be done, logging person in if our API returned the correct data and displaying an error if it didn't.
Is there a way to get it done with MediaWiki?
Thanks in advance.
Your question is very broad and involves some development but also a lot of configuration as well. So, let's start:
First of all, you need to somehow integrate with the API you mentioned, which is possible by developing your own primary authentication provider. See the high level documentation. In this, you will have all the necessary entry points a user might hit when logging in or registering a new account and you can "translate" them to the actual actions which you need to do in your API (which you do not mention what it is or provides, so we can not give you better guidance here).
The second step would then be to configure this new authentication provider as the only one using $wgAuthManagerConfig which will in fact disable all other ways of creating other accounts as well as logging in with other accounts then the ones provided from your API.
If you've more questions, I would suggest that you provide more information and specific points where you're stuck :)
You can have a look at Extension:Auth remoteuser, it could fit at least partly you needs.
At the moment I am working on a CRUD app that I am going to deploy (someday) and use for my own startup company. However I am nowhere near finishing this product and I stumbled upon a question that I can't seem to figure out.
I am using Express to serve angular the data out of my MySQL database. To do this I had to create '/api/' routes. However if I go (for example) to '/api/clients' I will be able to see the entire list of clients in an ugly array. In this case that does not really matter since it's just the data they were able to see anyways.
However my question is, is it important to block these kind of routes from users? Will problems arise when a user goes to 'api/createClient'? Could this result in a DB injection that could ruin my db?
My project can be found here: https://github.com/mickvanhulst/BeheerdersOmgevingSA
The server-side routing code can be found: server > Dao > clientDao.js
Controllers, HTML & client-side routing can be found in the 'public' folder.
I hope my question is clear enough and someone will be able to answer my question. If not, please state why the question is not clear and I will try to clarify.
Thanks!
Looking at the code, it looks like your URLs can directly be accessed using browser and if yes, then this does pose a security concern.
Doing DB transaction with the user provided fields or values is major security concern, if these data are not validated and sanitised before making a database call.
I would recommend following minimum steps to follow before crafting APIs which is internal but can be accessed using browser -
If this is internal, then do not provide HEADER ACCESS CONTROL from the server or keep it confined only to your domain name. This prevents any ajax call to be made to your APIs from another domains.
Do sanitise and validate all the data thoroughly before doing any kind of database transactions. There are lots of material on this everywhere on how to do it.
If these APIs are meant to be used for internal purpose, then kindly provide some kind of authentication to your APIs before doing the logical work in your routes with the help of middle-wares. You can leverage cookie authentication for very simple API authentication management. You can also use JSON Web Tokens, if you want a more levels of security.
If you are manipulating your databases then I would highly recommend to use some kind of authentication in your APIs. Ofcourse, point number 2 is must.
Right now, in my internship, I'm assigned to create a system that holds employee information such as personal info, education, salary, etc.
All these stuff is kept in a few spreadsheets right now. I need a basic program, but I feel like I should be using MySQL or another database solution to hold the data. I used MySQL before, but it was a PHP/MySQL assignment which I used Wampserver to create the whole system.
Edit: The system will be used by a few computers across the network. When someone makes a change to the system, it will become visible to other computers aswell. (obviously) (Before the edit, I thought that it's gonna be used by a single computer.)
I'm confused right now. Should I create a PHP/MySQL webpage with wampserver (or similar) to hold the information, or not?
Would it be easier or better to combine MySQL with some other programming language (such as Java/C++) and build a GUI? (I doubt it)
Should I come up with a different solution? Without database usage?
Database usage would be the best option. In the end it will come down to what you are more comfortable using, Java/C++ or php, for what you want to do either can work, but remember the database will need to be live at all times and using wamp server wont cut it. You need to learn how to tun a mysql server without wamp, which is easy(Google is awesome). And personally I would have used Java because Java is also easy to link with mysql, just google it a bit, and java doesn't need to run on a server so no wamp needed as you would have needed for php.
EDIT:
Ok if I understand you correctly what you want to do is the following:
1. Identify a pc to be used as a server and assign it a static IP.
2. This must also be the pc that is turned on first every day and turned of last.
3. Create a front end client application that connects to your sql server that you will be running on the server machine.
Now I am assuming this network is rather small, so you wont need a specific computer to just act as server. The server can also be one of the client machines.
The best approach would be to create a mysql server and make sure the firewall is not blocking your sql server. Then create a client application that can access the database over the network using Java, I find this easier than creating a php server for the users because of port forwarding for an apache server is time consuming, I did it once and never again. Java will be easiest to make the application work over the network. Use Netbeans for the development, it's an awesome IDE and it makes life easier when setting up the database connection.
If you have anymore questions please ask in comment, and I will elaborate, since this might be a bit vague lol.
Of course you should use a database for this type of work. That is the best way to organize, search, sort and filter your data without having to reinvent the wheel.
As to the other questions, the choice of language and environment is up to you to decide after evaluating the needs of your application.
Your solution should use a database to store the data and an front-end application to manage the data.
The database and front-end should be seen as two separate layers. In other words create the database using whatever database your are familiar with eg: MySQL and likewise create the front-end using whatever technology youre familiar with eg: PHP.
Personally for this type of requirement i would typically use MySQL / SQLExpress and ASP.Net / MVC3 front-end.
Hope this is helpful.
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.
I want to build a web based front-end to manage/administer my Linux box. E.g. I want to be able to add users, manage the file system and all those sorts of things. Think of it as a cPanel clone but more for system admin rather that web admin.
I was thinking about creating a service that runs on my box and that performs all the system levels tasks. This way I can have a clear separation between my web based front-end and the actual logic. The server pages can than make calls to my specialized server or queue tasks that way. However, I'm not sure if this would be the best way to go about this.
I guess another important question would be, how I would deal with security when building something like this?
PS: This just as a pet project and learning experience so I'm not interested in existing solutions that do a similar thing.
Have the specialized service daemon running as a distinct user -- let's call it 'managerd'. Set up your /etc/sudoers file so that 'managerd' can execute the various commands you want it to be able to run, as root, without a password.
Have the web server drop "trigger" files containing the commands to run in a directory that is mode '770' with a group that only the web server user and 'managerd' are members of. Make sure that 'managerd' verifies that the files have the correct ownership before executing the command.
Make sure that the web interface side is locked down -- run it over HTTPS only, require authentication, and if all possible, put in IP-specific ACLs, so that you can only access it from known locations, in advance.
Your solution seems like a very sensible solution to the 'root' issue.
Couple of suggestions:
Binding the 'specialised service' to localhost as well would help to guarantee that requests can't be made externally.
Checking request call functions that perform the actions and not directly give the service full unrestricted access. So calling a function "addToGroup(user,group)" instead of a generic "performAction(command)".