You might also want to consider a simplification of the trick that Salseforce.com uses (albeit in their case, on top of SSL & username/password authentication) when a user logs in via an unknown machine (my guess is 'unknown IP address').
The successful login is followed by a dialogue to send an authentication code. Clicking the button triggers the server to send a random number string to the user's registered email address (to which they should have access from the machine they're using to login). Once typed-in, some kind of session token/cookie or whatever is created for that machine for subsequent logins. This hand-shaking process could be simplified for your peer-to-peer scenario - or you could add an authentication server into the mix for initial application registration and set-up (which would also help track who is using the app and intercept for updates, etc)? Best, Keith.. On 2 Sep 2011, at 19:00, Richard Gaskin wrote: > 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
