Hi again Dar,
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.
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.
In many cases the server will only host a private network of 6 to 8
clients connecting to a dedicated gigabit ethernet switch. The
client/server connections will use 128 bit SSL connections. If the
system is integrated with an organisations existing network, a hardware
encryption router will be placed at each user terminal and at the server
connection to the network.
I could do as has been suggested in this thread and use a CGI to talk to
the database, but I hesitate to commit to another technology in the mix.
Partly cause I would have to learn it. :-)
Maybe Python or SOAP for the initial login and then hand the secure
session back to Revolution?
> If the data needs to be encrypted by the clients and decrypted by
the clients, then you might as well use a secret key. You can >
have the key kept at the client or kept at a key server. In the
first case, it needs to be encrypted with a user password
> (optionally mixed with your obfuscated application key) or
derived from it (and optionally mixed).
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.
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).
Regards
John T
Dar Scott wrote:
On Jul 12, 2006, at 6:20 PM, John Tregea wrote:
Thanks for your extensive reply. The point you raised about info
leaks through memory was one of my two concerns, the other was what
could be seen by 'peaking' into the built application.
In the latter case, you are using a hardwired password. From my
understanding of your recent mail, you don't want to do that. Well,
not completely.
I guess I can overwrite the memory variables I use by setting them to
empty at the end of each handler.
First put a string of the right length into char 1 to -1 of the key.
That will write over the key in RAM. Now you might have inadvertently
made copies by then.
I planned to do that when the user logs out anyway. I also was going
to store the variables in custom properties (in encrypted form)
during the session and set them to empty at the end of a session.
Why not a global? If the file gets saved, you don't want them in
properties.
Really there is just two things that have to be stored in the Rev
side of the solution. That is the login user name and password for
the postgreSQL database. Once the connection is made through that
default account, there is a two, three or four factor validation
process from within POstgreSQL.
If the user login is not used for data encryption, you do not need to
keep any copies anywhere. Use a digest such as MD5. Even then you
might need to have an ephemeral copy after it is keyed in, but there
are ways to avoid that.
You can prevent entering of the db password until the user login is
complete.
Earlier you had mentioned encrypting of data in the db at the client
end. If the user does not supply the password for that, then it is
essentially and extension of your program and is as vulnerable as that.
I realised that I may be able to use the location of certain objects
within the front end to build the key. The objects never move in
relation to each other and the resulting string of numbers would be a
perfectly hidden string.
maybe something like
repeat with x = 1 to the number of btns put char 1 of the short
name of btn x & item 1 of the loc of btn x after tTheKey
if length(tTheKey) > 16 then exit repeat
end repeat
put char 1 to 16 of tTheKey into tTheKey
-- the key would end up something like b234t256h678f67u (a 128 bit key)
?
I would have to be careful that the stack window never has a new
button inserted at a low layer in subsequent versions, or the clients
would lose there data decrypt capability :-)
You can put a little time into obfuscation, but I wouldn't put a lot
into it. If this is used to hide the data encryption key, then your
encryption is no better than a light scrambling. If this level is
fine, then this approach is fine.
The above method has the cool feature of being a sort of application
digest, though.
Any thoughts?
Consider these questions. The answers might affect your approaches.
Is the server physically secure? Is the client computer physically
secure? The network between? Is there a risk of eavesdropping on the
network? Is there a risk of man-in-the-middle on the network? Is
there a risk of a fake login to the db server? Will people lose the
ability to log in and access data? Why does the data need to be
encrypted at the client? What encryption does the db support? What
are the actual standard requirements? Are redundant layers needed?
If the data needs to be encrypted by the clients and decrypted by the
clients, then you might as well use a secret key. You can have the
key kept at the client or kept at a key server. In the first case, it
needs to be encrypted with a user password (optionally mixed with your
obfuscated application key) or derived from it (and optionally
mixed). In the second case, you still need a user password. The
second case might allow for encryption password management and handle
login and db password management, too. You can also break up the data
into encryption zones and only provide the keys for the zones used by
that user.
You said it yourself. Believe it. If you hide the key using
scrambling level obfuscation, then you reduce your mil-grade
encryption to scrambling level. You can claim little about the
encryption.
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
