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

Ответ 1

По-моему, ответ отрицательный.

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

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

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

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

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

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

Ответ 2

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

Ответ 3

Если можно увидеть отправленный GUID (например, через HTTP Auth), то это не имеет значения, насколько это возможно.

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

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

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

Ответ 8

Я рекомендую не использовать GUID в качестве пароля (за исключением, возможно, первоначального, который будет изменен позже). Любой пароль, который должен быть записан, чтобы быть запомненным, - неотъемлемо небезопасно. Это будет записано.

Изменить: "по сути" неточно. см. беседу в комментариях

Ответ 9

Это лучше, чем использовать "пароль" в качестве пароля, по крайней мере.

Я не думаю, что GUID будет считаться надежным паролем, и есть много надежных генераторов паролей, которые вы могли бы использовать так же легко, как Guid.NewGuid().

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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