determining if a stack is locked

[zryip theSlug]

2010/2/10 Richard Gaskin <ambassador at fourthworld.com>:
> With v4, the engine now uses a more secure method to secure scripts, but in
> my testing it has also removed any way to determine when a stack is
> password-protected without using "try".
>
> In versions prior to v4, you could do this:
>
>   if the password <> the passkey then ...
>
> The password and passkey returned an encrypted string which, while
> meaningless to the human reader, would at least allow comparisons of the
> password and passkey to determine if the passkey had been set in the current
> session, or if there is no password at all.
>
> In v4 and later, asking for the password or passkey returns simply "true",
> which might be sufficient but here's the rub:
>
> If you start a new session with a locked stack, asking for the password will
> return "true" which is correct, but asking for the passkey will also return
> "true" which is incorrect, since no passkey has yet been entered.
>
> I would expect that asking for the passkey of a stack that has a password
> would return "false" until a passkey has been entered in the current
> session.
>
>
> I discovered this with stacks in which the password had been set in a
> previous version, but I just confirmed it in v4 using this recipe:
>
> 1. Make a new stack
> 2. Set the stack's password
> 3. Run this in the Message Box:
>
>   put the password of this stack && the passkey of this stack
>
> You'll get "true true", which is appropriate because the stack's password
> was set in this current session and therefore its script is available.
>
> So now continue this test:
>
> 4. Save your stack and quit
> 5. Re-launch Rev, and re-open the stack
> 6. Run that command again in the Message Box
>
> RESULT: "true true", which seems inappropriate because the passkey has not
> been set and the stack's script cannot be accessed until it has.
>
>
> So this leads me to two questions:
>
> 1. Can anyone here spare a moment to confirm this behavior, and does it seem
> inappropriate to you?

I have follow all your steps and I can confirm that I obtained the
same results as you.

Inappropriate... Yes and no.

That the function returns true when the passkey is empty, this seems odd.
Now I think that for safety, less informations you have the better is it.

What it seems inappropriate to me is that when you set the wrong
passkey, you obtain an error.
I imagine already someone creating a loop that would try a password as
if it gets an error message.

In my opinion I believe that no message should be returned at any
time. If the password is good, it decrypts the stack and no more.


It's reminded me a story with my habitual development tool (no no it's
not RR, unfortunately ;)) which shall remain nameless for not
voluntarily give bad idea...

A few years ago, a client showed me how he was satisfied with the new
encryption system of this tool. It is true that in previous versions,
retrieve the password was a formality.
He was very happy with the feature that permitted to save a password
shortcut. This shortcut allowed users to connect to the server without
entering the user password...
The idea seems already strange to save a shortcut password in a file
accessible to everyone ... In addition, although internally encrypted
in the server, I discovered that the password was saved in clear text
in the shortcut...


Regards,

-- 
-Zryip TheSlug- wish you the best! 8)
http://www.aslugontheroad.co.cc