views:

89

answers:

5

I am writing an asp.net MVC app that drives an IPhone application.

I want the Iphone to send me its UUID looks like this:

2b6f0cc904d137be2e1730235f5664094b831186

On the server I want to generate a Guid:

466853EB-157D-4795-B4D4-32658D85A0E0

On both the Iphone and the Server I need a simple aglorithm to combine these 2 values into an Auth token that can be passed around. Both the IPhone and the ASP.NET MVC app need to be able to compute the value over and over based on the UUID and the GUID.

So this needs to be a simple algorithm with no libraries from the .net framework.

Full Solution Here

        public void Test()
        {    
            var DeviceId = Guid.NewGuid();
            var newId = "2b6f0cc904d137be2e1730235f5664094b831186";

            var guidBytes = DeviceId.ToByteArray();
            var iphoneBytes = StringToByteArray(newId);
            byte[] xor = new byte[guidBytes.Length];

            for (int i=0;i<guidBytes.Length;i++)
            {
                xor[i] = (byte) (guidBytes[i] ^ iphoneBytes[i]);
            }

            var result = ByteArrayToString(xor);               
        }

        public static byte[] StringToByteArray(String hex)
        {
            int NumberChars = hex.Length;
            byte[] bytes = new byte[NumberChars / 2];
            for (int i = 0; i < NumberChars; i += 2)
                bytes[i / 2] = Convert.ToByte(hex.Substring(i, 2), 16);
            return bytes;
        }

        public static string ByteArrayToString(byte[] ba)
        {
            StringBuilder hex = new StringBuilder(ba.Length * 2);
            foreach (byte b in ba)
                hex.AppendFormat("{0:x2}", b);
            return hex.ToString();
        }
+1  A: 

Well, the iPhone ID looks like a hex string, so converting both to binary and XORing the bytes ought to do it. You could store the result as an array, hex string, or base-64 encoded string as appropriate.

The way you refer to this as an "auth token" is a little concerning, however. Session ids must be unpredictable. You might consider generating an array of cryptographically random data on the server instead of a GUID.

Edit

// Convert the server GUID to a byte array.
byte[] guidBytes = severGuid.ToByteArray();

// Convert the iPhone device ID to an array
byte[] idBytes = StringToByteArray(iPhoneId);

Sadly, it seems .NET doesn't have a built-in method to convert to/from hex strings, but this subject has been covered before: Convert byte array to hex string and vice versa

// Once you've XORed the bytes, conver the result to a string.
string outputString = ByteArrayToString(outputBytes);
Peter Ruderman
I have added layers of security..this is really just to identify the client via a handshake.Can you give me an example in C#?
Climber104
An example of what? XORing the values together?
Peter Ruderman
Yes. Please...I know how to Xor ^ but i need help doing all the conversions.
Climber104
I've added an example of how to do the conversions.
Peter Ruderman
I derived the answer above from your example, thank you.
Climber104
+1  A: 

Rather than XORing, which loses information, you could just concatenate these hex digits.

Steven Sudit
Xor'ing doesn't lose data, it's completely reversible lightweight encryption, but +1 for concatenation :)
Doobi
@Doobi: I'm not sure what you mean. There's more information in 64 bits than in the XOR of 2 32-bit strings. It's not reversible except if you already know one of those 32-bit strings.
Steven Sudit
A: 

Why do you even need the GUID? The phone ID is unique, the GUID seems to add no value.

Doobi
Because that ID can be sniffed and spoofed. I need an ID that only lasts the lifetime of the session and is built by combining the session Guid from the server, which lasts for 20 min, and the UUID.
Climber104
A: 

I thought you can use two way algorithm. It mean the algorithm can be encode and decode like Base64, SHA256, AES

noneno
+1  A: 

Just as a side note, all the "auth token" mechanisms I've worked with (at least) concatenated a constant value (a "secret") with the current time, then hashed them together then sent the hash and the date. The server then reconstructed the hash from the received date and known "secret" and then compared to the received hash (signature). My point here was "concatenated with date" - this allows the resulting signature to be different every time which in theory should be more secure.

Cristian Vrabie
Thats a good idea. I think I will add that to my algorithm.
Climber104