Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 20 of 20 total |
Security hole in SQL |
Mon, Mar 5 2007 1:08 PM | Permanent Link |
Sean McCall | I think a nice addition would be a property for a temporary table
encryption password in TDBIASMDatabase component. If you put a password in the property all temporary tables would be encrypted. If you leave the property blank, none would be. Security if you want it & you would have the ability to examine the temporary tables for debugging if necessary since you created the password. Sean Robert wrote: > "Dave Harrison" <daveh_18824@spammore.com> wrote in message > news:40819DCC-ABCF-4BD7-8E10-F5CA36AE3A72@news.elevatesoft.com... > << Even canned result sets from table joins should remain encrypted if one >>> or more of the tables were encrypted. Use the same password as one of the >>> encrypted tables, it doesn't matter which one, as long as the data >>> remains secure. >> >>> >>> We can't just arbitrarily pick an encryption password from one of the >>> tables. >> For temporary tables, I think you have to. > > Why? There's no reason for anybody other than the engine at that time to > know what the password is. Create a password on the fly, it will only be > used to encrypt/decrypt that temporary dataset. If the application crashes, > the temp dataset is unusable, but who cares? In fact, this issue is giving > me the creeps, I'd rather see all temp files encrypted as a default. Do a > google "sox compliance" and you'll see the importance of this issue. I wish > I had not read this thread Temporary files remaining on the workstation > were an annoyance, now I see they can be a liability. > > I wonder if one can force the temporary folder to be some sort of secure > folder? Can you encrypt at the folder level? Maybe that's the solution. > >> It's going to be embarrasing if DBISAM developers now have to disclose to >> their clients (I think they are legally obligated to do so), that the data >> is no longer encrypted if a canned result set is produced. That means the >> client's data can be sitting on the disk unencrypted when a table is >> sorted on a non-indexed column or when tables are joined. >> >> There is mounting legal pressure and legislation enacted to force >> companies to tighten security to stop hackers (& employees) from gaining >> access to their critical data. Release of "secure" client information >> could be embarrassing to the company and can produce a litigation >> nightmare that could see fines in the tens of millions of dollars. I don't >> see any alternative but to fix the problem. Sure we can both argue the >> technical merits of whether the temporary data should remain encrypted or >> not, but in the end, it's the legal ramifications that will determine >> whether the problem is fixed or not. >> > > I'm certainly not a lawyer, but I do work with large companies and tend to > agree with you, though I had never previously considered this issue. > > Robert > >> Dave > > |
Mon, Mar 5 2007 2:40 PM | Permanent Link |
Dave Harrison | Sean McCall wrote:
> I think a nice addition would be a property for a temporary table > encryption password in TDBIASMDatabase component. If you put a password > in the property all temporary tables would be encrypted. If you leave > the property blank, none would be. Security if you want it & you would > have the ability to examine the temporary tables for debugging if > necessary since you created the password. > > Sean Sean, Good idea. Call it something like TDBISAMDatabase.TempPW for temporary tables. Dave |
Mon, Mar 5 2007 3:12 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dave,
<< I meant to say "Can I assume your TDBISAMTables's don't have this problem?". Your TDBISAMTables don't created temporary tables do they? If so, I'll likely use tables instead of queries whenever possible. >> No, tables never need to create temporary tables under any circumstances other than during alteration or optimization, and in those cases the temporary tables are always a mirror image of the source table, i.e. if the source table is encrypted, then the temporary table will also be encrypted. << My interpretation is, if the data is encrypted on disk, then it should stay encrypted in the temporary files. If you ask a programmer "Is it ok to remove the encryption on the data for intermediate tables?" I'll bet you the answer is a resounding "NO!". >> Perhaps in your case, but not necessarily is this always the case. The window of opportuntity to view the contents of a temporary table is only limited to a situation where the application terminated improperly. Under normal circumstances, a temporary table is opened exclusively and is deleted immediately after being used. There is no time period in which an external process could get access to the temporary table. For many customers, this is good enough for their purposes. << You're assuming of course that the client is using a dedicated database server that is in a secure location. >> No, I'm saying that in most cases, the reason customers use the database server is specifically because they don't want to allow users to have direct access to the database files themselves. The ability to secure database tables is limited when the users have direct access to the database files. << Often that is not the case. Client's are "cheap" and often put the DBISAM server on machines that are used for other purposes, which may allow users access to the temporary unencrypted files. >> Sure, but in that case it's just as easy for someone to simply delete the files, even if they are encrypted. Encryption doesn't provide you much safety from tampering in general. << For temporary tables, I think you have to. >> Perhaps, but for now the ENCRYPTED WITH clause is the way to go. << When using "Into", if the new table is permanent then you're right, the user needs to explicitly specify the password like he would for any other permanent table. But for temporary tables that were created from encrypted data and is beyond the developer's control, these tables should still be encrypted. Otherwise this is a hole in the database's security. >> No, it's not - ENCRYPTED WITH clause. You are ultimately responsible for the security of the data, not DBISAM or Elevate Software. If you leave the database files available on just some crappy old workstation so that anyone can copy them and go to work on them with a super-fast computer array back in the lab, that is your fault, not ours. << It's going to be embarrasing if DBISAM developers now have to disclose to their clients (I think they are legally obligated to do so), that the data is no longer encrypted if a canned result set is produced. That means the client's data can be sitting on the disk unencrypted when a table is sorted on a non-indexed column or when tables are joined. >> ENCRYPTED WITH clause. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Mar 5 2007 3:19 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< Why? There's no reason for anybody other than the engine at that time to know what the password is. Create a password on the fly, it will only be used to encrypt/decrypt that temporary dataset. >> I was under the impression that he was talking about all situations, including INTO. << If the application crashes, the temp dataset is unusable, but who cares? In fact, this issue is giving me the creeps, >> Don't be melodramatic. You are acting like someone's peeping in your window or something. << I'd rather see all temp files encrypted as a default. >> Encrypted in all situations ? That's a definite no-way. The performance would absolutely suck. << Do a google "sox compliance" and you'll see the importance of this issue. I wish I had not read this thread >> I understand the importance of this issue. And you're always free to skip any thread that you wish. << Temporary files remaining on the workstation were an annoyance, now I see they can be a liability. >> Only if you don't included the ENCRYPTED WITH clause. And once more for good measure: None of this is an issue if you use the DBISAM or ElevateDB Database Server and lock down user access. If you do not use the database server and lock it down, then there is no way to guarantee, even with encryption, that the data will not be tampered with or destroyed. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Mar 6 2007 10:23 AM | Permanent Link |
Dave Harrison | Tim Young [Elevate Software] wrote:
> > No, tables never need to create temporary tables under any circumstances > other than during alteration or optimization, and in those cases the > temporary tables are always a mirror image of the source table, i.e. if the > source table is encrypted, then the temporary table will also be encrypted. Great to hear. > Sure, but in that case it's just as easy for someone to simply delete the > files, even if they are encrypted. Encryption doesn't provide you much > safety from tampering in general. In my case the software I'm selling has data that is valuable because it takes a lot of work to gather it. If a competitor could crack the encryption he could take my data and resell it which is why I'm being more paranoid than normal. > If you leave the > database files available on just some crappy old workstation so that anyone > can copy them and go to work on them with a super-fast computer array back > in the lab, that is your fault, not ours. I'd like to see more than a 64 bit (8 byte) encryption key because it won't take that long for a brute force attack. I assume you did it that way so DBISAM could be exported outside of Canada/States. Is there a way for me to increase it to 1024 bits since the software I'm selling is for Canada/States only? TIA Dave |
Tue, Mar 6 2007 11:39 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Dave
With DBISAM you can hook into the encryption event (sorry don't know what its called just seen it mentioned on these NGs) and do what you like with the strength of encryption. Just quickly copied from the pdf manual ================================================ Encryption Customizations By default DBISAM uses the Blowfish block cipher encryption algorithm with 128-bit MD5 hash keys for encryption. However, you may replace the encryption in DBISAM with another 8-byte block cipher algorithm by defining event handlers for the TDBISAMEngine OnCryptoInit, OnEncryptBlock, OnDecryptBlock, and OnCryptoReset events. The OnCryptoInit event is triggered whenever DBISAM needs to initialize the internal block cipher tables using a new key. The OnEncryptBlock event is triggered whenever DBISAM needs to encrypt a block of data, and the OnDecryptBlock event is triggered whenever DBISAM needs to decrypt a block of data. A block of data will always be 8-bytes in length. Finally, the OnCryptoReset event is triggered after every encryption or decryption of a buffer (data record, index page, or BLOB block) in order to reset the cipher data so that it is ready for encrypting or decrypting a new buffer. Please see the Encryption topic for more information. =============================================== Its so much gibberish to me but you might find it helpful Roy Lambert |
Tue, Mar 6 2007 12:39 PM | Permanent Link |
Dave Harrison | Roy Lambert wrote:
> Dave > > > With DBISAM you can hook into the encryption event (sorry don't know what its called just seen it mentioned on these NGs) and do what you like with the strength of encryption. > > Just quickly copied from the pdf manual > ================================================ > Encryption Customizations > By default DBISAM uses the Blowfish block cipher encryption algorithm with 128-bit MD5 hash keys for > encryption. However, you may replace the encryption in DBISAM with another 8-byte block cipher algorithm > by defining event handlers for the TDBISAMEngine OnCryptoInit, OnEncryptBlock, OnDecryptBlock, and > OnCryptoReset events. The OnCryptoInit event is triggered whenever DBISAM needs to initialize the internal > block cipher tables using a new key. The OnEncryptBlock event is triggered whenever DBISAM needs to > encrypt a block of data, and the OnDecryptBlock event is triggered whenever DBISAM needs to decrypt a > block of data. A block of data will always be 8-bytes in length. Finally, the OnCryptoReset event is triggered > after every encryption or decryption of a buffer (data record, index page, or BLOB block) in order to reset the > cipher data so that it is ready for encrypting or decrypting a new buffer. > > Please see the Encryption topic for more information. > =============================================== > Its so much gibberish to me but you might find it helpful > > Roy Lambert > Roy, Now where would we be without "gibberish". I could set up a gibberish free zone, but that means no radio, TV, or internet. I could go into withdrawls pretty quick. I did a brief password test and it does accept a pw of length more than 8 characters, so I'm happy about that. I was worried I would be limited to 8 character passwords which could be broken by brute force in a few hours. From what you sent me it appears it does an MD5 on the password and uses that generated 128 bits to encrypt the data. So I guess the internal encryption key is 128 bits? That's ok, much better than 64 bits. But I'm not sure if its possible to increase it from 128 bits to 1024 bits using a different algorithm. If so, then great. Has anyone successfully changed the encryption algorithm in DBISAM? Dave |
Tue, Mar 6 2007 12:56 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dave,
<< I'd like to see more than a 64 bit (8 byte) encryption key because it won't take that long for a brute force attack. I assume you did it that way so DBISAM could be exported outside of Canada/States. Is there a way for me to increase it to 1024 bits since the software I'm selling is for Canada/States only? >> Actually, we use a 128-bit MD-5 hash for a key. Unfortunately, you can't increase the key size. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Mar 6 2007 2:40 PM | Permanent Link |
Dave Harrison | Tim Young [Elevate Software] wrote:
> Dave, > > << I'd like to see more than a 64 bit (8 byte) encryption key because it > won't take that long for a brute force attack. I assume you did it that way > so DBISAM could be exported outside of Canada/States. Is there a way for me > to increase it to 1024 bits since the software I'm selling is for > Canada/States only? >> > > Actually, we use a 128-bit MD-5 hash for a key. Unfortunately, you can't > increase the key size. > Thought so. Good old hom lan secrty, huh?I suppose ElevateDb has similar encryption, 128 bit blowfish? This should be adequate for what I'm doing. Would be nice if it could be increased if need be, that's all. I might end up re-encrypting some memo's that store the user registration info just to be sure. Dave |
Wed, Mar 7 2007 11:19 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dave,
<< Thought so. Good old hom lan secrty, huh?>> No comment. << I suppose ElevateDb has similar encryption, 128 bit blowfish? >> Yes. << This should be adequate for what I'm doing. Would be nice if it could be increased if need be, that's all. I might end up re-encrypting some memo's that store the user registration info just to be sure. >> You could modify DBISAM to do it, but I wouldn't recommend it. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |