Реализация безопасных, уникальных URL активации “единственного использования” в ASP.NET (C#)
Если вам действительно нужно это сделать, то закодируйте как данные. Я просто создал новое поле под названием receive как NSData (двоичные данные).
Затем в реализации NSManagedObject:
-(void)setReceiveList:(NSArray*)list{
self.receive = [NSKeyedArchiver archivedDataWithRootObject:list];
}
-(NSArray*)getReceiveList{
return [NSKeyedUnarchiver unarchiveObjectWithData:self.receive];
}
5 ответов
- Да, 2 128 - это достаточно долго.
- Нет, реализации GUID предназначены для генерации уникальных идентификаторов GUID, а не случайных. Вы должны использовать криптографически безопасный генератор случайных чисел (например,
RNGCryptoServiceProvider) для генерации 16 случайных байтов и инициализации структурыGuidс этим. - Да, это приемлемый подход в целом. Оба будут работать.
- Да, если вы не дадите никаких других подсказок
- Нет,
goto 2 - Нет, это нормально. Вам просто нужно использовать криптографически безопасный генератор случайных чисел для генерации GUID.
Это может быть излишним, но вы можете хешировать их адрес электронной почты с помощью SHA1 , используя ваш guid (подойдет NewGuid) в качестве хэш-соли и поместите его в URL. Затем, когда они перейдут на вашу страницу, вы можете спросить их адрес электронной почты, получить guid и пересчитать хэш для проверки. Даже если бы кто-то знал, какие адреса электронной почты попробовать, они никогда не смогли бы сгенерировать хэш-коллизию, не зная, с каким гуидом вы солили (или это заняло бы у них адски много времени :). Конечно, вам придется сохранить их электронную почту и хэш-соль в базе данных.
но вы можете хешировать их адрес электронной почты с помощью SHA1 , используя свой guid (NewGuid подойдет) в качестве хэш-соли и поместить его в URL. Затем, когда они перейдут на вашу страницу, вы можете спросить их адрес электронной почты, получить guid и пересчитать хэш для проверки. Даже если бы кто-то знал, какие адреса электронной почты попробовать, они никогда не смогли бы сгенерировать хэш-коллизию, не зная, с каким гуидом вы солили (или это заняло бы у них адски много времени :). Конечно, вам придется сохранить их электронную почту и хэш-соль в базе данных. но вы можете хешировать их адрес электронной почты с помощью SHA1 , используя свой guid (NewGuid подойдет) в качестве хэш-соли и поместить его в URL. Затем, когда они перейдут на вашу страницу, вы можете спросить их адрес электронной почты, получить guid и пересчитать хэш для проверки. Даже если бы кто-то знал, какие адреса электронной почты попробовать, они никогда не смогли бы сгенерировать хэш-коллизию, не зная, с каким гуидом вы солили (или это заняло бы у них адски много времени :). Конечно, вам придется сохранить их электронную почту и хэш-соль в базе данных. Даже если бы кто-то знал, какие адреса электронной почты попробовать, они никогда не смогли бы сгенерировать хэш-коллизию, не зная, с каким гуидом вы солили (или это заняло бы у них адски много времени :). Конечно, вам придется сохранить их электронную почту и хэш-соль в базе данных. Даже если бы кто-то знал, какие адреса электронной почты попробовать, они никогда не смогли бы сгенерировать хэш-коллизию, не зная, с каким гуидом вы солили (или это заняло бы у них адски много времени :). Конечно, вам придется сохранить их электронную почту и хэш-соль в базе данных.Во-первых, если возможно, вы должны ограничить грубую силу, ограничив пропускную способность запроса (например, ограниченное количество попыток на IP в секунду и ограниченное общее количество попыток в секунду).
В зависимости от Алгоритм генерации GUID, возможно, это не лучшая идея. Хотя недавние реализации должны быть «обычно достаточно хорошими», их значения могут быть очень предсказуемыми. Недавние реализации, такие как та, которая используется в .NET, применяют хэш, в противном случае у вас есть четко идентифицируемые поля для MAC-адреса и времени с момента загрузки. Однако возможные значения ограничены, поэтому у вас нет истинных 128 случайных битов.
Если безопасность является главным приоритетом, я бы выбрал криптографически стойкий генератор случайных чисел и построил строку случайных символов.
- Нет, идентификаторы GUID не являются полностью случайными, и большинство битов либо статичны, либо их легко угадать.
- Нет, они не случайны, см. 1. На самом деле существует очень небольшое количество битов, которые на самом деле случайны, и при этом не являются криптографически стойкими случайными.
- Это не так, см. 1 и 2.
- вы можете, но не нужно ... увидеть мое решение в конце.
- Нет, см. 1 и 2
- Да.
То, что вы должны использовать вместо GUID, - это криптографически стойкое случайное число генератор - используйте System.Security.Cryptography.RNGCryptoServiceProvider , чтобы сгенерировать длинную (скажем, 32 байта) строку данных, затем кодируйте base64 это.
Кроме того, предполагая, что это какая-то регистрация с конфиденциальными данными, вы захотите ограничить срок действия ссылки, скажем, 60 минутами или 24 часами - в зависимости от вашего сайта.
Вам нужно будет сохранить сопоставление этих значений с конкретными пользователями. Затем вы можете автоматически предоставить ему соответствующую форму по мере необходимости. Не нужно перезаписывать URL, просто используйте его как идентификатор пользователя (на этой странице).
Конечно, не забывайте, что этот URL-адрес должен быть HTTPS ...
Между прочим, просто примечание - это хорошая практика - помещать в электронное письмо текст в той или иной форме, объясняя, что пользователи не должны переходить по ссылкам в анонимных электронных письмах, и обычно на вашем сайте не будет отправлять, и они никогда не должны вводить свой пароль после нажатия кнопки blablabla ....
О, чуть не забыл - еще одна проблема, которую вы должны рассмотреть, это то, что происходит, если пользователь хочет, чтобы ему было отправлено несколько писем, например, несколько раз регистрируются обращения. Может ли он делать это снова и снова и получать много действительных URL-адресов? Действителен только последний? Или, может быть, одно и то же значение снова и снова вызывает недовольство? Конечно, если анонимный пользователь может отправить запрос на это электронное письмо, тогда DoS может стать проблемой ... не говоря уже о том, что если он отправит свое собственное электронное письмо, он также может ввести любой случайный адрес, затопив какой-то бедный шмот ' Нет однозначного правильного ответа, но его следует рассматривать в контексте вашего приложения.
Я бы рекомендовал использовать простое случайное число, например байты из RNGCryptoServiceProvider.GetBytes . Идентификаторы GUID не должны быть полностью случайными. У них есть фиксированные биты, а в некоторых версиях используется ваш MAC-адрес. GetBytes также дает вам возможность использовать более 128 бит (хотя этого должно быть достаточно).
Я думаю, что лучше не помещать данные пользователя в URL. Хотя HTTPS может защитить его при передаче, он может оставаться в истории браузера пользователя и т.п. Лучше использовать POST и связать случайное число со строкой вашей базы данных.