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
_______________________________________________
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
