Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 4 of 4 total |
Catalog SQL script security |
Tue, Feb 27 2007 5:22 PM | Permanent Link |
Dave M | Is there or will there be an encrypted catalog?
My concern is the visibility of scripts. Although I haven't tried it yet, I assume when the catalog is read into memory, scripts in memory will be visible. (Optional precompiling scripts would make things more difficult for hackers.) dave m |
Wed, Feb 28 2007 9:10 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dave,
<< Is there or will there be an encrypted catalog? >> There is the ability in EDB to optionally compress and/or encrypt the catalog, but we don't have it surfaced as of right now. The basic issue is that, if the user has access to the files themselves, they can simply do more damage by simply deleting them if they want to. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 28 2007 3:49 PM | Permanent Link |
Dave M | >>"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
>>The basic issue is that, if the user has access to the files themselves, >>they can simply do more damage by simply deleting them if they want to. That's not the security to which I was referring. I am thinking about reverse engineering, and making it as difficult as possible. That's why I briefly mentioned plain text scripts being visible even in memory. Some time ago I looked at Firebird. As I recall, the answer to the visibility of scripts was not to give the user access to the gdb and to wait for a future version. Suffice it to say that this was not a "selling point." Dave M |
Thu, Mar 1 2007 5:07 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dave,
<< That's not the security to which I was referring. >> That may be so, but it's the only security that matters. If a user can get to the database files and read the SQL text there, then it really doesn't matter whether the SQL text is visible in-memory. Also, pre-compiled storage in the catalog is not really an option because it is more space-consuming than plain text and is very inflexible to future changes in the way the SQL is compiled. << I am thinking about reverse engineering, and making it as difficult as possible. That's why I briefly mentioned plain text scripts being visible even in memory. >> There's no way to prevent the SQL text from being read while it is in-memory. The only way around this is to use the C/S access in EDB, which would mean that SQL objects are only read into memory on the ElevateDB Server. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |