please tell me why this is stupid

Keith Clarke keith.clarke at clarkeandclarke.co.uk
Fri Sep 2 15:03:20 EDT 2011


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





More information about the use-livecode mailing list