Hi Firstly if your application is well designed then your data should not be accessible by the wrong users - if you make sure that there is no way the wrong supplier id can be allocated - put an extra 'are you sure this is correct' check, make it so that the user id can only be allocated once two people have checked it or something similar.
Another option would be that there is no facility for viewing past quotes at all. If there is no facility at all you can give the application rights to insert data only - no update or select - adding another layer of security. If you do need the users to see some history then don't display the detail - no prices or part ids - whatever you can get away with. HTH Peter -----Original Message----- From: Nils Valentin [mailto:[EMAIL PROTECTED] Sent: 16 August 2003 05:05 To: Lefevre, Steven; [EMAIL PROTECTED] Subject: Re: Secure Database Design Part II Hi Steven, I believe I understand your concerns. I think the only way to reduce the risk of associating the wrong data is tripple checking it by different persons or even better make two tables which you can compare against each other. The second table only readable to you. This way you could always double check the correctness of the distrubutor table (as long as they are in sync ;-) Best regards Nils Valentin Tokyo/Japan 2003年 8月 16日 土曜日 05:36、Lefevre, Steven さんは書きました: > Hey folks - > > Thanks to everyone who gave input to my concerns. Of course, we don't > intend to have the mysql port open to the world. We will have Apache/PHP > connect on a unix socket, or to another machine with a cross-cable on > non-routeable IPs. > > But now I have another question. We are working on a web database to allow > our suppliers to log on and submit information that they would otherwise > fax, email, or phone to us. It would reduce work in our office, and reduce > errors in duplication of our information. But, we are very concerned about > security! > > We aren't worried so much about outside hackers as we are about legit users > trying to gain access to information they shouldn't. Some of our suppliers > are overseas and we think they have no qualms about trying to hack the > system, knowing the stunts they have pulled in the past. It would be > extremely difficult to pursue any problems legally, since it would be > international, and the damage would be already done. > > So, here's my question. Good database design dictates that I normalize my > tables. So, in this simplified example, we have a table of supplier quotes: > > supplier_id > part_id > quote_price > quote_date > > All of our suppliers would be drawing from the same table, via php. I'm > worried that good database design might be more susceptible to information > 'spilling over' -- what if I make a simple mistake and put the wrong > supplier_id with a new user's logon? That new user would see all the parts > that belong to whatever company I mistakenly associate them with. > > I'm not so worried about, say, suppliers seeing sales data. All the php > pages will be protected by Unix filesystem permissions, so I can be > reasonably certain that only those belonging to the suppliers group will be > able to execute supplier_*.php. Even if they do load some sales_*.php page, > then the MySQL user permissions will stop them from actually seeing any > data on the page. So there are two layers of security between sales and > suppliers, for example. I would have to make two mistakes for them to have > access to sales data. > > But, when all suppliers are accessing the same pages, it's up to my careful > hands to make sure they are pulling only their records out of the table. > If I make a mistake in a query, it might pull up other records, or even all > records! > > Of course if I design it completely perfectly the first time, I don't have > to worry about anything. But I'm not perfect and I don't make perfect > things. > > So, I'm thinking I should violate good design principles, and setup > identical tables for each supplier, salesperson, customer, etc. That way, > since they share the same PHP pages, they aren't all pulling data from the > same table. If there is any mixup in the query, the user doesn't have the > MySQL permission to pull data from another suppliers table. > > Does this make sense? > > Steve Lefevre > Network Administrator > IMI International, Inc. > 614.839.2500 -- --- Valentin Nils Internet Technology E-Mail: [EMAIL PROTECTED] URL: http://www.knowd.co.jp Personal URL: http://www.knowd.co.jp/staff/nils -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
