Password Field
Jim Carwardine
JimCarwardine at OwnYourFuture-net.com
Wed Jan 21 20:57:14 EST 2004
I have an idea for this application...
I created 2 identical fields. I placed field 2 exactly on top of field 1
and locked field 2. I put this script in field 2 (the top field)...
on mouseUp
select line 1 of field 1
end mouseUp
on mouseDown
put empty into me
put empty into field 1
end mouseDown
Then I put this script on field 1...
on keyDown
put "*" after line 1 of field 2
pass keyDown
end keyDown
You can then lock everything down and a user would need a can opener to see
the password... Jim
on 1/21/04 9:26 AM, Rob Cozens wrote:
>> Well, I ended up taking a different tack on the password field
>> thing. Although the solutions given will work in most cases I
>> decided to go the route of setting the foreground, background and
>> hilite color of my password field to white then disallowing the
>> "copy" function (Cmd-C, Ctrl-C) so that no one can select the
>> entered text, copy it to the clipboard then paste it into something
>> else in order to obtain the password. In the end this ended up
>> being easier than trying to (1) figure out all the possible ways
>> someone can "get" the password and (2) ensure that whatever someone
>> does with the mouse or keyboard, the entered password is correct
>> (i.e. what if they use the mouse to select some of the "dots" in the
>> field and remove them ... it was just getting too complicated).
>
> Hi Brian,
>
> I got into this thread a little late, so forgive me if this has been
> addressed.
>
> The general approach to passwords is via an ask password dialog box
> instead of a field. The ask password command takes care of all the
> details you are struggling with when trying to replicate a password
> dialog in a field.
>
> As part of this approach, the password is never unencrypted: Sys
> Admin creates a password via the ask password dialog, hides the
> result in the application, and tells the user what keys to press when
> responding to ask password. Password verification involves comparing
> the user's response to ask password with the encrypted response
> stored in the application.
>
> Note that the user input is never derived by unencrypting the ask
> password response.
>
> So I ask:
>
> 1. Is it necessary that the password be entered in a field instead
> of via the ask password dialog?
>
> 2. Is there a reason why you need to know what keys the user pressed
> (eg: the user is entering "secure" data instead of a predefined
> password)?
>
> If you answer both questions in the negative, I suggest you look at
> ask password syntax.
--
OYF is... Highly resourceful people working together.
<http://www.OwnYourFuture-net.com>
Own Your Future Consulting Services Limited,
1959 Upper Water Street, Suite 407, Halifax, Nova Scotia. B3J 3N2
Info Line: 902-823-2477, Phone: 902-823-2339. Fax: 902-823-2139
More information about the use-livecode
mailing list