Internal security of Rev?

Dar Scott dsc at swcp.com
Thu Jul 13 23:05:30 EDT 2006


On Jul 13, 2006, at 6:50 PM, John Tregea wrote:

> Thanks for your time again. I believe that the database server is  
> secure. It will be Solaris 10 running a dedicated copy of  
> postgreSQL. Solaris will be configured with a zone that enables  
> login only on the postgres port . The server will be supplied by us  
> with pre-configured software for the client.

I am not familiar with postgres, so keep that in mind.

> The users will have one U3 enabled USB thumb drive per licensed  
> client and the user application will be programmed to only run on  
> the serial numbered, unique thumb drive.

Cool!  I suppose users should keep up with those as they would keep  
close tabs on a badge.  But the drive might get stolen and the user  
might be a bad guy.

A password is like a security code that would go with a badge.   
(Maybe a future version could even have a duress password.)

> This is why I was asking about the security of the stand-alone rev  
> application. I intended to store one secret key in the application  
> in a custom property in base64encoded form. This key would unlock  
> the first step of authentication on the database login with  
> everything after that coming from within the database.

I wouldn't do that.

> It is true that the data can be encrypted on the storage medium  
> without me doing that in the client, but I thought that made the  
> transmission more vulnerable to penetration (even with SSL).

I'd put that effort into making SSL solid.

How about this:

(Make the network as secure as you want as an add-on and independent  
feature.  You can use ipSec or encryption hardware among certain  
classes of equipment.)

Set up the db to use SSL only.  Set up the db to take per-user  
passwords.  Keep a file (or property) with secret things in it (plus  
an MD5 digest).  When the user runs the app, the secret things are  
opened up and checked.  It is decrypted with the user password.  In  
that is the host and port, the db password or cert (for this user),  
the data encryption key (if you insist), and the root cert for  
confirming the db connection.  The cert is written to a file.  The  
connection is made and the password is used to connect to the db.   
You know connection was made with the real db.  Erase the cert file.   
Continue the session.  (The public cert doesn't have to be secret.)

The db probably has lots of data consistency and data constraint  
features that you lose with encryption.

(IIRC, in Rev the host name used in making the SSL link must be the  
same as the one in the db cert.)

Now if you use the Rev db interface or some external to connect to  
the db, then the above suggestion would have to be adjusted (or  
thrown out) as needed.  Others can advise here better than I.

Dar




More information about the use-livecode mailing list