There is a database with different tables for a mobile phone application.
UserIds are stored in the table for each row. Only these users should be allowed to read these data sets. Is this technically possible? If yes, how can I implement this?
I have a smartphone app where users can register to access the self created data. But I want to avoid a security hole that allows access to the whole table.
Edit: Correct text
Related
We have developed a data matching application where each user can upload their data and the apply the features we provide to identify when the same entities exist in those files. While it will change in the future, we are currently built on MySQL. Each user has their own tables based on their own data. Thus, each user has a different number of tables and most have structures unique to that user (i.e. I couldn't put all user data into one, super long table).
We currently store each user's data in a schema dedicated to that user but all of these schemas are in one, common DB. The only way users can get to their data is through our application. It uses one user & password to access all schemas in the DB.
As we get more folks testing our system, I am starting to think more deeply about security. One thing I'm considering is dedicating a unique UID / PW for each application user and giving that UID access only to that user's schema. In addition, I would like to encrypt each user's data using a key specific to that user (it's been suggested to me that this protects data should a bug in our application accidentally give a user access to some other user's schema).
So, my question is this: can I encrypt a Google Cloud MySQL DB at the schema level and, if so, how? If not, is the only option to create a separate instance for each user?
Thanks!
Ben
I am building a mobile application that I want the save data should be available across multiple devices for the login user only.
E.g If a user login to the mobile application, only his records (data) should be synchronized (available offline) maybe using the user unique id.
For security reasons, I don't want all the records in the table row to be synchronized since other users records will be there as well.
I have read about using filters in sqlite-sync but I didn't see anything that can prevent a user from manipulating the filter and synchronizing other user records instead.
What is the best method to use for the synchronization of just the user record only in a secure way (using authenticated user id)?
Use a hard-to-guess random text string for your subscriberId. A CHAR(10) string that's Base64 encoded can carry 50 bits of randomness. That's fairly hard to guess.
When a user authenticates (logs in) pass the subscriberId to your mobile app.
When you create a new user account, use a high-quality random number generator to make her a new subscriberId.
Don't allow data lookup from your mobile app by a user serial number, only by subscriberId.
If your server gets a request for a nonexistent subscriberId, somebody is trying to guess valid values. Disconnect that person.
I was looking into how to add a create user account/login to my website, so I could have members join and come back, etc and ended up finding out in order to do that, I'd need to create a new database in my SQL, to store the users credentials, I dont have the option to create any new databases by my webhost. Only the one database is what I can use. Could I just add this to my existing database? Do I really need more than 1 database on SQL for my website? If so, could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website? Im sorry for the few questions, Im really new to all this and so confused and overwhelmed.
You can create multiple tables in same database.just make a table with fields such as user id,password etc. and use it for saving,fetching user details using sql queries.
Could I just add this to my existing database?
Yes, you can tables to the existing database.
Do I really need more than 1 database on SQL for my website?
There are a lot of websites that use just one database. Some websites use connections to multiple databases. What information is stored in which database is frequently the result of factors other than the website. The ability to connect to multiple databases means that a website could use authentication/authorization info from one database, store user profiles and submissions in another, and read information from other sources (for example, historical stock prices, stored in another database.
All of that information could be stored in a single database. Having them as separate databases means that the databases can be managed separately (frequencye of backups, replication to DR site) and makes it easier to share the database across multiple applications. (For example, we would probably want employee payroll and health care information stored in a separate database, with separate access controls.
Could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website?
It may be technically possible to do that, but that's not the way you want to go. That would add another dependency... the website at the web hosting provider would be dependent on having access to another database, which is not being backed up and managed along with your website.
I am making a site in django [mysql] that will have to be scalable, so my question is what is better for multiple users with same kind of data
have a db per user , or have one big monolithic db?
Please advice of the design pattern preferred for this?
thanks!
Normally, You use a single database for multiple users with the same table schema, unless your requirement makes you create multiple DBs. Especially, if you have the same kind of data for each user, you must handle access rights and other things in your application side, not in your database side.
Django hava a nice User authentication/authorization system that lets you define permissions and lets you control user access rights (creating a new record, updating an existing one and deleting one) for each type of data that is represented by a table in your system. Also you can define custom permissions to control access rigts as you wish.
Separate databases are almost never the correct answer but there are cases in which it's appropriate. Unless you have very special needs, and in absence of any real description of what your project is, a single database is likely to be the correct decision.
Is there a way to secure tables in ms access db from unauthorized access? I would like my users to use the forms in the db but i don't want them to see the contents of the tables. I know i can hide a table but anyone who knows just a bit about access can show the hidden tables anyway. I cna also change a name to UsysTableName but again - enabling system tables shows them all. Is there a safer way? Securing by password maybe?
Also in access there are users and groups, and the possibility of granting rights.
You can access this functionality via tools/security/user and group permissions.
You need to create a workgroup information file in order to use this :
see : http://www.databasedev.co.uk/access_security.html
NOTE : Indeed Ms Access is in most cases a poor choice of db. But if you have to keep on using it for one reason or another, learning its security model is imperative in real world apps.
For Access 2003 Understanding the role of workgroup information files in Access security at http://support.microsoft.com/kb/305542/.
For Access 2007 How to use the Workgroup Administrator utility in Access 2007 at http://support.microsoft.com/kb/918583.
In your case, I suggest moving the tables you want to secure into a different database then link to the User-Interface (front end) database. This allows you more control over security. Using a password only keeps non-users out of the database. Logged in users can still see the tables.
One solution is to have your forms on one side (client side) and your tables on the other side (server side). Each user has only a copy of the forms, and the tables are somewhere else on the network.
Another solution is to install the runtime version of access (free to use) on user's computer. In this case the database window does not appear.
Whatever is you choice, you'll have to fully manage access to commandbars, creating you own ones (and forbidding the display of access commandbars).
If you go for the first solution, you'll be on your way to a real client/server structure, and you'll be able sooner or later to switch to SQL Server for your tables (your forms can then stay in an Access client application).
With some limits, it is possible to completely delete the links to the back-end tables in the front-end/app:
During app open, just use ChDir "\\someShare\someFolder" in VBA
As the source of your forms & reports, use SQL SELECT instead of saved queries/tables, using the syntax: SELECT field1, field2 FROM [BackendName_be.mdb].myTable. Note that the path is NOT specified!
This way the forms/reports will work perfectly, without any table (not even hidden) in the app.
If you put the BE in a hidden folder/share and you deliver an MDE, users will have a very hard time finding where the data is.
This technique has the added benefit to allow instant switching of the back-end (like between test/prod).
Access does a very poor job of securing data in tables. Your users NEED access to the tables in order to work with the data, but you don't want them possibly seeing EVERYTHING. You could encrypt the data in your tables yourself on the fly. I talk about this in my Access Data Encryption seminar.