Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Please don't compromise my privacy

by Petruchio (Vicar)
on Mar 06, 2001 at 00:43 UTC ( [id://62339]=note: print w/replies, xml ) Need Help??


in reply to Please don't compromise my privacy
in thread On Chatterbox Echoes, and the Identification of Monks in the Wild

However, if I'm reading your subtext properly, you want to ID Monks without their knowledge and that raises several concerns.

Happily, this is the only point I need to respond to. This is not at all what I mean. I would not support, much less suggest, anything which would compromise the privacy of people here... especially mine. ;-)

What I mean is simply this: if each Monk had the option to specify a second, secret password, he could use that password to verify his identity outside the site, without giving up his primary password. That is all. There is no connection with anyone's real identity.

So, for instance, I set up another website, Perlmonks' Bar & Grille. You wish to get in. You supply your normal username, footpad, and your secondary password. My login CGI sends the pair to a CGI on Perlmonks, recieves a "YES" back, and lets you in. Without your needing to divulge your real password, and compromise your PerlMonks account,

It seems that the word "automatic" (and probably some unclarity on my part) gave you a different impression. I meant it in reference to the way authentication is implemented. By having set your secondary password, you now automatically have access to my web site. This scheme has various strengths and shortcomings (as do other schemes) but it is totally voluntary, and not at all injurious to personal privacy.

Sorry if I mislead you.

Replies are listed 'Best First'.
Re: Re: Please don't compromise my privacy
by Albannach (Monsignor) on Mar 06, 2001 at 01:24 UTC
    This seems pretty limited to me. Once a monk has given you their ID and 2nd password, you could effectively imitate them anywhere outside the Monastery. This means that monks would have to be very careful with this second password, making it little more useful than the first for ID purposes.

    How about this: A person claims to be Petruchio, and wants an account on my site as such. I simply use the Monastery to /msg a monk of that name with a default password for his/her/its account on my site et voilą. No extra work for anyone, and the ID verification is as good as your primary password here. Even if someone who isn't a monk wanted to do verifications (seems unlikely ;-) they'd merely join the Monastery and they'd have the same ability. This also provides an automatic mechanism for a monk to know that someone is trying to impersonate them elsewhere ("/msg Albannach what the heck is this password for?").

    --
    I'd like to be able to assign to an luser

      You're quite right, it is limited. On the other hand, it allows the user, and only the user, to change his password at any time also, so stealing the password will be of very limited value as well. And it seems a trivial limitation when real passwords could be harvested so easily around here.

      Your suggestion would also work, and is a bit more efficient than what tilly had suggested. Since under my scheme the user could be assigned, or forced to adopt, a new, local password upon first authentication, the only real difference is the level of automation.

      Also, with your scheme, there is extra work for someone... the person who must automate the /msg. If this seems trivial, then consider also the difficulty of adding a single textbox to a form, a single field to a database table, and what must be close to the simplest of all CGI programs.

      But yes, what I have suggested is quite limited, and what you have suggested is a very comparable scheme. Perhaps more interesting would be to consider the real objectives. A great scheme, as I think of it, would:

      1. Automatically allow access to a second site for anyone with a PerlMonks account, while maintaining the user's identity
      2. Allow this access in a way that was as transparent as possible to the user (ideally requiring no work on the user's part)
      3. Not give the proprietors of one external service any ability to masquerade as the user at another external service, and
      4. Be easily implemented, whether by vroom or someone else (more important if it's vroom).

      My suggestion achieves 1, 2 and 4, with the ability to change passwords limiting the problem of failing to achieve 3.Yours achieves 1, 3 and 4, and while it's less efficient on 2, it's not that bad on that account. I wonder whether we can come up with something which achieves all 4.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://62339]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2024-03-29 01:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found