please tell me why this is stupid
ambassador at fourthworld.com
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. :)
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
More information about the Use-livecode