Protecting key data
Tereza Snyder
tereza at califex.com
Sat Dec 16 11:03:02 EST 2006
On Dec 16, 2006, at 7:57 AM, Richard Miller wrote:
> We're already setting the password of the main stack, so its script
> data is encrypted. But this main stack has more than 50 sub-stacks,
> and unless a password is set for every one of those stacks (which
> may be necessary), anyone can see the scripts of those stacks. So
> it would appear necessary to set a password for every substack that
> contains important data.
>
> A bigger problem is that we're putting the IP info into a global
> variable so it can be accessed throughout the application. That IP
> address is currently contained in a custom property in the main
> stack, which.... even though it is password protected... can be
> easily accessed through the message box, even before the password
> is entered. No security there.
>
> Seems one route is to put the IP address into the script of some
> object in the main stack. This way, there's no way to get at it
> without the password. But it becomes a bit of a pain to reference
> that IP throughout the application, other than the long way (put
> the script of object x of cd x of stack x.....).
>
> Is there a better approach?
>
I have never dealt with this myself, but one approach that occurred
to me is to store the data in a passworded script like so:
constant kPassWord="MyPassWord", kIP="192.168.0.100"
Access it in your application by providing, in the same script, a
getprop handlers like so:
getprop uPassWord
return kPassWord
end uPassWord
getprop uIP
return kIP
end uIP
... which you invoke with statements like:
put the uIP of stack "MyMainStack" into tIP
put the uPassWord of stack "MyMainStack" into tPassWord
-- do something with tIP and tPassWord
If tIP and tPassWord are local to the handler in which they are used,
they'll not be floating around in globals.
You can exclude message box access by including, in the getprop
handlers:
if not( the target contains "message field" ) then ...
I'm sure the security gurus have better answers, but I couln't hold
myself back!
t
--
Tereza Snyder
Califex Software, Inc.
www.califexsoftware.com
More information about the use-livecode
mailing list