Unique Application Key

Question

I am creating a web service to allow application developers (my fiends LOL) to query my database. The thing is, as a security constraint i wanna be able to track each user. I am in the process of creating a unique app id like facebook or Google maps. Any help?

The developer must submit a user-name and email-address, when they click generate a unique key will be generated. The thing is, the database must first be checked if the user already exist/email and also check if the key is already generated (pseudo-random generation protection).

To use the webservice the user will have to enter something like

webservice.Authenticate('app key here');

to authenticate. any help? thanks

Answer 1

As far as I can tell Guid.NewGuid() should be sufficient.

Answer 2

Typical authentication consists on an identity (a name) and a secret (a password). You are designing an authentication scheme consisting on only a secret, ie. the password (in form of a guid). The problem with this approach (ie. not separating identity from password) is that the user cannot change the password if compromised, because the password is their identity.

What Maps API key and similar keys are something else: they are claims signed by the service provider. For example the registered domain from where your app is calling the Maps API. The Generate key accepts a domain you submit, will sign that domain name with a private key of the service and present you with the publis signature. When accessing the API you must present the signature (the API key) that prooves you have signed up and agreed to the terms of service. The other part of the verification (the domain your app is running from, in other words the 'claim') is detected automatically by JavaScript.

I'm by no means an expert on Maps API and I may had got some parts off, but this is typically how things are implemented. I would suggest against using a guid as an obfuscated application ID as it doesn't provide much value: a leaked guid can be used by anybody and you cannot verify any claim using a guid. Think about what are you trying to protect, or just go with an established scheme like OpenId or something.

Answer 3

Make a string out of a salt, the username, and the email address. Then make a hash (MD5 or SHA1) from that string. The salt can simply be userid, or it could be something else, as long as it isn't known to the user.

GUID is fine but it's probably overkill in this situation. Are you going to have billions of users? You could probably get by with a random number between 1 and 1,000,000. Then make sure you disable login after x number of failed attempts, where x is between 3 and 6.

Answer 4

If you go with the GUID solution - you can always make sure it is unique by querying the database. If it isn't unique - just generate a new one.

Answer 5

Depending on the size of your application and the number of users a Guid may not be the best choice unless you know how to handle them. Most often I have seen these used as strings, which only increases your storage requirement and slows down your comparison routines. A string comparison of a guid on a match has to scan all 36 characters. Way overkill for data which is just stored in hex format. Its better to save the GUID as an array of integers...you reduce the search while at the same time reducing the storage requirements.

If you only have a few thousand records, then guid as string is probably not going to matter much. But if your programming for scale, and that scale is large, then proper adjustments now will save you the pain of doing it later.

IF you are doing joins on tables, use an integer identity to do the join, not the guid (for the same reasons already mentioned).