Password Field

[Jim Carwardine]

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