On 8/11/06, Jyrki Pulliainen <[EMAIL PROTECTED]> wrote: > > On 8/11/06, Felix Ingram <[EMAIL PROTECTED]> wrote: > > > > On 8/10/06, Jyrki Pulliainen <[EMAIL PROTECTED]> wrote: > > > On 8/10/06, Felix Ingram <[EMAIL PROTECTED]> wrote: > > > > On 8/10/06, hernan43 <[EMAIL PROTECTED]> wrote: > > > > > Nowadays(is that a word?) a lot of fancy web services use API keys to > > > > > allow an individual access to a service without requiring a username > > > > > and password. Google, flickr(I believe), Akismet, so on and so on. > > > > > > > > > > If I wanted to make a Django app that utilized a custom authenticator > > > > > and my own "API key" what would be the best way to generate unique API > > > > > keys for my app. Would running a md5/sha sum on username + > > > > > randomstring > > > > > + email be safe? Or is that stupid thinking? > > > > > > > > Why not just 'randomstring'? I assume you'd be storing it anyway. > > > > Tagging on username and email doesn't give you anything extra. > > > > > > Plain random string would make it possible (though not likely) to have > > > two accounts with same API-key. That's why some personal data should > > > be inserted in to the API-key (like username+random through SHA) > > > > Sorry but that's just wrong. There's an equal chance that > > sha(username+random) will generate two identical API numbers. SHA does > > not 'add' randomness and adding username does not ensure you'll get > > different results. > > > > No, SHA does not add randomness, but that really was not the point. > The point is, that when having unique usernames per user, the start > (for example the first 8 letters) of the original string already > differs. To make it harder (almost impossible) to guess, we also can > append some additional (say, for example, 20) random characters to the > end of the string.
Since the original poster wanted a unique key to use without a username we just want a random string. Seeing as how we're using a random string to prevent someone guessing another user's key then why bother adding anything else? > This way you propably can be quite sure, that the > strings are never going to collide (except in case SHA collides), a > 'security' random string cannot provide You cannot say that at all. Either the random string we're adding to the username is random (in which case collisions are just as likely as with SHA, maybe even less likely, it depends on the random generator) or it's not. In that case you should pick one that is. Hashing functions have the property that small changes in the input will not result in small changes in the output. > The hashing algorithm really doesn't matter, but the fact is that the > SHA is more secure than MD5, less likely to collide. SHA is 'more secure' than MD5 if two ways. 1. The output is longer. The only way MD5 is more likely to collide is due to the length of the output. While the output of MD5 is only 128 bits, you'll find that this is long enough for API keys. 2. MD5 is 'broken' MD5 is broken in the following way: given an input and its MD5 hash someone can find another input that will give you the same output. I.e. _finding_ collisions is easier (grossly simplified explanation) Neither of these reasons apply to our problem. If you want a random string then use a random string. If you are worried about collisions then pick a longer string or perform a check and generate another. Felix --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
