Well it depends on how secure you want to make your application. Which could spawn a very long thread indeed and is really matter of system requirements.
Personally I think using a single account (that all your application users use) isn't a good idea, because you lose any sort of database auditing. You can't tell who exactly deleted that row, or even worse, who dropped that table. So then you get into the roles issue. Which is very important in a strong security model. With a single account that means at most you have a single role. Pretty much making the role based security in your database useless as well. So the security that is built into your database is mostly going to waste. What's worse is that the security is moved into your application where it doesnt fit. After all it's the data you want secure. So why should CF be in charge of protecting it? Of course, if you are using a shared server, then you shouldnt be concerned with security to such a degree. Afterall, if your data is so confidential, why are you trusting it to a third-party? As for plain text passwords on your system, thats where OS security comes in. If some gains login to your server, they can do many worse things than logging into your database. However, if you fully utilize the database security model, these credentials aren't stored there anyway. Before OS security comes physical and network security... I guess the short answer is to utilize the security thats built in to your database. Every user should get an actual database login. That login is passed through CF to database every time. (You can store the credentials in session, even encrypt them if you want to get crazy.) That login is assigned specific application roles in the database. Those roles only have execute on stored procedures. (Never grant select, insert, delete etc to any user or role). As you can see this thread could get very long, very fast. Dave Watts would be a good resource for more security with CF as he is presenting on the topic at CFUnited. Even if you can't adopt the security model of your database CFMX7 offers two things to solve the problem above. Don't deploy the CFAdmin to production (which you _really_ shouldn't do) and only deploy compiled source code. Sure someone could hack your OS and decompile the source, but it should be enough deterent to make them choose a softer target. -Adam On Apr 5, 2005 4:52 PM, Jeff Garza <[EMAIL PROTECTED]> wrote: > What would your strategy be for storing database credentials if you are not > storing them in CF? Are you saying don't put them in your cf templates or > are you saying do not store them via the CF Administrator? > > Just curious. > > Jeff Garza > > ----- Original Message ----- > From: "Adrocknaphobia" <[EMAIL PROTECTED]> > To: "CF-Talk" <[email protected]> > Sent: Tuesday, April 05, 2005 1:38 PM > Subject: Re: Is CFMX 7 any better? > > > 1) Do not deploy the CFAdmin to production > > 2) Do not store db credentials in CF > > > > CF7 handles these credentials the same way CF6 did. > > > > -Adam > > > > On Apr 5, 2005 4:36 PM, Mike Cohen <[EMAIL PROTECTED]> wrote: > >> It's bad enough that the Administrator password is freely available, but > >> I just realized that every jdbc password on the box is too. Is MX 7 any > >> better? > >> > >> > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:201629 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
