Will the hash be salted or not? If not, you might as well store the PIN in cleartext. If yes, you still don't want to implement anything yourself; The BCrypt api in Windows supports the following hashes: https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
I see PBKDF2 there, so there's at least one very strong (and slow) hash available.
For hashing passwords, the best choice is normally Argon2. If you're trying to sell software for US government use, PBKDF2 is probably your best choice since it's based on NIST-approved primitives. It's very easy to just drop an Argon2 or PBKDF2 implementation into your source tree, so for passwords I'm not sure how much sense it makes to use anything else. It doesn't matter if you don't have much coding experience, other people have already written the tricky bits for you.
That said, no matter what you do 4 digit pins aren't going to be secure unless you store them in special hardware which limits the number of unsuccessful attempts; it's just to easy to try all 10,000 possibilities (even if they take 2 seconds each, worst case it's only ~5.5 hours to crack one). In this case, I'd probably just store the PIN as 32-bit number, XOR it with some salt (maybe the username hashed with something like djb2), then run it through a simple integer hash function. It won't be secure, but it should be enough to thwart casual attackers.
#4 its not for for any real security it just to avoid non/low tech pople from reading another persons pin. there is no value behind it of any real concerns. i just added it because i don like storing it in plain text. no external connection whatsoever
there are plenty of solutions. basically, it seems that you prefer something computable in a few operations (so no crc32), and mapping 1:1 to original value (to avoid both false positives and false negatives). there is the class of reversible operations for integers in given range - add const, xor by const, exchange digits, and multiple by comprime value (i.e. for 0..9999 range - not divisible by 2 or 5)
Since it's only 10000 possible PINs, I like this approach (pseudocode):
seed random number generator with seed S
generate an array A, filled with the numbers 0000..9999
for N iterations, do:
generate two random numbers B and C in the range 0..9999
swap array elements A[B] and A[C]
N should be some value above 100K.
After that, use the entered PIN as an index to the array A and store it's value together with S and N.
To reverse, generate the array again. You can either search the index to the value, create a reverse mapping array or use a map data structure that allows value->index in O(1).
This shuffles the possible PINs and creates a bijective, reversible mapping. Creating the array takes longer than computing the hash, but after that, it's a simple lookup. Also, programming this is very straightforward and easy.
Agreed, it's a bit more sophisticated, but guarantees success in exactly 10K iterations. So using this removes the need to store iteration count. Also note that using a fixed seed doesn't really matter here, as the LCG parameters can be chosen differently, so storing this is optional, too.