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