Internal security of Rev?

[John Tregea]

Dar,

That is a valuable synopsis. I will go away now and get on with it... :-)

Thanks again. (to all)



Dar Scott wrote:
>
> 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
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>