none
Password hashing and adding zero RRS feed

  • Question

  •  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

        0x3BD49472981C07E354B156A9DBD11F507DFFEE40A353CD732ABED6E14035C36C31E93E8888E1E657B77B41B35E883CD5F8920DDDB3F87D1F85AFFA3E2BD1015E 

    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 

        0x3BD49472981C07E354B156A9DBD11F507DFFEE40A353CD732ABED6E14035C36C31E93E8888E1E657B77B41B35E883CD5F8920DDDB3F87D1F85AFFA3E2BD1015E00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000



    when  i check my codes i dont see any wrong 
    so what can i do this about that
    Thursday, May 12, 2022 12:55 PM

All replies

  • follow
    Friday, May 13, 2022 2:29 AM
  • can a hashed password be hacked ? 
    Monday, May 23, 2022 3:43 AM
  • 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 (https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.sha512?view=net-6.0): 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!
    Tuesday, May 24, 2022 7:11 PM
  • You are forgetting to end the string before it goes into the database. Do something like this:

    databasestring[512] = '\0';

    Good luck!

    Thursday, May 26, 2022 11:49 AM
  • 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.

    Saturday, May 28, 2022 2:22 PM
  • 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.

    Regards,

    Rachel Gomez

    Friday, December 23, 2022 6:56 AM
  • Is it possible to hack a hashed password ?
    Sunday, December 25, 2022 6:43 PM
  • 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.
    Thursday, January 12, 2023 4:22 PM
  • 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.
    Monday, January 23, 2023 10:07 AM
  • This answer should float up higher...it's the right answer.   HMACSHA512 is adding padding, as it should.
    Monday, January 23, 2023 4:42 PM
  • Rally Nice Information I Like It
    Tuesday, January 24, 2023 6:54 PM