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
>
>

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

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

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

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

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 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

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

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

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