Re: Re: Please don't compromise my privacy

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

Comment on Re: Re: Please don't compromise my privacy

Replies are listed 'Best First'.
Re: Re: Re: Please don't compromise my privacy by Petruchio (Vicar) on Mar 06, 2001 at 06:26 UTC
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: Automatically allow access to a second site for anyone with a PerlMonks account, while maintaining the user's identity Allow this access in a way that was as transparent as possible to the user (ideally requiring no work on the user's part) Not give the proprietors of one external service any ability to masquerade as the user at another external service, and 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.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: Please don't compromise my privacy
by Petruchio (Vicar) on Mar 06, 2001 at 06:26 UTC

real

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:

Automatically allow access to a second site for anyone with a PerlMonks account, while maintaining the user's identity
Allow this access in a way that was as transparent as possible to the user (ideally requiring no work on the user's part)
Not give the proprietors of one external service any ability to masquerade as the user at another external service, and
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.

[reply]