Je construis un service Web qui me demande de générer des sessions personnalisées et des mots de passe aléatoires, etc.
Je me demandais si faire une classe statique et utiliser 1 instance statique RngCryptoServiceProvider pour l'ensemble du site Web est une bonne idée? 1. Est-ce que c'est threadsafe de plusieurs instances de demande HTTP? 2. Est-ce sécurisé? Si je permettez à quelqu'un de générer de nombreuses sessions en peu de temps, il serait-il possible de déterminer l'état de la RNG et de prédire les prochaines sessions? P>
dans mon service, d'autres utilisateurs savent quand quelqu'un se connecte et j'ai initialement créé un nouveau RngCryptoServiceProvider lorsqu'ils se connectent à générer une session, mais ma préoccupation est que si cela est basé sur la datetime actuelle, ne pouvait que parler théoriquement de passer quelques milliers de sessions pour "deviner" la session de Un autre utilisateur s'ils savaient à peu près à quoi ils se sont connectés? P>
public static class random
{
private static RandomNumberGenerator _rng;
protected static RandomNumberGenerator rng
{
get
{
if (_rng == null) _rng = new RNGCryptoServiceProvider();
return _rng;
}
}
public static byte[] Bytes(int number)
{
var value = new byte[number];
rng.GetBytes(value);
return value;
}
public static byte Byte { get { return Bytes(1)[0]; } }
public static int Int { get { return BitConverter.ToInt32(Bytes(4), 0); } }
public static long Long { get { return BitConverter.ToInt64(Bytes(8), 0); } }
}
3 Réponses :
1) Si elle est cryptographique, laquelle il est censé être, ce type de devinette ne devrait pas être réalisable.
2) sur une note latérale, je suggère de supprimer l'instanciation JIT dans la propriété statique Annd. Suivant:
Le RNG basé sur le CSP dans CLR n'est qu'une enveloppe autour de CryptGenrandom . Comme toutes les fonctions CSP, ils travaillent autour d'un Selon ce MSDN Magazine Le CLR peut < / EM> Utilisez un tampon d'instance au lieu d'une empilement, rendant le rngcryptoserviceProvider dangereux à travers les threads dans les futures implémentations:
Notez que, comme actuellement mis en œuvre dans
le .NET Framework 2.0, le
Constructeur sans paramètre de
RngcryptoserviceProvider crée
instances de fil-sécurité. En tant que tel, nous
aurait pu créer notre membre privé
au lieu de cela avoir été une statique privée
membre, et ce faisant ne pas avoir à
créer un nouveau rngcryptoServiceProvider
instance pour chaque instance de
Cryptorandom. Cependant, cela
Le fil-sécurité n'est pas actuellement
documenté ni en quelque sorte cuit au four
dans le contrat de la classe ou
interface. Étant donné que nous n'avons pas
invoqué dessus pour notre mise en œuvre.
Notez que cette utilisation n'est pas liée à la sécurité du fil de l'API native, le problème de la mémoire tampon est un problème d'emballage CLR. Aussi, HycryptProv Poignée de contexte. Si je me souviens bien, la toute première chose que le fournisseur fait lors de la saisie du «contexte» consiste à acquérir une section critique qui protège le «contexte». Ainsi, tandis que la fonction est très probablement stable à travers les threads, vous devez utiliser vraiment un séparé pour chaque fil pour éviter la conflit.
La classe rngcryptoserviceProvider est la sécurité du thread car .net 3.5: voir msdn.microsoft.com/en-us/library/5f45t420%28v=vs.90%29.aspx (mais pas en silverlight).
[ThreadStatic] protected static readonly RandomNumberGenerator _rng = new RNGCryptoServiceProvider(); ThreadStaticAttribute should make sure each thread gets their own.
Vous ne pouvez pas avoir d'initialiseurs pour threadstatic des objets, il s'agira de problèmes: Confluence.JetBrains.com/Display/resharper/...