0

**Due to the limitations of my situation the exe (i.e. source), hash, salt, everything is stored locally as it's a local application.

Would this idea beat rainbow tables?

Password = Input (always 8 in length, 0-9 accepted) (unique to person)
Check = Input2 (always 2 in length, 0-9 accepted) (unique to person)

HashedPassworwd = Hash(Password, SHA_512)

Salt = Starting at string position Check, take 32 chars onwards

HashedSalt = Hash(Salt, SHA_512)

FinalHash = Hash(HashedPassworwd+HashedSalt, SHA_512)

Would this be beat rainbow tables and would only work against brute-forcing?

  • 1
    Ian, can you edit the last sentence? I'm not sure what you are trying to say. – schroeder Sep 12 '16 at 21:00
  • 2
    If the password have only 8 digits (or 10 with the check), a bruteforce attack would succeed way before someone creates a rainbow table. – ThoriumBR Sep 12 '16 at 22:27
1

You are probably better off increasing password length and strength rather than doing something with check and salt - salt is intended to be stored with the hashed password as a general principle.

What you've effectively done with the check is increase the password entropy by 2 digits while making it more difficult for you to use standard libraries. If you are really just using 0-9, that's only 10^10 - even with salt, even with SHA512, that's breakable by someone who really wants to - especially if your users use predictable patterns, which they probably will.

Why limit password length and valid characters - it is going to be hashed anyways, no skin off your nose from a storage perspective. With a better character set, you can just use a straight up salt and sha512 hash and be secure.

  • In my case the password length is set (always 8) and generated by admins. – ian smith Sep 12 '16 at 21:27
  • The only thing i dont understand is, if the salt is stored with or in the script an attacker has access to this information which means he could simply generate a rainbow table or remove the salt from the "hashed" password and compare with rainbow. Thats why i thought this idea would be better, as every password hash is unqiue meaning every salt is unqiue with that hash? Also i am aware about the brute-forcing and 10^10 is a tiny number, i am looking to add in key stretching to combat this. – ian smith Sep 12 '16 at 21:30
1

Your idea is not clearly specced out at all, so as posed, this is a nearly hopeless question to answer. But nevertheless I see tons of clear problems:

  1. Fixed, short password length of 8 characters. You should accept very long passwords if the users wish to provide them.
  2. The password length problem is particularly compounded by the fact that you only accept digits from 0-9.
  3. If users choose their own passwords, you cannot assume they will be unique. In real life, a lot of people use the same passwords, like "12345678", which is one of the most common passwords in practice.
  4. If the Check variable is 2 digits, it cannot be "unique to person" unless there are no more than 100 persons.
  5. Since your salts are derived from a Check variable that only has 100 distinct combinations, there are only 100 distinct salts. This makes the 32 character length pointless. (I'm assuming that the "string" that you take the 32 characters from is the same always. You have not told us anything about this string.)
  6. SHA-512 does not have any form of tunable work factor to slow down an attacker. If you have access to SHA-512, you have access to PBKDF2-HMAC-SHA512, and so you should use at least that. (Not that it will do you tons of good, given how many other problems you have!)
  7. I don't understand what kind of limitations you're talking about in your first sentence, but if the attacker has access to the program's object code, they can just modify it to bypass all of this.
  8. You seem to be fixated on rainbow tables when they are quite likely the least of your problems.
  • 1. The passwords are set by the admins and are randomly generated. 2. I agree on that 3. The check is something extra i am adding to the password to try and make it more secure as i am aware 8 digits, of 0-9 isn't great. The check is going to be [a-zA-z0-9] & puncation. Depending on the first "item" converted into dec it would give me a number between 32 - 255 – ian smith Sep 13 '16 at 9:20
  • 5. The salt is derviced from the check, but also the hash. If i hash "password" and my salt is "3". Then starting from letter 3 of the hashed password, take out 32 letters to be my salt. This means if the hashed "differentpassword" with a salt of 3. It would still be different and in affect unqiue. That is what i am mainly focused on at the moment and trying to find out if that "idea" is correct. I understand currently there are other problems, but i focusing on rainbow tables for now before moving onto the next problem :) – ian smith Sep 13 '16 at 9:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.