|
|
Posted by Jerry Stuckle on 09/05/07 16:02
Sanders Kaufman wrote:
> C. wrote:
>> On 5 Sep, 11:00, Sanders Kaufman <bu...@kaufman.net> wrote:
>
>>> It can be done, but it's a monumental task that duplicates processes
>>> already established in the industry.
>>>
>>> It's called Public Key Encryption.
>>>
>>
>> 1) that's not really the solution to the OP's problem - presumably he
>> doesn't control the remote end to get the authentication system re-
>> written. The only sensible reason for using a 13 digit single use
>> password is to prevent leeching - it should be *very* straightforward
>> to strip this from the responses - I don't understand why the OP
>> thinks it's a problem.
>
>
> Because it puts the "secret code" in the HTML for the client's browser -
> effectively publishing it to the world.
>
> The kind of security he's asking for is not possible. To solve his
> problem, he'll have to ditch his current method, and implement a PK
> scheme of some sort.
>
>
>> 2) Client side certificates are *not* a monumental task - they're very
>> easy to implement - not least because of the likes of cacert.org
>> providing a free CA service.
>
> No - that's not monumental.
> But rolling your own CA system would be.
> The hardest part would probably be negotiating a partnership agreement
> with Dow Jones.
Maybe I misread it, but it sounds like the op wanted to use CURL to
fetch a page which has the 13 digit code on it (which changes every
time), not create a page with the code.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|