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. > > So please help me out: why is this a stupid idea? I'd like to know too. Cheers Dave _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
