Internal security of Rev?

[Dar Scott]

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