Использует ли безопасность GUID, хотя неизвестность?

Question

Если вы используете GUID в качестве пароля для общедоступного приложения в качестве средства для получения доступа к сервису, является ли это безопасностью из-за неясности?

Я думаю, что очевидный ответ - да, но уровень безопасности мне кажется очень высоким, так как шансы угадать GUID очень и очень низки верны?

Обновление

GUID будет храниться на устройстве, при подключении будет отправлять через GUID через SSL-соединение.

Может быть, я мог бы сгенерировать GUID, затем выполнить 128-битное шифрование AES для GUID и сохранить это значение на устройстве?

Answer 1

На мой взгляд, ответ - нет.

Если вы устанавливаете пароль для вновь созданного GUID, то это довольно безопасный пароль: более 8 символов, содержит цифры, буквы и специальные символы и т. Д.

Конечно, в GUID известны позиции '{', '}' и '-', а также тот факт, что все буквы в верхнем регистре. Так что, пока никто не знает, что вы используете GUID, пароль сложнее взломать. Как только злоумышленник узнает, что он ищет GUID, усилие, необходимое для атаки грубой силой, уменьшается. С этой точки зрения, это безопасность по неизвестности .

Тем не менее, рассмотрите этот GUID: {91626979-FB5C-439A-BBA3-7715ED647504} Если вы предполагаете, что злоумышленник знает положение специальных символов, его проблема сводится к поиску строки 91626979FB5C439ABBA37715ED647504. Грубый форсирование пароля из 32 символов? Это произойдет только при вашей жизни, если кто-то изобрел работающий квантовый компьютер.

Это защита с использованием очень и очень длинного пароля , а не по неясности .

EDIT: Прочитав ответ Дени Хеннесси, я должен пересмотреть ответ. Если GUID действительно содержит эту информацию (в частности, MAC-адрес) в расшифрованной форме, злоумышленник может значительно уменьшить пространство ключей. В этом случае это определенно будет безопасность по неизвестности , читайте: довольно небезопасно .

И, конечно, MusiGenesis прав: существует множество инструментов, генерирующих (псевдо) случайные пароли. Я рекомендую придерживаться одного из них.

Answer 2

На самом деле, использование GUID в качестве пароля не очень хорошая идея (по сравнению с получением действительно случайного пароля эквивалентной длины). Хотя он выглядит длинным, на самом деле это всего 16 байт, которые обычно включают MAC-адрес пользователя, дату / время и небольшой случайный элемент. Если хакер может определить MAC-адрес пользователя, довольно просто угадать возможные GUID, которые он сгенерирует.

Answer 3

Если можно наблюдать отправку GUID (например, через HTTP-аутентификацию), то не имеет значения, насколько он угадан.

Некоторые сайты, такие как Flickr, используют ключ API и секретный ключ. Секретный ключ используется для создания подписи через хеш MD5. Сервер вычисляет ту же самую подпись, используя секретный ключ, и выполняет аутентификацию таким образом. Секрет никогда не должен идти по сети.

Answer 4

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

Answer 5

Сначала я был готов дать безоговорочное да, но это заставило меня задуматься о том, означает ли это, что ВСЕ аутентификация на основе паролей является безопасностью по неясности. В самом строгом смысле, я полагаю, так или иначе.

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

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

Answer 6

Как правило, вы вводите уязвимости безопасности, если вы вставляете ключ в свое устройство или если вы передаете ключ во время аутентификации. Не имеет значения, являются ли они ключом GUID или паролем, поскольку единственное криптографическое различие заключается в их длине и случайности. В любом случае злоумышленник может либо просканировать память вашего продукта, либо прослушать процесс аутентификации.

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

• Зашифруйте ключ, прежде чем хранить его. Конечно, теперь вам нужно хранить этот ключ шифрования, но вы ввели уровень косвенности.

• Вычислять ключ, а не хранить его. Теперь злоумышленник должен перепроектировать ваш алгоритм , а не просто искать ключ.

• Передайте хэш ключа во время аутентификации, а не сам ключ, как предлагали другие, или используйте вызов-ответ аутентификация. Оба эти метода предотвращают передачу ключа в виде открытого текста. SSL также выполнит это, но тогда вы зависите от пользователя, чтобы поддерживать правильную реализацию; Вы потеряли контроль над безопасностью .

Как всегда, всякий раз, когда вы обращаетесь к безопасности, вам необходимо учитывать различные компромиссы. Какова вероятность атаки? Каков риск 1038 *, если атака успешна? Какова стоимость безопасности с точки зрения разработки, поддержки и удобства использования?

Хорошим решением обычно является компромисс, который удовлетворительно учитывает каждый из этих факторов. Удачи!

Answer 7

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

Я бы также гарантировал, что вы выполняете какую-то взаимную аутентификацию (т. Е. Устройство проверяет SSL-сертификат сервера, чтобы убедиться, что это тот, который вы ожидаете). Мне было бы достаточно легко захватить устройство, подключить его к моей системе и прочитать с него GUID, а затем воспроизвести его обратно в целевую систему.

Answer 8

Это только безопасность через неизвестность в той степени, в которой это пароли. Вероятно, основная проблема с использованием GUID в качестве пароля заключается в том, что используются только буквы и цифры. Однако GUID довольно длинный по сравнению с большинством паролей. Ни один пароль не является безопасным для исчерпывающего поиска; это довольно очевидно. Просто потому, что GUID может иметь или не иметь какую-то основу на какой-либо метке времени или, возможно, MAC-адрес несколько не имеет значения.

Разница в вероятности угадать это и что-то еще довольно минимальна. Некоторые GUID могут быть «проще» (читай: быстрее), чем другие. Дольше, тем лучше. Тем не менее, больше разнообразия в алфавите также лучше. Но опять же, исчерпывающий поиск раскрывает все.

Answer 9

Конечно, это безопасность по неизвестности. Но так ли это плохо? Любой «надежный» пароль - это безопасность по неизвестности. Вы рассчитываете на безопасность системы аутентификации, но, в конце концов, если ваш пароль легко угадать, не имеет значения, насколько хороша система аутентификации. Таким образом, вы делаете «надежный» и «неясный» пароль, чтобы его было трудно угадать.

Answer 10

Это действительно зависит от того, что вы хотите сделать. Использование GUID в качестве пароля само по себе не является безопасностью из-за неясности (но следует помнить, что GUID содержит много предположительных битов из общего числа 128: есть временная метка, некоторые включают MAC-адрес компьютера, который ее сгенерировал, и т. Д.) но реальная проблема заключается в том, как вы будете хранить и передавать этот пароль на сервер.

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