If you want to see if a user entered a pin of 6357 you'd have to compare it with something: a hard coded string in the software, a string in a text file, a string in a serialized file, or even a field in a database. ALL of these are vulnerable to hacking efforts or easily obtained by a system administrator. This is especially insidious if a person happens to use a number that is easy for them to remember for logging in to multiple accounts.
So if you can't store the string 6357, then what do you store?
You want a set of bytes that has a strong relationship to the entered pin (or password), and then store that set of bytes using one of the approaches listed above. Now if someone hacks the storage they only find a meaningless sequence of bytes which does not give them enough info to reverse engineer the pin. The result is that they won't know the pin to use in order to log in to the system.
One approach to getting a string of encoded bytes for a pin is to use a hash function. There are several available. Java comes with an API to generate hashes. One of the easier ones to connect to is the MD5 hash. You take your pin string and pass it to the MD5 methods and it returns an array of 16 seemingly random bytes. For convenience sake, this is often converted to a 32 character hex string for storage and comparison. Note that a hash is not 1 for 1 unique to a pin. That is, multiple pins may hash to the same 16 bytes. This is so rare that it doesn't impact the security because, again, you can't use the hash to reverse engineer the pin.
So, you now have a stored hash instead of a stored pin. Now, how do you verify a pin during log in? It is pretty straight forward. You prompt the user to enter a pin, you hash that pin to come up with the hash value, and then compare that hash value to the one previously stored. If it matches, they've successfully logged in. At no time is the plain text pin sent across the network, or internet, or written to a hard drive.
That's pretty much it in a nutshell.