What's the best way to store data that one iOS app sends to another?

Geoff Canyon gcanyon at gmail.com
Mon Apr 8 11:37:40 EDT 2013


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 <john at 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 <ambassador at 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.




More information about the use-livecode mailing list