Internal security of Rev?
dsc at swcp.com
Thu Jul 13 17:39:05 EDT 2006
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,
> 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
Why not a global? If the file gets saved, you don't want them in
> 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
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
> 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
> 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
More information about the Use-livecode