Re: How about a module for "passwords"?

This sounds interesting, but may need to be more complex. Consider:

Can one ask for different passwords in a script (e.g the read passwd then the write passwd)? If so you need to specify which one in get_passwd
How does the provider know/authenticate who is asking? If I ask a file for a passwd, to whom does it give it up? Are OS read perms all we use?
Let's say the passwd is on a USB dongle. I need to provide a string to the dongle to check it. How do I do that?

Just a few things to think about.

--traveler

Comment on Re: How about a module for "passwords"? Download Code

Replies are listed 'Best First'.
Re: Re: How about a module for "passwords"? by John M. Dlugosz (Monsignor) on Jan 27, 2003 at 06:35 UTC
Just a few things to think about. Thanks. Can one ask for different passwords in a script? Yes, the idea all along was to have an identifier to correspond to the password of interest. I need to provide a string to the dongle to check it. How do I do that? The rough inkling I have at this point is that the identifiers will map to information specifying which concrete password module to use, and any other parameters it needs for that; e.g. the corresponding identifiers used by that particular system, such as database table row, registry key name, dongle slot. How does the provider know/authenticate who is asking? If I ask a file for a passwd, to whom does it give it up? Are OS read perms all we use? Well, it depends. Different concrete classes could do totally different things. The real value is to have a common abstract interface and central module to dispatch to the correct concrete module for that password. A simple nieve file-based table would rely on OS permissions, secure file system, or removable media to give it any real security. An implementation module could certainly prompt for a password or key itself. After reading the replies on this thread, I do see that the password getter object needs to have a state that can hold information for the concrete modules, so that (for example) the script's user can be authenticated once and then the key is remembered for the life of the script. —John	[reply]

Replies are listed 'Best First'.

Re: Re: How about a module for "passwords"?
by John M. Dlugosz (Monsignor) on Jan 27, 2003 at 06:35 UTC

Just a few things to think about.

Thanks.

Can one ask for different passwords in a script?

Yes, the idea all along was to have an identifier to correspond to the password of interest.

I need to provide a string to the dongle to check it. How do I do that?

The rough inkling I have at this point is that the identifiers will map to information specifying which concrete password module to use, and any other parameters it needs for that; e.g. the corresponding identifiers used by that particular system, such as database table row, registry key name, dongle slot.

How does the provider know/authenticate who is asking? If I ask a file for a passwd, to whom does it give it up? Are OS read perms all we use?

Well, it depends. Different concrete classes could do totally different things. The real value is to have a common abstract interface and central module to dispatch to the correct concrete module for that password. A simple nieve file-based table would rely on OS permissions, secure file system, or removable media to give it any real security. An implementation module could certainly prompt for a password or key itself.

After reading the replies on this thread, I do see that the password getter object needs to have a state that can hold information for the concrete modules, so that (for example) the script's user can be authenticated once and then the key is remembered for the life of the script.

—John

[reply]