Password hashing and adding zero RRS feed

  • 问题

  •  i trying a user login/register template and 
    when i do register a user  i doing hashing like this


        public class HashingHelper
               public static void CreatePasswordHash(string password, out byte[] passwordHash, out byte[] passwordSalt) 
                    using (var hmac = new System.Security.Cryptography.HMACSHA512())
                        passwordSalt = hmac.Key;
                        passwordHash = hmac.ComputeHash(Encoding.UTF8.GetBytes(password));
            public static bool VerifyPasswordHash(string password, byte[] passwordHash, byte[] passwordSalt)
                using (var hmac = new System.Security.Cryptography.HMACSHA512(passwordSalt))
                    var computedHash = hmac.ComputeHash(Encoding.UTF8.GetBytes(password));
                    for (int i = 0; i < computedHash.Length; i++)
                        if (computedHash[i] != passwordHash[i])
                            return false;
                    return true;

        public class AccessToken
                public string Token { get; set; }
                public DateTime Expiration { get; set; }
        public interface ITokenHelper
                AccessToken CreateToken(User user, List<OperationClaim> operationClaims);
        public JwtHelper(IConfiguration configuration)
                    Configuration = configuration;
                    _tokenOptions = Configuration.GetSection("TokenOptions").Get<TokenOptions>();

            public AccessToken CreateToken(User user, List<OperationClaim> operationClaims)
                _accessTokenExpiration = DateTime.Now.AddMinutes(_tokenOptions.AccessTokenExpiration);
                var securityKey = SecurityKeyHelper.CreateSecurityKey(_tokenOptions.SecurityKey);
                var signingCredentials = SigningCredentialsHelper.CreateSigningCredentials(securityKey);
                var jwt = CreateJwtSecurityToken(_tokenOptions, user, signingCredentials, operationClaims);
                var jwtSecurityTokenHandler = new JwtSecurityTokenHandler();
                var token = jwtSecurityTokenHandler.WriteToken(jwt);

                return new AccessToken
                    Token = token,
                    Expiration = _accessTokenExpiration


            public JwtSecurityToken CreateJwtSecurityToken(TokenOptions tokenOptions, User user,
                SigningCredentials signingCredentials, List<OperationClaim> operationClaims)
                var jwt = new JwtSecurityToken(
                    issuer: tokenOptions.Issuer,
                    audience: tokenOptions.Audience,
                    expires: _accessTokenExpiration,
                    notBefore: DateTime.Now,
                    claims: SetClaims(user, operationClaims),
                    signingCredentials: signingCredentials
                return jwt;

     codes doing hashing and gives me this result


    it will doing without problem but when i tried the sign in user  
     i cant because when i see in local sql database i see codes are adding  zero number 


    when  i check my codes i dont see any wrong 
    so what can i do this about that
    2022年5月12日 12:55


  • follow
    2022年5月13日 2:29
  • can a hashed password be hacked ? 
    2022年5月23日 3:43
  • Hi, It just so happens that the methods you use determine hat you get back in return e.g. HMACSHA512 would always provide a 512 bits of data and it will be padded if required. From the official documentation ( The hash is used as a unique value of fixed size representing a large amount of data. Hashes of two sets of data should match if and only if the corresponding data also matches. Small changes to the data result in large unpredictable changes in the hash. The hash size for the SHA512 algorithm is 512 bits. So the extra trailing zeros are just padding to make the result from the hash match the expected number of bytes. Hope that helps!
    2022年5月24日 19:11
  • You are forgetting to end the string before it goes into the database. Do something like this:

    databasestring[512] = '\0';

    Good luck!

    2022年5月26日 11:49
  • If you are running the length of the shorter string though the code:

    for (int i = 0; i < computedHash.Length; i++){
      if (computedHash[i] != passwordHash[i]) {
        return false;
    return true;

    Shouldn't the shorter string still return true if they are the same? you are only comparing for the digits of the first string?

    I would also be careful about having a case where computedHash.Length = 0. As this will lead no password passing through as the same. You should ideally change the test to the stored password.

    2022年5月28日 14:22
  • Hash algorithms are one way functions. They turn any amount of data into a fixed-length "fingerprint" that cannot be reversed. They also have the property that if the input changes by even a tiny bit, the resulting hash is completely different (see the example above). This is great for protecting passwords, because we want to store passwords in a form that protects them even if the password file itself is compromised, but at the same time, we need to be able to verify that a user's password is correct.

    The general workflow for account registration and authentication in a hash-based account system is as follows:

    The user creates an account.
    Their password is hashed and stored in the database. At no point is the plain-text (unencrypted) password ever written to the hard drive.
    When the user attempts to login, the hash of the password they entered is checked against the hash of their real password (retrieved from the database).
    If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials.
    Steps 3 and 4 repeat every time someone tries to login to their account.
    In step 4, never tell the user if it was the username or password they got wrong. Always display a generic message like "Invalid username or password." This prevents attackers from enumerating valid usernames without knowing their passwords.

    It should be noted that the hash functions used to protect passwords are not the same as the hash functions you may have seen in a data structures course. The hash functions used to implement data structures such as hash tables are designed to be fast, not secure. Only cryptographic hash functions may be used to implement password hashing. Hash functions like SHA256, SHA512, RipeMD, and WHIRLPOOL are cryptographic hash functions.


    Rachel Gomez

    2022年12月23日 6:56
  • Is it possible to hack a hashed password ?
    2022年12月25日 18:43
  • It looks like the problem is that when you are storing the password hash and salt in the database, it is getting padded with additional zeroes. This could be due to the data type of the column in the database that is storing the hash and salt. By default, the byte array is being stored as a varbinary or binary data type which has a fixed length, so if the length of the byte array is smaller than the defined length, it will get padded with additional zeroes.

    To fix this issue, you can try changing the data type of the column in the database to a variable-length data type such as varchar or varbinary. Or you can define a max-length for the data type of column in the database.

    Another solution is to convert the byte array to a string before storing it in the database and then convert it back to a byte array when you are comparing the password. You can use the Convert.ToBase64String() method to convert the byte array to a string and the Convert.FromBase64String() method to convert the string back to a byte array.

    It's worth noting that these solutions only address the problem of the zero padding, but they don't address the root cause of the problem, which is in the way of handling the byte array.

    It's important to be aware that the data type you choose to store the hash and salt should be able to handle the size of the byte array. Also, you should make sure that you are using the same data type when you are reading the hash and salt from the database to compare it with the password.
    2023年1月12日 16:22
  • Hashing is a one-way activity, but no one has yet explained how, as of yet.

    Let's use simple addition, subtraction, multiplication, and division as a stand-in for these operations. Your password is 15 (a prime number). I receive it from you.

    I multiply 15 by two more digits, which we'll call 3 and 7.

    In order to get 2305, I add the value that is half of my 1537, rounded down to itself. That is what I multiplied by 50 to obtain 115,250. I multiply 1537 by the remaining half to get 116,018.

    I round down and divide that figure by the two digits I inserted previously, getting 38,672 and 5524 respectively. 
    Then, I multiply each digit by my value (still 5524) to get 5586, which I then multiply by my value to reach 30,857,064.

    The result is my final "hash," which is 482,855. I then multiply that by my starting value of 15 and eliminate the last three digits.

    Therefore, if a hacker gains access to my database, they will instead find the salt and hash (482,855) instead of your password (15). (37).

    After doing a handful of those steps several hundred times, it is difficult to recover the original value without brute-forcing it by subjecting every possible value to the hashing process. It will take longer to brute force it the longer that original value was.
    2023年1月23日 10:07
  • This answer should float up's the right answer.   HMACSHA512 is adding padding, as it should.
    2023年1月23日 16:42
  • Rally Nice Information I Like It
    2023年1月24日 18:54