Um, yeah. Instead of authenticating to Yahoo or Slashdot, I suggest you authenticate against somewhere like PayPal or Charles Schwab. At least that way you've got some chance of recouping your investment of time and energy.
Seriously though, this seems both insecure (who's going to send a username/password from one service to authenticate on another?) and pointless (it's not all that difficult to learn how to use crypt or Digest::SHA1 or whatever). Can I ask what do you hope to achieve with this scheme?
| [reply] |
I'd roll your own if I were you. Also, please warn me in
advance which sites you are doing this to so I can avoid
them. No offense intended but what you are asking to do
is evil on so many axes that I can't even calculate the
dimensionality of the evil, let alone the volume...
Honestly, I'd rather you store the password than
send it back out of your network...
--
$you = new YOU;
honk() if $you->love(perl) | [reply] |
ah, this made me smile :)
I'm just experimenting, and I know how to roll my own, but I
just thought it would be neat to be able to utilize existing
user bases so somebody could use a previously existing account
and password.
Little did I realize the indignation I would incur ;)
| [reply] |
| [reply] |
Dear dshahin,
when you say:
<cite>"This may seem trivial and/or insecure to some"</cite>
I have to say that there is no black or white or at least no clear border between them.
As you can't read cookies set by any other server you will need to connect to that other server and you will have to get the verification back - otherwise it would be sent to the client which seems useless for your approach.
Security is always the most important concern: so what will happen? You give the verification service provider support to keep track of the users behaviour - would you like to? Would your users like you to do so as well?
Even if the provider of such a service does not intend to use this kind of information - would you rely on his systems security and would you deny the risk of his system being hacked and all the information being stolen???
So better think about persistent cookies if you are just about to store user preferences such as colour schemes or display orders etc.
But if you wan't your users to trust you in the way they give you (personell) information you will have to implement and use SSL and encryption (such as strong as PGP) in the most effordable way by yourself.
Have a nice day
All decision is left to your taste | [reply] |
My only suggestion is build your own auth scheme. I'd never give my password to one site to a different site. If they were partnering on something, they could probably do this without my help.
Also, even if it's technically possible, I consider it abusive to force this sort of thing on the other site unless they explicitly agree to it. | [reply] |