Setting encryption key in web/mobile Javascript apps

I hadn't considered this previously.

I have a table in a database that is necessarily encrypted.

In a VFP app, I would SET ENCRYPTION TO <the key containing in an #include file) in the INIT of the app.

What would I do in a JavaScript (web/mobile) app?

thanks,

Hank

Hi Hank,

The connection between the client and the server is stateless.

In 4.1 I made some changes to the way timelines are handled so that whenever a database and/or table is opened its timeline can be enabled by setting timeline=on in the metadata.

e.g.

alter database southwind metadata "timeline=on"
alter table mytable metadata "timeline=off"
etc

The reason i mention this is that encryption is a similar problem.

Popping up dialogs in the web/mobile to input encryption keys is not practical.

I'm therefore considering handling encrypted tables through metadata.

alter database southwind metadata "encryption=key1,key2,key3"
alter table mytable metadata "encryption=key1,key2,key3"

I then need to mask off these keys when databaseMetaData() or tableMetaData() is evaluated from web/mobile Apps.

Hi Barry,

that metadata has almost turned into an alternative command channel. :) That's a good thing.

The integration should be made to work with a dynamic call to whatever Key Management System is being used (I can use Lianja to create a KMS for this purpose, at least.)

So the question I have is how do I unencrypt a given table (or an entire database) using a dynamic call that will affect only the current session in a web/mobile app. Wouldn't the metadata setting affect all calls to that table, thus allowing whoever can get a connection to the database to view the information?

thanks,

Hank

Hi Hank,

But they need to authenticate in the first place.

I like the idea of using a KMS that certain tables or databases would need to authenticate with. That’s just password related security.

Once you have encrypted a table you can only unencryt it with the same key.

I suppose the KMS once authenticated using username/password/database/table it could return an encryption key.

The only thing to be considered is that tables are opened and closed repeatedly so how this is accomplished on a stateless web connection needs to be properly thought out.

Hi Barry,

Yes, in stateless it gets tricky.

Even tricker: a common security requirement is that the encryption password must change on a regular basis (it seems as though a month is acceptable). This would entail resetting the encryption on the Lianja tables, so that's a management job the developer would have to work out. Anyway, that's why the key can't be supplied statically even within a given app (I'm thinking apps that are busy 24/7).

If the ODBC driver specified the decryption key as a key/value pair in the "other" section, and that value specification could be a dynamic call to the KMS, then the issue of stateless could be handled. That all calls, even to the local db, go through ODBC is a reasonable requirement. When the LCS is used in a security-aware environment, the LCS would/should be in a DMZ with very narrow privileges, with the connection to the SQL Server/s (of whatever variety) being the only internal connection/s allowed. Keeping the data on the same server connected to the internet is a definite security no-no.

As I know you are aware, the bad guys aren't going way, and in fact are always raising their game, so there's going to be more of this rather than less.

thanks,

Hank