I have an idea for a web application that involves a multiple users, two different applications (which will be run from a user's local machine), and a remote database server.
Databases stored on remote server:
1) Username database - contains user information
2) application database - contains two rows, one for each application. Stores an application name and password.
3) app1 database - each row stores information about a single user for the first application.
4) app2 database - each row stores information about a single user for the second application.
Each of these two applications will have separate owners and I do not want them to be able to write to the other application's database. Also, because the users will be public users, their password should be required to modify their line in an application database that contains their information.
These are the requirements:
1) Each user has a username and password.
2) Each application has an application name and password.
3) To modify any line in one of the application databases, you will need the user's password and the application owner's password.
4) Applications are run on a user's machine.
I'm really not sure how to do this AND make it secure. Does anyone have any ideas? I would really like to avoid forcing each application owner to have their own server. I would like to have one central server that can store all the information.
Also, there is potential for the number of applications (and application databases) to expand beyond two. The programming languages are not necessarily going to be the same for both applications.
multiple users, multiple applications, one server.
Started by Fittersman, Jul 12 2010 12:34 PM
3 replies to this topic
#1
Posted 12 July 2010 - 12:34 PM
|
|
|
#2
Posted 14 July 2010 - 08:22 AM
I think I have come up with a solution, if anyone wants to critique it that would be really helpful. Either that or if anyone comes up with a better idea, that would be even more helpful
This Is what I was thinking...
1) Users of the application initiate the process that would require writing to the database of that application.
2) The application would collect all required data and make a POST to a servlet, which will be hosted on the main server.
3) The data would be displayed to the user, and the user would be asked to login.
4) Once the user logs in and verifies the data is valid, it is all saved to the database.
It is a little bit inconvenient that a web browser must be launched just so the user can save their data, but that is really all I can think of. All the other ideas I have been able to think of require at least one party to be entirely honest, which we all know isn't a good risk to be taking.
This Is what I was thinking...
1) Users of the application initiate the process that would require writing to the database of that application.
2) The application would collect all required data and make a POST to a servlet, which will be hosted on the main server.
3) The data would be displayed to the user, and the user would be asked to login.
4) Once the user logs in and verifies the data is valid, it is all saved to the database.
It is a little bit inconvenient that a web browser must be launched just so the user can save their data, but that is really all I can think of. All the other ideas I have been able to think of require at least one party to be entirely honest, which we all know isn't a good risk to be taking.
#3
Posted 15 July 2010 - 12:34 AM
Ok, here's my idea:
You have one large application database, with separate sub-databases for each application. Each sub-database consists of two parts: a small header containing a special number (say 0xC0FFEE11), and the rest of the data. The special number is the same for each application. Here's the trick, though: each application's sub-database is encrypted with a common algorithm (e.g. AES-256) using a hash (e.g. SHA-2) of the application owner's password. To access it, you ask the user for the owner's password, take the SHA2 hash of it, and then try to decrypt the header using the hash as the key for the AES-256 algorithm. If you get 0xC0FFEE11, then that means that the password is correct. If not, it wasn't, so deny access. Once you've verified that the password is correct, you can decrypt the rest of the application database. We can use the same method for user data. This way, the passwords don't need to be stored anywhere.
You have one large application database, with separate sub-databases for each application. Each sub-database consists of two parts: a small header containing a special number (say 0xC0FFEE11), and the rest of the data. The special number is the same for each application. Here's the trick, though: each application's sub-database is encrypted with a common algorithm (e.g. AES-256) using a hash (e.g. SHA-2) of the application owner's password. To access it, you ask the user for the owner's password, take the SHA2 hash of it, and then try to decrypt the header using the hash as the key for the AES-256 algorithm. If you get 0xC0FFEE11, then that means that the password is correct. If not, it wasn't, so deny access. Once you've verified that the password is correct, you can decrypt the rest of the application database. We can use the same method for user data. This way, the passwords don't need to be stored anywhere.
sudo rm -rf /
#4
Posted 15 July 2010 - 07:32 AM
Thanks for the ideas. That sounds quite similar to something I was thing of originally. The only problem I could think of with that is that the user applications would have to know the owner's password. These user applications could possibly be accessible to the public, so it would be difficult (if not impossible) to allow the application access to the owner's password without giving the public access to it. And once the public gets the owner's password, they are free to do as they please with it.


Sign In
Create Account

Back to top









