please tell me why this is stupid

[Richard Gaskin]

Thanks for chiming in, Dave:

> On 2 Sep 2011, at 16:33, Richard Gaskin wrote:
>
>> So it occurs to me that before the authentication data is sent, the first request to the server app could be to ask for a token.  This token would be a hash (probably SHA1) of the client app's IP address, the time in millisecs, and other arbitrary data.
>
> Why not just a random string as the token? If the client passes in an identifier with the request (e.g. username), the server can store the token alongside the identifier.
>
> I do something similar, but just for authentication over a non-secured line. It has two stages:
>
> 1a. Client requests "login token" (submits user identifier with request)
> 1b. Server returns random string (and stores alongside identifier)
> 2a Client submits credentials that are hashed with the login token. (also sends in same identifier as in 1)
> 2b. If authenticated, client returns a "service token". This is used in all subsequent service calls to the server.

Looks like we're walking similar paths.  I added IP and time stamps to 
the arbitrary data as additional precautions, but the core principle 
sounds very much the same.

>>
>> So please help me out:  why is this a stupid idea?
>
> I'd like to know too.

Nice to know I'm in good company on schemes like this. :)

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv