Hachage des mots de passe avec MD5 ou sha-256 C#

Je suis en train d'écrire un formulaire d'inscription pour une demande, mais encore avoir des problèmes avec la nouvelle c#.

Je suis à la recherche pour crypter/hachage des mots de passe md5 ou sha-256, de préférence sha-256.

Tout de bons exemples? Je veux qu'il soit en mesure de prendre les informations de "chaîne de mot de passe;" et puis de hachage et de le stocker dans la variable "string hPassword;". Des idées?

  • Qu'allez-vous faire avec le hachage de mot de passe? Stocker dans une base de données? Puis il suffit de hachage n'est pas suffisant ( arc-en-ciel de la table ). L'utilisation de sels.
  • Je vais être de les stocker dans une base de données. Que recommandez-vous.
  • Les gens s'il vous plaît être conscient que les réponses ci-dessous sont plus à jour. Et garder à l'esprit que vous ne devriez jamais jamais utiliser MD5 pour le hachage de mot de passe. Il est vieux, cassé, et obsolètes. Le plus simple, up-to-date et sécurisée, la solution pour la plupart des gens serait bcrypt. Au moins, quand ce commentaire a été écrit 🙂 Argon2 est probablement va être le standard de la recommandation bientôt.
InformationsquelleAutor Sean | 2010-12-01
  1. 78

    Ne pas utiliser un simple hash, ou même un salée de hachage. Utiliser une sorte de touche-le renforcement de la technique comme bcrypt (avec un .NET mise en œuvre ici) ou PBKDF2 (avec un construit-dans la mise en œuvre).

    Voici un exemple d'utilisation de PBKDF2.

    Pour générer une clé de votre mot de passe...

    string password = GetPasswordFromUserInput();

//specify that we want to randomly generate a 20-byte salt
using (var deriveBytes = new Rfc2898DeriveBytes(password, 20))
{
    byte[] salt = deriveBytes.Salt;
    byte[] key = deriveBytes.GetBytes(20);  //derive a 20-byte key

    //save salt and key to database
}

    Et ensuite tester si un mot de passe est valide...

    string password = GetPasswordFromUserInput();

byte[] salt, key;
//load salt and key from database

using (var deriveBytes = new Rfc2898DeriveBytes(password, salt))
{
    byte[] newKey = deriveBytes.GetBytes(20);  //derive a 20-byte key

    if (!newKey.SequenceEqual(key))
        throw new InvalidOperationException("Password is invalid!");
}
    • Je suppose que dans votre post où vous dites: de PBKDF2, que vous avez voulu dire OU. Je ne recommande pas l'utilisation de bcrypt dans .NET, StackOverflow abandonné bcrypt pour utiliser PBKDF2. Voir les remarques de Kevin Montrose sur le StackOverflow blog blog.stackoverflow.com/2011/05/...
    • Oui, je voulais dire "ou PBKDF2"; mise à jour. J'irais personnellement pour PBKDF2 trop, bien que je ne suis pas au courant de toutes les bonnes raisons de ne pas utiliser bcrypt. (Je n'ai jamais entendu de bonnes choses à dire à ce sujet.)
    • Le problème avec bcrypt est qu'il n'y est pas .NET de la mise en œuvre de ce qui a été vérifié, c'est pourquoi StackOverflow choisissez de déposer leur utilisation de bcrypt. Ils ne souhaitent pas dépenser des ressources pour la mise en œuvre vérifié alors que le inclus PBKDF2 natif dans la mise en œuvre .NET a été vérifié pour Microsoft déjà.
    • seule chose que je voudrais ajouter, il conviendrait de modifier le sel de la longueur que vous avez mis le lien wiki dit "La norme recommande une longueur de sel d'au moins 64 bits.".
    • 20 octets est de 160 bits.
    • doh... mon mauvais... avez lu plus près... avez utilisé votre extrait de code dans mon application actuelle, la plupart des reconnaissante.
    • Un lien direct StackOverflow détails de l'évolution de l'utilisation PBKDF2 est ici: blog.stackoverflow.com/2011/05/...
    • href="http://stackoverflow.com/questions/12855336/what-data-type-to-use-when-storing-pbkdf2-encrypted-passwords">Ce type de données à utiliser lors de l'entreposage de PBKDF2 mots de passe cryptés ? il semble nvarchar(max) a problème de performance , ce que vous pensez pouvoir est d'utiliser 128 longueur le changement de longueur ?
    • Vous avez raison, ce lien n'est pas bon plus... j'ai utilisé la Wayback Machine, pour aller trouver l'ancienne version de la page, et il s'avère qu'il était dans les commentaires de la page, qui ont disparu depuis qu'ils ont déménagé le domaine à un .blog domaine. Voici donc un lien où StackOverflow détails de l'évolution de l'utilisation PBKDF2.

    InformationsquelleAutor LukeH
  2. 53

    Vous allez avoir à utiliser le System.De sécurité.La cryptographie espace de noms; en particulier, la MD5 de la classe ou la SHA256 de la classe.

    Dessin un peu le code de la cette page, et avec la connaissance que les deux classes ont la même classe de base (HashAlgorithm), vous pouvez utiliser une fonction comme ceci:

    public string ComputeHash(string input, HashAlgorithm algorithm)
{
   Byte[] inputBytes = Encoding.UTF8.GetBytes(input);

   Byte[] hashedBytes = algorithm.ComputeHash(inputBytes);

   return BitConverter.ToString(hashedBytes);
}

    Ensuite, vous pouvez l'appeler comme cela (MD5):

    string hPassword = ComputeHash(password, new MD5CryptoServiceProvider());

    Ou pour SHA256:

    string hPassword = ComputeHash(password, new SHA256CryptoServiceProvider());

    Edit: Ajout De Sel De Soutien

    Comme dtb souligné dans les commentaires, ce code serait plus forte si elle comprenait la possibilité d'ajouter des sel. Si vous n'êtes pas familier avec elle, le sel est un ensemble de bits aléatoires, qui sont inclus en tant que contribution à la fonction de hachage, qui va un long chemin pour contrecarrer les attaques de dictionnaire à l'encontre d'un hachage de mot de passe (par exemple, à l'aide d'un table arc-en-ciel). Voici une version modifiée de la ComputeHash fonction qui prend en charge le sel:

    public static string ComputeHash(string input, HashAlgorithm algorithm, Byte[] salt)
{
   Byte[] inputBytes = Encoding.UTF8.GetBytes(input);

   //Combine salt and input bytes
   Byte[] saltedInput = new Byte[salt.Length + inputBytes.Length];
   salt.CopyTo(saltedInput, 0);
   inputBytes.CopyTo(saltedInput, salt.Length);

   Byte[] hashedBytes = algorithm.ComputeHash(saltedInput);

   return BitConverter.ToString(hashedBytes);
}

    Espère que cela vous a été utile!

    • L'OP a une chaîne de caractères et veut le hash d'une chaîne comme une chaîne de caractères. Les classes de chiffrement ne traiter qu'avec des tableaux d'octets.
    • ASCIIEncoding.Default point de prêter à confusion retourne l'encodage UTF-16. Je suggère Encoding.UTF8 (ASCII serait trop limité).
    • Maintenant, si vous aussi ajouter un byte[] salt paramètre à votre ComputeHash méthode et la faire précéder de ces octets à inputBytes puis j'ai officiellement l'amour de votre réponse 🙂
    • Fait! Merci pour les conseils 🙂
    • À l'aide de PBKDF2 (via Rfc2898DeriveBytes) est plus sécurisé et nécessite en réalité moins code.
    • MD5CryptoServiceProvider et SHA256CryptoServiceProvider (et les HashAlgorithms) mettre en œuvre les IDisposable de l'interface et donc de leur création et de la durée de vie devrait être de façon optimale enveloppé dans un using bloc plutôt que le nouvel objet transmis en tant que paramètre.
    • StackOverflow a abandonné Bcrypt en faveur de PBKDF2

    InformationsquelleAutor Donut
  3. 5

    Vous devriez toujours le sel le mot de passe avant de hachage lors de leur stockage dans la base de données.

    Recommandé colonnes de base de données:

    • PasswordSalt : int
    • Propriétés passwordhash : binaire(20)

    La plupart des postes que vous trouverez en ligne allons parler d'un codage ASCII, le sel et le hachage, mais qui n'est pas nécessaire et ne fait qu'ajouter inutiles calcul. Aussi, si vous utilisez SHA-1, alors la sortie sera seulement 20 octets de sorte que votre hash champ dans la base de données ne doit être de 20 octets de longueur. Je comprends votre demande sur SHA-256, mais à moins d'avoir une raison impérieuse, à l'aide de l'algorithme SHA-1 avec une valeur salt sera suffisant dans la plupart des pratiques commerciales. Si vous insistez sur SHA-256, puis le hachage champ dans la base de données doit être de 32 octets de longueur.

    Ci-dessous sont quelques fonctions qui va générer le sel, calculer la valeur de hachage et de vérifier le hachage contre un mot de passe.

    Le sel de la fonction ci-dessous génère un fort niveau de chiffrement le sel comme un Entier de 4 cryptographique créé octets aléatoires.

    private int GenerateSaltForPassword()
{
    RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
    byte[] saltBytes = new byte[4];
    rng.GetNonZeroBytes(saltBytes);
    return (((int)saltBytes[0]) << 24) + (((int)saltBytes[1]) << 16) + (((int)saltBytes[2]) << 8) + ((int)saltBytes[3]);
}

    Le mot de passe peut alors être hashé en utilisant le sel avec la fonction ci-dessous. Le sel est concaténé à la passe et puis le hash est calculé.

    
