How to secure Database Credentials for a client-se

问题:

Ok, before I start, I know a lot of people have already asked this question. But I really didnt find the solution I was looking for. So here I am, explaining my project & requirements, & asking the same question.

I am doing a final year project on REMOTE ELECTRONIC VOTING SYSTEM. Developing a client side application, using java, that allows the public users to login to the APPLICATION using a LOGINID & LOGINPASS(Given to each & every voter by the election commission or so). The client-side application then displays a list of candidates participating in the election, & has radio buttons to choose one of it. After choosing, the user can then press a "CAST VOTE" button in order the "cast the vote".

The problem now is, to "cast the vote", I need to send this information to a database on the server. How can I make a connection from the client-side app to the database in order to update the desired table/details? I was hardcoding the database credentials into the source code, but realized recently that it is very insecure.

I cant really use a PROPERTIES files or a CONFIG file & protect it using OS features, since these can be read by the end-users as well(since they are the admin/owner of the OS)

And oh yeah, I'll be distributing the client-side app as JAR files or so, & hence whether I hardcode it into the source code, encrypt it, or use properties file, all of it are still open for risks & decompiling in order to know the database details.

Is there an alternate for this? Any workaround? If there is, can you please provide the details about it or how to implement it?

Thank You.

回答1:

With a normal client-server app, you don't connect directly from the client to the database server. Rather, the client connects to the server (using LOGINID and LOGINPASS as authentication), which then connects to the database server.

That means the client doesn't store any information about the database, and the server mediates all access to it.

回答2:

I think the solution to the two things is the same. You already are asking the server somehow if the username and password is correct for the voter.

Make this a webservice in front of the database, and simply have two calls (both authenticated by loginuser & loginpass)

GET /user/_self

This would return some information about the user, so you can greet them appropriately, and allow you to check that they know their password.

You would need to make sure that you didn't allow brute force attacks, nor denial of service.

POST /candiates/candidate

This would register a vote for from the logged in user.

If you put this over SSL, and use both client and server certificate validation, then you have a good chance that the client isn't spoofed into sending login details to an invalid client, and that the server doesn't get invalid requests from any old client.

If you make this a web start app (which requires signed jar files) and do a bit of key installation on the client, then you will have a reasonably secureish path.

You would place the DB in a firewalled zone, with the web application in a DMZ. Access from the web application to the database could be done using normal methods, but for a somewhat secured application, you would do your best to ensure that if the DMZ box were compromised, you still couldn't cast a valid vote.

Note that:

• There are no passwords anywhere in the client app
• Client and server verify each other user public key stuff
• The user's password is sent (assuming BASIC auth) over the wire, but this wire is an SSL wite.
• You could use DIGEST auth over SSL which means the user's password is never sent over the wire.

回答3:

Never let the user write directly to the database remotely!!!!!

Write a server app (php, servlets?), the user can log in to, and this app can update the DB.

If you don't know how to do this, seriously, you shouldn't write a voting app.

回答4:

Please be aware that this program running on the client side whichever way you'll implement it will be fundamentally insecure.

I know that this is just a university project work and will never be a real voting system however you must be deeply convinced about this fact.

Remember indeed that "Any secret key that you embed in a program can be recovered by a person who has full access to that program, the best you can do is make it time consuming to do so.". See this question on stackexchange to know why https://security.stackexchange.com/questions/35235/how-to-effectively-save-database-password-inside-desktop-application.

This is the main reason why DRM has always been defeated in all history of computing.

Now if you wanted to implement a more realistic voting system you would probably implement it as a web application (JavaEE for instance) where the user would use the browser to vote. This would be both more secure and wouldn't require for the voter to install any program on his computer.

Then there's the problem of the identity of the voter and voter coercion, but that I think is clear to everyone.