please tell me why this is stupid

Richard Gaskin ambassador at
Fri Sep 2 14:00:46 EDT 2011

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:
  Webzine for LiveCode developers:
  LiveCode Journal blog:

More information about the Use-livecode mailing list