private byte[] ComputePasswordHash(string password, int salt)
{
    byte[] saltBytes = new byte[4];
    saltBytes[0] = (byte)(salt >> 24);
    saltBytes[1] = (byte)(salt >> 16);
    saltBytes[2] = (byte)(salt >> 8);
    saltBytes[3] = (byte)(salt);

    byte[] passwordBytes = UTF8Encoding.UTF8.GetBytes(password);

    byte[] preHashed = new byte[saltBytes.Length + passwordBytes.Length];
    System.Buffer.BlockCopy(passwordBytes, 0, preHashed, 0, passwordBytes.Length);
    System.Buffer.BlockCopy(saltBytes, 0, preHashed, passwordBytes.Length, saltBytes.Length);

    SHA1 sha1 = SHA1.Create();
    return sha1.ComputeHash(preHashed);
}

    Vérification du mot de passe peut être fait simplement par le calcul du hachage et de comparer ensuite les attendus de hachage.

    
private bool IsPasswordValid(string passwordToValidate, int salt, byte[] correctPasswordHash)
{
    byte[] hashedPassword = ComputePasswordHash(passwordToValidate, salt);

    return hashedPassword.SequenceEqual(correctPasswordHash);
}
    • -1 pour la plaine de l'algorithme SHA-1. L'utilisation d'un lent hachage, comme PBKDF2, bcrypt ou scrypt. Il est également recommandé d'utiliser une version 64 bits de sel, mais c'est un problème mineur.
    • SHA1 n'est pas fiable à 100%, mais il a fallu une équipe de Google de 2 ans pour le prouver: security.googleblog.com/2017/02/... Peut aussi bien utiliser SHA-256 ou SHA3
    InformationsquelleAutor Adam Spicer
  4. 2

    Si vous allez stocker les mots de passe hachés, l'utilisation bcrypt au lieu de l'algorithme SHA-256. Le problème est que SHA-256 est optimisé pour la vitesse, ce qui rend plus facile pour une attaque en force brute sur les mots de passe doivent quelqu'un d'accéder à votre base de données.

    Lire cet article: Assez Avec Les Tables Arc-En-Ciel: Ce Que Vous Devez Savoir Sur Les Régimes De Mot De Passe Sécurisé et ce réponse à une précédente DONC, la question.

    Quelques citations de l'article:

    Le problème est que MD5 est rapide. Ses moderne concurrents, comme SHA1 et SHA256. La vitesse est un des objectifs de la conception moderne de hachage sécurisé, parce que les hachages sont un bloc de construction de presque tous les crypto-système, et généralement obtenir à la demande exécuté par paquet ou par message de base.

    Vitesse est exactement ce que vous ne voulez pas un mot de passe fonction de hachage.

    Enfin, nous avons appris que si nous voulons stocker les mots de passe en toute sécurité, nous avons trois options raisonnables: PHK du MD5 régime, Provos-Maziere de Bcrypt régime, et PRS. Nous avons appris que le bon choix est Bcrypt.

    • Bien que les mots de passe sont stockés dans une base de données après haché. Pas stockées localement à tous.
    • Ok, alors chaque mot de passe doit être haché avec un unique sel et vous devez l'utiliser bcrypt, ou quelque chose comme ça. Le hachage avec un sel bloque les attaques à l'aide d'un arc-en-ciel de la table, et à l'aide d'un ralentissement de l'algorithme augmente l'effort pour une attaque en force brute sur les mots de passe hachés.
    • Je ne recommande pas l'utilisation de bcrypt dans .NET, StackOverflow abandonné bcrypt pour utiliser PBKDF2. Voir les remarques de Kevin Montrose sur le StackOverflow blog blog.stackoverflow.com/2011/05/...
    • Il est utile de noter pourquoi StackOverflow ne pas utiliser bcrypt. Quand vous dites que "StackOverflow abandonné bcrypt", on pourrait avoir l'impression qu'il ya quelque chose de mal avec bcrypt.
    InformationsquelleAutor Jeff Ogata
  5. 2

    PBKDF2 est à l'aide de HMACSHA1.......si vous voulez plus moderne HMACSHA256 ou HMACSHA512 la mise en œuvre et voulez toujours la clé d'étirement pour rendre l'algorithme plus lent je suggère cette API: https://sourceforge.net/projects/pwdtknet/

    InformationsquelleAutor thashiznets
  6. 2

    Ici est la pleine mise en œuvre de la persistance ignorant SecuredPassword classe

    using System;
