On Thu, 12 Nov 2009 12:40:05 +1100 Ian Holsman <i...@holsman.net> wrote:
IH> most places i've seen don't use DB auth anywhere. there is a common IH> login, stored in a property file, sometimes stored in a internally- IH> world-readable SVN repo. In my current industry (financials) this is not acceptable. It puts money and jobs at risk to open access this way. IH> they usually use network ACLs to restrict access to good hosts. (jump IH> hosts). network ACLs have been tested for decades and they work. IH> implementing your own auth is just asking for problems. It's too hard IH> to do properly, and will probably never work well with the enterprises IH> existing auth systems. Layers of security are always a good idea (any firewall is just a part of good security design, and by itself only increases complacency). I should mention I've been a sysadmin and network admin for many years besides doing programming. No one is suggesting to implement our own authentication. We're going to use existing mechanisms, namely what JAAS supports (LDAP, NIS, etc.). We're creating a specific authorization mechanism because it makes sense for Cassandra, but we're again using JAAS to do that. IH> If you have sensitive data being stored, ENCRYPT it, or use a 1-way IH> hash instead of storing it. Ideally with a user-supplied key which IH> is not stored anywhere on disk. This is not feasible in many cases. Encryption is slow and very hard to implement properly. One-way hashes lose the original content, obviously. User-supplied keys require interactivity at least at some point, which is annoying and makes reliable operation harder to achieve. Fast access to the data is very important and my proposal (initial login followed by an auth token passed around) is a decent solution to these concerns. IH> sadly DBA's are people too, and it is pathetically easy for them to IH> get all the data from a DB-dump. Securing backups is, fortunately, much easier to address on the server side because it deals with static data. Ted
