No, there isn't, and one isn't likely to be added any time terribly soon. The reason is that the insecurity isn't in HTTP being cleartext, but rather in the cookies not being as opaque as they should be.
(If you're interested in changing that fact, level 7 or higher, and trustworthy, you might want to consider becoming a pmdevil.)
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] |
Making the cookie content more opaque wouldn't help. Snooping an opaque cookie is just as simple as snooping the login details or the plaintext cookie.
Moving to an expiring key based authentication system with a secure login would reduce the window of opportunity for highjacking. Encrypting everything over https makes it more secure (if, of course, you trust the gods and pmdev).
However, personally, for something like perlmonks I really don't think it's worth the effort or cost.
| [reply] |
Does it matter? What are you afraid of? Just don't use your realname.
or post anything that might reveal <dramatic music>your true identity!
And don't get hung up about XP. If you do those things why would you care if
someone was to spoof your perlmonks login?
| [reply] |
This thread isn't going where i expected it to go. Identity theft is a problem imho and personally i expected the elite perl hackers® to recognize that. It's true that the original poster had a weak argument in the 'trustworthyness' of the code posted, but identitytheft is something any programmer should be aware of.
On a practical side: the way the login system is set up now (with the cookie) would not be secure over http after a login over https. So that would require some modification. | [reply] |
I guess this is a wrong solution for a correct problem. The solution I decided a while ago, includes signing the code I upload to CPAN with GPG, so that people can verify it. This still gives no assurance so as to the potentially malicious intent that a given author might have, but allows users to authenticate the code properly.
Best regards
-lem, but some call me fokat
| [reply] |