using System.Collections.Generic;
using System.Linq;
using System.Security.Cryptography;
using System.Text;
using System.Threading.Tasks;


    public class SecuredPassword
    {
        private const int saltSize = 256;
        private readonly byte[] hash;
        private readonly byte[] salt;

        public byte[] Hash
        {
        get { return hash; }
    }

    public byte[] Salt
    {
        get { return salt; }
    }

    public SecuredPassword(string plainPassword)
    {
        if (string.IsNullOrWhiteSpace(plainPassword))
            return; 

        using (var deriveBytes = new Rfc2898DeriveBytes(plainPassword, saltSize))
        {
            salt = deriveBytes.Salt;
            hash = deriveBytes.GetBytes(saltSize);
        }
    }

    public SecuredPassword(byte[] hash, byte[] salt)
    {
        this.hash = hash;
        this.salt = salt;
    }

    public bool Verify(string password)
    {
        if (string.IsNullOrWhiteSpace(password))
            return false; 

        using (var deriveBytes = new Rfc2898DeriveBytes(password, salt))
        {
            byte[] newKey = deriveBytes.GetBytes(saltSize);

            return newKey.SequenceEqual(hash);
        }
    }
}

    Et tests:

     public class SecuredPasswordTests
{
[Test]
public void IsHashed_AsExpected()
{
var securedPassword = new SecuredPassword("password");
Assert.That(securedPassword.Hash, Is.Not.EqualTo("password"));
Assert.That(securedPassword.Hash.Length, Is.EqualTo(256));
}
[Test]
public void Generates_Unique_Salt()
{
var securedPassword = new SecuredPassword("password");
var securedPassword2 = new SecuredPassword("password");
Assert.That(securedPassword.Salt, Is.Not.Null);
Assert.That(securedPassword2.Salt, Is.Not.Null);
Assert.That(securedPassword.Salt, Is.Not.EqualTo(securedPassword2.Salt));
}
[Test]
public void Generates_Unique_Hash()
{
var securedPassword = new SecuredPassword("password");
var securedPassword2 = new SecuredPassword("password");
Assert.That(securedPassword.Hash, Is.Not.Null);
Assert.That(securedPassword2.Hash, Is.Not.Null);
Assert.That(securedPassword.Hash, Is.Not.EqualTo(securedPassword2.Hash));
}
[Test]
public void Verify_WhenMatching_ReturnsTrue()
{
var securedPassword = new SecuredPassword("password");
var result = securedPassword.Verify("password");
Assert.That(result, Is.True);
}
[Test]
public void Verify_WhenDifferent_ReturnsFalse()
{
var securedPassword = new SecuredPassword("password");
var result = securedPassword.Verify("Password");
Assert.That(result, Is.False);
}
[Test]
public void Verify_WhenRehydrated_AndMatching_ReturnsTrue()
{
var securedPassword = new SecuredPassword("password123");
var rehydrated = new SecuredPassword(securedPassword.Hash, securedPassword.Salt);
var result = rehydrated.Verify("password123");
Assert.That(result, Is.True);
}
[Test]
public void Constructor_Handles_Null_Password()
{
Assert.DoesNotThrow(() => new SecuredPassword(null));
}
[Test]
public void Constructor_Handles_Empty_Password()
{
Assert.DoesNotThrow(() => new SecuredPassword(string.Empty));
}
[Test]
public void Verify_Handles_Null_Password()
{
Assert.DoesNotThrow(() => new SecuredPassword("password").Verify(null));
}
[Test]
public void Verify_Handles_Empty_Password()
{
Assert.DoesNotThrow(() => new SecuredPassword("password").Verify(string.Empty));
}
[Test]
public void Verify_When_Null_Password_ReturnsFalse()
{
Assert.That(new SecuredPassword("password").Verify(null), Is.False);
}
}
    InformationsquelleAutor Sam Shiles
  7. 2

    TL;DR l'utilisation Microsoft.AspNetCore.La cryptographie.KeyDerivation, la mise en œuvre de PBKDF2 avec SHA-512.

    La bonne idée de commencer avec le hachage de mot de passe est de regarder ce qui OWASP lignes directrices dire. La liste des recommandés algorithmes comprend Argon2, PBKDF2, scrypt, et bcrypt. Tous ces algorithmes peuvent être réglés pour adapter le temps qu'il faut pour hacher un mot de passe, et, en conséquence, le temps de la fissure par force brute. Tous ces algorithmes utilisent le sel pour protéger des tables arc-en-attaques.

    Aucune de ces algorithmes est très faible, mais il existe quelques différences:

    • bcrypt a été autour depuis près de 20 ans, a été largement utilisé et
      a résisté à l'épreuve du temps. Il est assez résistant pour GPU
      les attaques, mais pas pour FPGA
    • Argon2 est le plus récent ajout, être un gagnant de l'année 2015 hachage de Mot de passe de la concurrence. Il a une meilleure protection contre les GPU, FPGA et l'attaque, mais il est un peu trop récent pour mon goût
    • Je ne sais pas beaucoup sur scrypt. Il a été conçu pour contrecarrer GPU, FPGA et accélération des attaques, mais j'ai entendu il s'est avéré être pas aussi fort qu'à l'origine revendiquée
    • PBKDF2 est une famille d'algorithmes paramétrés par le hachage différent
      fonctions. Il n'offre pas une protection spécifique contre le GPU ou ASIC attaques, surtout si un affaiblissement de la fonction de hachage comme SHA-1 est utilisé, mais il est, cependant, certifiée FIPS si c'est important pour vous, et encore acceptable si le nombre d'itérations est assez grand.

    Basées sur des algorithmes seul, je serais probablement aller avec bcrypt, PBKDF2 le moins favorable.

    Cependant, ce n'est pas l'histoire complète, parce que même le meilleur algorithme peut être rendue précaire par une mauvaise mise en œuvre. Regardons ce qui est disponible pour .NET plate-forme:

    • Bcrypt est disponible via bcrypt.net. Ils disent que la mise en œuvre est basée sur Java jBCrypt. Actuellement il y a 6 contributeurs et 8 questions (fermées) sur github. Dans l'ensemble, il semble bien, cependant, je ne sais pas si quelqu'un a fait un audit du code, et il est difficile de dire si une version mise à jour sera disponible assez tôt si une vulnérabilité est détectée. J'ai entendu parler d'un Débordement de Pile déplacé loin de l'aide de bcrypt à cause de ces raisons
    • Probablement la meilleure façon d'utiliser Argon2 est par le biais de liaisons à l'
      bien connu libsodium de la bibliothèque, par exemple
      https://github.com/adamcaudill/libsodium-net. L'idée est que
      la plupart de la crypto est mis en œuvre par libsodium, ce qui est considérable
      de soutien, et la "non testé" pièces sont assez limitées. Toutefois, dans
      la cryptographie détails signifier beaucoup de choses, donc combiné avec Argon2 être
      relativement récente, j'avais la traiter comme une expérimentales option
    • Pour longtemps .NET a intégré la mise en œuvre de PBKDF2 via
      Rfc2898DeriveBytes classe. Cependant, la mise en œuvre ne peut utiliser hachage SHA-1 de la fonction, qui est jugée trop rapide pour être sûr de nos jours
    • Enfin, la plus récente de la solution est
      Microsoft.AspNetCore.La cryptographie.KeyDerivation paquet
      disponible via NuGet. Il fournit PBKDF2 algorithme SHA-1, SHA-256, ou SHA-512 fonctions de hachage, ce qui est considérablement mieux que Rfc2898DeriveBytes. Le plus grand avantage ici est que la mise en œuvre est fournie par Microsoft, et bien que je ne peut évaluer correctement le chiffrement de la diligence de développeurs de Microsoft contre BCrypt.net ou libsodium les développeurs, il est tout à fait logique de faire confiance, car, si vous exécutez un .NET application, vous êtes dépendant de Microsoft déjà. On pourrait également s'attendre à Microsoft pour libérer les mises à jour si des problèmes de sécurité sont trouvés. Avec de la chance.

    De résumer la recherche jusqu'à ce point, alors que PBKDF2 peut-être le moins préféré algorithme des quatre, la disponibilité de Microsoft fourni par la mise en œuvre des atouts que, si la décision raisonnable serait d'utiliser Microsoft.AspNetCore.Cryptography.KeyDerivation.

    Le récent paquet au moment de cibles .NET Standard 2.0, aussi disponible dans .NET Core 2.0 ou .NET Framework 4.6.1 ou plus tard. Si vous utilisez plus tôt cadre de version, il est possible d'utiliser la version précédente de l'emballage, 1.1.3, qui cible les .NET Framework 4.5.1 ou .NET Core 1.0. Malheureusement, il n'est pas possible de l'utiliser même dans des versions antérieures de .NET.

    La documentation et l'exemple de travail est disponible à docs.microsoft.com. Cependant, ne pas faire de copier-coller en tant qu'il est, il y a encore des décisions qu'un développeur doit faire.

    La première décision à prendre est ce que la fonction de hachage à utiliser. Options disponibles incluent SHA-1, SHA-256 et SHA-512. De ceux, SHA-1 est vraiment trop rapide pour être sûr, SHA-256 est décent, mais je vous recommande SHA-512, parce que soi-disant, de ses opérations en 64 bits utilisation rend plus difficile de bénéficier de GPU-attaques.

    Ensuite, vous devez choisir le hachage de mot de passe de sortie de longueur et le sel de la longueur. Il ne fait pas de sens d'avoir de sortie de plus de la fonction de hachage de sortie (par exemple 512 bits pour l'algorithme SHA-512), et il serait probablement plus sûr d'avoir exactement comme que. Pour le sel de la longueur, les opinions divergent. 128 bits devrait être suffisant, mais dans tous les cas, la longueur du plus long que le hachage de sortie longueur certainement n'est pas de fournir tous les avantages.

    Ensuite, il y a un nombre d'itérations. Plus elle est grande, plus les hashs sont à craquer, mais il faut plus d'utilisateurs du journal de dans le. Je vous suggère de choisir de sorte que le hachage prend de 0,25 - 1 secondes sur typique de système de production, et dans tous les cas, il ne doit pas être inférieur à 10000.

    Normalement, vous obtiendrez tableau d'octets que le sel et les valeurs de hachage. Utilisation Base64 pour les convertir en chaînes. Vous pouvez choisir d'utiliser deux colonnes dans la base de données, ou de combiner le sel et le mot de passe dans une colonne à l'aide d'un séparateur, qui n'est pas rencontrée en Base64.

    N'oubliez pas de concevoir un hachage de mot de passe de stockage d'une façon qui permet de déplacer de manière transparente pour un meilleur algorithme de hachage à l'avenir.

    InformationsquelleAutor ovolko
  8. 1

    Le Système.De sécurité.La cryptographie.SHA256 classe devrait faire l'affaire:

    http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256.aspx

    InformationsquelleAutor James Kovacs
  9. 1

    Veuillez utiliser ce que j'ai le même problèmes avant, mais pourrait résoudre ce sera la petit extrait de code

        public static string ComputeHash(string input, HashAlgorithm algorithm, Byte[] salt)
{
Byte[] inputBytes = Encoding.UTF8.GetBytes(input);
//Combine salt and input bytes
Byte[] saltedInput = new Byte[salt.Length + inputBytes.Length];
salt.CopyTo(saltedInput, 0);
inputBytes.CopyTo(saltedInput, salt.Length);
Byte[] hashedBytes = algorithm.ComputeHash(saltedInput);
StringBuilder hex = new StringBuilder(hashedBytes.Length * 2);
foreach (byte b in hashedBytes)
hex.AppendFormat("{0:X2}", b);
return hex.ToString();
}
    InformationsquelleAutor king zecole