Уникальный ключ приложения

Question

Я создаю веб-сервис, который позволяет разработчикам приложений (А.К.А., мои друзья) запрашивать мою базу данных. Дело в том, что в качестве ограничения безопасности я хочу иметь возможность отслеживать каждого пользователя. Я нахожусь в процессе создания уникального идентификатора приложения, как в FaceBook или Google maps.

Разработчик должен указать имя пользователя и адрес электронной почты, и при нажатии кнопки создать уникальный ключ будет сгенерирован. Дело в том, что сначала нужно проверить базу данных, если пользователь / электронная почта уже существует, а также проверить, сгенерирован ли уже ключ (защита от псевдослучайной генерации).

Чтобы использовать веб-сервис, пользователь должен будет ввести что-то вроде:

webservice.Authenticate («ключ приложения здесь»);

для аутентификации. Заранее спасибо.

Answer 1

Насколько я могу сказать, Guid.NewGuid() должно быть достаточно.

Answer 2

Если вы используете решение GUID - вы всегда можете убедиться, что оно уникально, запрашивая базу данных. Если он не уникален - просто сгенерируйте новый.

Answer 3

В зависимости от размера вашего приложения и количества пользователей Guid может быть не лучшим выбором, если вы не знаете, как с ними обращаться. Чаще всего я видел, что они используются как строки, что только увеличивает ваши требования к памяти и замедляет ваши процедуры сравнения. Сравнение строк гида по совпадению должно отсканировать все 36 символов. Путь избыточен для данных, которые просто хранятся в шестнадцатеричном формате. Лучше сохранять GUID в виде массива целых чисел ... вы сокращаете поиск и одновременно уменьшаете требования к хранилищу.

Если у вас всего несколько тысяч записей, то guid в виде строки, вероятно, не будет иметь большого значения. Но если вы программируете для масштаба, и этот масштаб большой, то правильные настройки сейчас избавят вас от необходимости делать это позже.

Если вы выполняете объединения для таблиц, используйте объединение целых чисел, а не guid (по тем же причинам, которые уже упоминались).

Answer 4

Создайте строку из соли, имени пользователя и адреса электронной почты. Затем сделайте хеш (MD5 или SHA1) из этой строки. Соль может быть просто идентификатором пользователя, или это может быть что-то еще, если она не известна пользователю.

GUID - это хорошо, но в этой ситуации он, вероятно, излишний. У вас будут миллиарды пользователей? Вы могли бы, вероятно, обойтись со случайным числом от 1 до 1 000 000. Затем убедитесь, что вы отключили вход после x числа неудачных попыток, где x находится между 3 и 6.

Answer 5

Типичная аутентификация состоит из личности (имя) и секрета (пароль). Вы разрабатываете схему аутентификации, состоящую только из секрета, т.е. пароль (в виде гида). Проблема с этим подходом (т.е. не отделяя идентификационные данные от пароля) состоит в том, что пользователь не может изменить пароль в случае его взлома, поскольку пароль равен их идентификатору.

Что такое ключ API Карт и подобные ключи - это что-то другое: это заявления, подписанные поставщиком услуг. Например, зарегистрированный домен, откуда ваше приложение вызывает API Карт. Ключ Generate принимает домен, который вы отправляете, подпишет это доменное имя закрытым ключом службы и предоставит вам подпись pubis. При доступе к API вы должны предоставить подпись (ключ API), подтверждающую, что вы зарегистрировались и согласились с условиями обслуживания. Другая часть проверки (домен, с которого запускается ваше приложение, другими словами, «претензия») автоматически обнаруживается JavaScript.

Я ни в коем случае не эксперт по API Карт, и, возможно, у меня есть некоторые детали, но, как правило, это реализуется. Я бы посоветовал не использовать guid в качестве замаскированного идентификатора приложения, так как он не имеет большого значения: утечка guid может быть использована кем угодно, и вы не можете проверить какие-либо претензии с помощью guid. Подумайте о том, что вы пытаетесь защитить, или просто используйте установленную схему, такую ​​как OpenId или что-то в этом роде.