Internal security of Rev?

John Tregea john at debraneys.com
Thu Jul 13 20:50:20 EDT 2006


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
> 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
>
>



More information about the Use-livecode mailing list