I've been thinking about this. I'm assuming (all with salt): 1. At some point the user set a password. At that point the iOS app applies MD-5, sends that to the server, and stores the hash locally.
2. When the app wants to access something from the server, it makes a request for an authentication string. The server takes the user name and the current time and sends that back,and stores that hash itself. The iOS app hashes the authentication string combined with the password hash, and includes that with its requests. Since both the server and the iOS app know the authentication string from (1), they do not have to exchange it now. Richard, is this something like what you're doing? Sent from my iPad On Apr 7, 2013, at 8:10 AM, John Craig <j...@splash21.com> wrote: > As an example, my requests to the server contain; > 1/ a uuid > 2/ current time > 3/ md5 hash of user credentials + uuid + time > 4/ any other data On Apr 7, 2013, at 4:54 PM, Richard Gaskin <ambassa...@fourthworld.com> wrote: > One method Dave Cragg, me, and others have used is a home-grown > quasi-HTTPS-like scheme in which the client first handshakes with the server > to obtain a token, which is a hash of the IP address, time stamp, and some > salt, and that token is used as a key to send the authentication data, after > which all other data uses a less derivable method. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
