Re: General security Question (Databases)

Hi Ben. I see your point, but it's harder to deal with in those cases. I'd reckon most people on this list are using some type of shared hosting system anyway, where they CAN'T do that. Creating extra users in most databases I've used is a bit of a pain, and trying to tie in your application's security with that of a database's may be problematic. Example: we've got a system running on MSSQL7, with about 10000 user accounts, with a few different levels of permission. They all can read and write the same tables, but only the rows which correspond with their user info. Breaking that data up into 10000 tables, each with a user that only has access to that table, is just weird, imo. At the end of the day, some process with higher permissions needs to run to be creating the 'lower' accounts anyway, in whatever fashion that may be. So anyone breaking into a machine is more than likely going to go after the main process' security info anyway. ben.2.edwards@bt.com wrote: > The examples of holding passwords in databases (i.e. mysql) tend to encrypt > the password. Although this seems sensible (if not necessary) it douse mean > that if a user forgets there password the normal solution is to generate a > new random password and email it to them. Then I realised that this fafing > about was all a bit unnecessary. Surly if security has been breached to the > extent that the user table can be accesses chances are that the intruder > could delete data from tables or even drop them. In fact the best solution > is to set up proper database users rather than your own 'application' users. > This way you can set it up (at database level) so that for 'Punters' they > can only read most of the data and 'Administrators' have fuller access. > > So maybe the conclusion is there is no point in encryption passwords but > there are very good reasons to have users an 'real' database users. > > What do you lot reckon.