I need to create an application for a company and they would like to have people login to the application to have different permissions to perform different tasks.
My initial idea was to create a MySQL database, hardcode the credentials into the application and have the application connect to the MySQL database. The MySQL database would then have a table called "users" which would store usernames, passwords and permissions. The application would then query the server and perform the authentication.
The biggest problem with this is having the MySQL credentials hard coded into the application. If the application gets into the wrong hands, they could do lots of damage to the MySQL database if they snoop around to find the credentials and start dropping tables.
So I thought of developing a server that acts as an interface for the MySQL Database. For example, the client application would connect to the Server via TCP, and the server connects to a MySQL database. That way the MySQL credentials are never exposed to end-users. However, this means I have to develop a server application which a) will be harder to maintain and deploy for my customer (as opposed to just setting up a MySQL Server) and b)Has potential to introduce more bugs since I have an additional system I need to make (which relates back to point a for deploying bug fixes, etc)
So I was thinking instead of having a table of users in the database and having the application connect directly to the MySQL server with hardcoded credentials, the end-user would be given actual MySQL user credentials in which they would enter into the application to connect to the MySQL server. This means if someone gets their hands on the application, they can't do any damage to the MySQL database, but there still remains the risk of an end-user giving their credentials to the wrong person.
What are the best ways to have a desktop application connect to a MySQL database? Are there any other solutions other than the 3 I have thought of, or do you have any thoughts on my solutions?
As #Perception noted. Your best bet here is to implement a web service in front of MySQL. You don't want unknown numbers of clients from unknown IP addresses all having access to your database.
It would be really easy to DOS attack you by tying up MySQL connections. Not to mention that you would very severely limit your ability to scale your backend service to meet the demands of an increased client base without having a web service in between.
The web service could also offer you the ability to control user authentication and authorization in any number of ways (user/pass combination, token-based access, OAuth access, etc.).
Where I work there are two practices I have seen:
Each entity (person, thing, or business (depending on level of granularity needed) accessing the database) has their very own credentials. This was used on an MSSQL and on a Rocket Universe database. This is mostly the retail and legacy software.
We host the application ourselves and use a separate authentication system for users. The database credentials are stored on our server where the application is hosted. The client knows nothing of the backing database. These are usually web apps and web services.
Something you could do that we have done is that many of our applications actually talk through a RESTful service that emulates the database in a way. The application itself has no access to the database. I would read the wikipedia article on restful services for more information. Our authentication is done using Nonce encoded HMAC requests where each user is given their very own key tied to their credentials.
Wrapping the database in a web service gives you a few possible advantages:
If you decide to change your database structure while keeping the same information, you might not even need to update the client applications, just the service.
Credentials never leave the server, your credentials remain safe so long as nobody gains access to your server. Security in general is increased.
If you do your service cleverly enough, you could even transfer much of the internal logic that would normally be client side onto the server, making updates and bugfixes virtually seamless to the client.
The disadvantages that I see:
It is one more thing to maintain
Your application is vulnerable to denial of service attacks, but since it is a database that's a possible problem anyway
If the server goes down, all the client applications go down, but again, still a problem anyway.
RESTful architecture: http://en.wikipedia.org/wiki/Representational_state_transfer
HMAC: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
Our HMAC system works like so:
User logs in using username and password to their local application.
The local application communicates to our authentication service and gets a "Session Key" and shared secret for that username and password.
Using the Session Key (which expires in a short period of time), the application creates an API Key (which lasts a long time) and stores it to the computer. The session key could be used instead of an API Key if the user is required to log in each time. We mainly did it this way for convenience for some programs. If the computer is not secure, the Session Key should be used only and no API key is stored on the local machine. Each time the user logs in, they get a new Session Key.
Each request to the database service is accompanied by a HMAC-signed nonce which the application gets from the authorization service based on the API key. After getting the nonce, the application signs it using the shared secret. These signed requests can only be used once since the web service (which the user could know nothing about) authenticates the request. Once the signed nonce has been authenticated server-side by seeing if hashing the nonce with that particular API/Session Key's shared secret results in the same digest, the nonce is marked expired and the request is granted.
The above is vulnerable to man-in-the-middle attacks if HTTPS is not used, so often people make a message based on the nonce and the URL being requested along with a timestamp and compute the HMAC on that. The server then recreates the message based on the URL, checks to see if the timestamp is within some bounds (+/- 4mins or something), and then authorizes the user based on that information.
To further granulate operations, we also have a role system which checks to see if the user who owns the Session/API Key has been given permission to request the thing that they were requesting. If they have the appropriate role, the request is granted.
Summary: Credentials are done user-by-user, the end user has no knowledge of the database, a web service wraps the database in a RESTful API, and a role based system is used to make permissions granular.
This is just a suggestion and I am not saying this is the best or only way to do this. This just happens to be how we have ended up doing it where I work.
Let's look at two ways of dealing with database:
Client directly connects database, and manipulate database
Server connects to database and provide interface for client to use
Considering your use case:
valid valid serial number or to store/read information about certain user
it can be designed in the following way to provide security. (I'm no expert in this)
Client directly connects database, and manipulate database
You don't have to use your admin to visit database, instead you create a user for client only, and limit user's access privilege to only viewing (certain data). And you can enforce security policy at database by changing privilege for this user.
you can consult MySQL :: MySQL 5.1 Reference Manual :: 6 Security for more info.
6.2 The MySQL Access Privilege System
6.3 MySQL User Account Management
Server connects to database and provide interface for client to use
You can use HTTP and provide interface to client to use. And only the backend connects to the database.
Something like RESTful API, there are many easy to use framework that provides authentication and authorization.
I don't think it's good idea to let client have direct access to database in your case. So if possible, the second option is better.
Also note that password based authentication is not ideal.
Related
I have a web application where the regular user login is handled via SSO.(This prevents me from creating a service user)
In this application I have some web service endpoints that are not in the scope of any user. They will be triggered by another application and do some stuff.
Is the following the right way to do.
A token string is created by hand(because of simplicity)
The token string is stored in the environment variables of the system that provides the webservice endpoint as well as in the system that calls those endpoints.
On every call a simple equality check is proceeded - if the token is not present, the endpoint returns a 401.
Is my approach to simple?
I have not found much on this topic - my approach comes from the moodle-webservice handling, where you generate a webservice token in moodle and place it aswell in the application that calls the webservice.
For a basic application with no high security requirements, this might be ok.
A few things you could do (all of which will increase complexity and/or cost):
The service could store a proper password hash (like bcrypt, pbkdf2 or argon2) instead of the actual password. This would help, because if it is compromised, the actual key would not be lost, the attacker could still not easily call the service. (But it's already compromised, and this is not like a user password that would be reused, so it depends your choices and threat model.)
You could store this secret in a proper vault like AWS Secrets Manager or Hashicorp Vault or similar. This would enable you to control access to the key in one place, and audit key usage (maybe alert on attempts and so on). Access to the vault would still have to be managed, but that's easy via roles on AWS for example, where instances with the right role can access the secret but others cannot.
I have setup an web-based API to allow a remote app to GET/POST data. Every API call is authenticated with a User ID and Password that is encrypted with a secret key known only to the remote app and the website. This authentication not only ensures that the user can access the API, but also allows me to implement security features based on the user's profile (i.e. User A can see items A & B, but not item C).
I would like my server-side website pages to be able to call the same API methods remotely via AJAX calls, but, something just doesn't seem right about storing encrypted passwords in the code, and, my website implements a "Login As" feature, which will not allow me to set the encrypted password, since the passwords are not stored in plain text.
What is a good way to implement API security for both remote and "local" calls that doesn't require encrypting the user's password?
You should not be storing usernames and passwords in server side code. Sooner or later someone will lay eyes on your code and your data will be vulnerable.
But you should also not be storing secrets (key) in client side code. You should not assume your client can be trusted to keep that secret.
Giving user A access to item A and B, but not C is called authorization and depends on you knowing who calls your API (authentication).
You should probably look into a authentication protocol like OpenID Connect and an authorization protocol like OAuth 2.0.
Also see my answer to this question.
I am developing several Web Services that will be accessed by a mobile application. I have several requirements:
Each user will need to sign in with their own User ID and Password (the same User ID and Password they use to sign into the website).
Every Web Service request will need to be authenticated to ensure that the request is coming from the mobile app(s).
Every Web Service request will need to authenticate the user, since there is user-specific fucntionality built in, and access will need to be blocked if the user's account is disabled.
Let's assume that OAuth is not an option.
In order to ensure that Web Service requests are coming only from the mobile app(s), I am planning to use HTTP Basic Authentication in IIS (the mobile app(s) will need to have a User Account setup in Windows Server and the mobile app will need to store the User Name & Password and pass these in the header).
Next is the User Authentication for each Web Service request. Would it be suitable to encrypt the User ID, Password, and some shared secret key (a "pepper", of sort) with AES-256, pass that encrypted string as a parameter with each request (over HTTPS, of course), and then decrypt and parse it on the server to authenticate? This is the existing plan, but something just doesnt seem right about it - like it's not "secure enough".
What else can I do to properly authenticate users for Web Service requests?
I recently went through this problem and asked opinions from a group of senior people about how they solve the problem. Opinions were varied, but one consistent feeling is that your level of security depends on the use case of your application. Are you doing online banking or storing medical records? Then your security needs may be quite high. Social networking? Maybe not so much.
Basic Authentication is generally fine when encrypted over SSL, ColdFusion works well with it. If you use Basic Auth, make sure to encrypt your traffic with 1024-bit keys or better. Don't authenticate every request with username/password - that's unnecessary. Authenticate the first request, set a session token, and rely on the session token for your identification of users.
Set a polling mechanism from the client to the server to keep the session alive - set the session timeout to 30 minutes and the polling frequency at 25 minutes, for example. Otherwise you may need to re-authenticate expired sessions. Again, how you approach this part of the solution depends on your paranoia level, which depends on what kind of data/app you are dealing with.
Cookies, and therefore sessions, should work fine in iOS apps. If you use sessions to verify identity after authentication, make sure your session cookies are memory-only (set at the server level).
Check the SSL implementation of your server against the Qualysis SSL Test:
https://www.ssllabs.com/ssltest/
The report will give you a surprising amount of detail about the strength of your SSL implementation.
Lastly, consider implementing two-factor authentication to combat password theft.
If you ignore the SSL advice and plan on encrypting your password and communicating over an insecure channel, look at the Kerberos protocol for a well-known example of how to authenticate securely:
http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
Yes, you can use Basic Authentication but that means the client will need to store the username/password in plain text, and also send them over in plain text. Sending part is sort of fine if it's under HTTPS, but storing username/password in plain text may not be a good idea, unless you're using some secure key store.
Let's assume you have decided that Basic Authentication is the way to go, and you want to make use of the official CF way of supporting that, then you can use CFLOGIN.name & CFLOGIN.password. You may also check out Ask Ben: Manually Enforcing Basic HTTP Authorization In ColdFusion. In the remote cfc side, always validate the username/password, or return some sort of token and asks the client to use that token going forward. The token can be cfid+cftoken if you like, or even roll your own that never expires. If you use cfid+cftoken, and send them over as cookie or in body along with your web service call, I believe you can resume the session if you so choose.
I have an internal-facing RESTful web service. There are various client applications using the service, and the client apps themselves have end users. The web service needs to authorize requests based on the end user identities.
The question: What are the typical options for authenticating the end user here? That is, I want to authenticate the user, not the client application. (I don't mind if authenticating the client application is part of the scheme, but ultimately I need to know that the end user is who I think he or she is.)
One possible scheme, for example, would be to have per-client system accounts, and then have the client simply assert the user's identity (e.g. in an HTTP request header, say). So we authenticate the client application and delegate user authentication to the client. I don't think this is a very strong scheme, though, because it depends too much on keeping the system account credentials secret. I have seen too many examples of people e-mailing system account credentials around to put much faith in this sort of approach.
Another approach might be to have the client app, upon user login, use the user's credentials to get a token from the API, and then use that token for subsequent API requests. That way the authentication is user-specific without requiring the client app to hang onto the username/password credentials.
Anyway I'd like to have a better sense for the range of options I should be considering here.
The problem that you describe with "delegated authentication" is a real one. It means that a "client application" using it's credentials has access to the whole breadth of user data. This access can be used maliciously (for example a "semi-trusted" app harvesting api data) or negligently (for example an app accidentally exposing a Direct Object Reference Vulnerability - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)
Probably the most prevalent "token based" scheme is OAuth2 (http://oauth.net/2/), and the precursor, OAuth, which many sites choose to continue to use.
OAuth2 has a number of roles:
resource owner (the user in your case)
resource server (your api)
client (the apps you talk about)
authorization server (not clear who or what would fulfil this role in your case)
The basic scheme is that the resource owner authenticates using their credentials directly with the authorization server. They are then asked if they want to grant some information (which may just be a persistent identifier, or a description of the information exposed by your api) to some client. When they accept an 'auth code' is sent to the client and they use that (combined with their own credentials) to receive an 'access token'. This access token can then be used to authenticate against the resource server (which can check it's authenticity back against the authorization server).
Normally the way this is used is that the authorization server and the resource server are owned and managed by the same entity (for example google and facebook would fulfil this role) and then clients are independently managed.
The scheme can also be used internally within an organisation without the "explicit grant" which can still at least confirm that a specific end-user is present before releasing any data from an api.
I want to make few webservices, all of them will require login/pass authorization. I want to keep them all sync (one login, one password to all services), but also I want to share session between them.
If user is log in to service A, and open service B its automatically log in to this same account on service B like in service A.
How this is usually implemented?
I would consider a database to support the sessions.
You could have a database record that holds key session information. If the database supports BLOB fields you could even hold more complex session data.
The record would have a "cookie thing" that the web service requests would present, the service implementation code would take that "cookie thing" and look in the database table(s) to see if a login event had correctly occurred recently.
(I say "cookie thing" because if it is a webservice it may not actually be a browser coming in).
This is called a distributed session, implementations vary per webserver.
For Tomcat: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
For WebSphere: http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.iseries.doc%2Finfo%2Fiseriesnd%2Fae%2Fcprs_persistent_sessions.html
You can also store persisted variable in a database, which may be easier in your case.