I am not sure what you mean with your specific example. I gather that referring to user names and passwords you are talking about something that should be encrypted? Any database can do that. So if you mean anyone can hack the system and get logins and log in as anyone else and thus take their rights then sure. They can go for it. Do you have that code, by the way? I would be curious to see a glaring vulnerability like that. It would affect everything on the compromised system - not just databases.
Usually logins are done at the OS level. Now, if your app has a security table and requires a separate login then it is open season. Better encrypt it. But by "security" I was referring to things far more generic than perhaps using notepad to read data out of a file. I am referring to the database being in control, and not the application being in control. Multivalue databases are app-centric and suffer because of it. I can change data without the app and the multivalued database is purring away like nothing odd is happening. I think I'll give myself a raise! Not only can I read, modify, delete, whatever, anything I can easily write a program that will corrupt the whole database - by mistake! That is because it is really a file base. You open a file, and (you) write to that file. If you can write to it, you can write to all of it. Other database systems error when you try to update something for which you don't have permission. And I can see a view of the data that includes say everything except the board of trustees. I simply would not be permitted to see there data in the first place. In relational databases you must ask the database to read, update and delete data from an abstract object. If it doesn't allow you to you aren't going to get to do it. And it is all managed from one central place - where the data is, not where the app is. The app can't protect the data when I am using something else (like the editor) to screw it up. If you use wIntegrate the Query Builder is a prime example of a major security problem. The app may prevent me from seeing how much the CEO is making, but Query Builder digs right in and will show me. App based security is very passive. Your code must respect it as it actually has no power over you other than within the app itself. But if you are dealing with stuff like credit card numbers you better encrypt. But again, that is a security measure taken at the database level. I could still read the encrypted data, and change or delete it with a multivalued system. But it would not be readily useful to me. I agree with you about no database being 100% secure. But unless extra steps to lock down accounts, verbs, files, dictionaries, fields, records, and i-descriptors, etc are taken then multivalue is approaching 100% insecure. OK, that is once you get logged into the system. You do have the OS level securities in place. A big problem is the ecl/tcl prompt. Some vendors address this issue by providing a "fake" ecl/tcl prompt, and that layer prevents you from doing bad things to the database from that prompt. But still, I could access a data "file" from another account that I could create sans the application with a remote pointer and voila... I know how much the CEO makes, and I gave myself a raise. Another way is to prevent you from exiting the application to the prompt. As a side note, I have had Unidata failures that dropped me to the Unix prompt. That's bad too. I haven't had Oracle do it yet, but it is just as possible I suspect. Maybe there are ways to do this with other databases, but it is a lot harder. A better way may be to reinvent the wheel and copy somebody else's security model (hmm...) and implement it at the database level. I see this as something that should be addressed. With a little overhaul multivalue could be a world class contender. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Ritchie Sent: Monday, May 17, 2004 11:48 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Cost of Oracle vs PICK -----Original Message----- From: Jeff Flynt [mailto:[EMAIL PROTECTED] Sent: Tuesday, 18 May 2004 4:23 PM To: [EMAIL PROTECTED] Subject: RE: [U2] Cost of Oracle vs PICK <snip> If the Pick model provided the same "uniform" level of security that standard relational databases do then the rest of the world might look at it differently. </snip> Sorry to disagree with this point, but join any number of online communities and ask how to extract usernames and passwords from MySQL, Oracle, MS SQL, MS Access etc etc and some one will drop some code on you. This is not a valid arguement imho. No db system is 100% secure against those wanting to crack into it. Just my adjusted $0.01c worth to the debate, (that would be $0.00725 US cents :) ). ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.686 / Virus Database: 447 - Release Date: 5/14/2004 ------- u2-users mailing list [EMAIL PROTECTED] http://www.u2ug.org/listinfo/u2-users
