hashcat Forum

Hi everyone, 

I am running out of idea, so I wanted to ask the community (having more experience, already face similar question and/or got some other approach to propose).

I am currently evaluating risk on an open source software 
* on which some token are encrypted with sha256($pass.$salt) store into database
* The salt have a 32 bytes length and stored on filesystem (out of database)
* The salt is uniq and used on all sha256($pass.$salt) (not a random salt per encryption stored with value in database)

The risk I am evaluating is the following
* a user have the ability to forge 1-N Token
* The user know the token (real) value (abcdefg12345) as example
* The user not known the salt (store on filesystem/secure) of application
* But if the user get the ability to make some SQL injection (to read the database), this user will get the ability to get 1-N tokenhashsalt value he generated store into database

Question
* Starting that point, there is certainly some facilities to recompute/brute force the SALT
sha256("abcdefg12345".$salt??????) => RESULTHASHSALT
* the ability to forge 1-N Token (ie. 1000 or more) could be also a facilities to end user/attacker to retreive the salt
is there a way to find/deducate the SALT ?

My Objective(s)
* check if I am right (implementation is weak, but fortunately the salt is quite long 32 byte for a sha256 that could make it more harder to find, but not impossible)
* demonstrate to developpers, they are wrong or could do it better
* evaluate how long it will take (ie. hour, day, week before the SALT be deducted); Starting that point (SALT) was deducated + DB of all HASHSALT value (we are going back to hashcat are regular mode)
* make them (dev) to make thing differently (ie. not a uniq salt, but some secure random salt per token encrypted)

All ideas, advice or suggestions are welcomed : => retrieve SALT from VALUE and SHA256 (VALUE.SALT) with hashcat or other tool ?

32 byte salt is impossible to brute-force, assuming that means 32*8 bits. A little less would still be impossible to brute-force (ie 32*7).

All other security properties are trivially fulfilled under the assumption that SHA-256 is a secure (unbroken) cryptographic hash function.

However, unrelated to the salt itself it would still be possible to know if pass(user A) == pass(user B) due to the deterministic nature of hashes. This can be exploited if user A's password is known (for example because it was part of a previous breach).

note: don't use "encrypted" together with a hash function. A hash functions hashes. Encryption is something different. Encryption is by definition reversible while a hash function is not.

Thanks for feedback an yes we are talking about (hash) (not crypt), currently reading code .. and start to be tired.