Quote:
I think you're missing the entire point. There are two fields stored in the same record, and they are date and time. There is nothing anywhere in the database stating that the date and time are used in creating the hash, (other than the C# code-behind, Windows Application C# files, or your method of choice). For all the casual database table-reader knows, this is just a stamp on when the login was created. If the attacker was a little brighter than the average Joe, who says that the date and time are paired with the input in exactly the order that I stated? Who says that they can't be hashed first before being added, added in reverse order, or any other possibility that could have astronomical odds of guessing, all while remaining a unique final hash?
The odds of reversing such a hash are even more astronomical than the odds of guessing the proper method of putting together the string that is used to create the hash, (since you have to know what is being used to create the hash in order to know whether or not you have successfully reversed the hash.) If you really want to get over-the-top complex, throw in the OS SID, the MAC address, and any other unique identifier that you would want to add before the hashing takes place.
That is what I meant by saying that the second method was more secure because the attacker would have to know the format, even if they knew that you were using a date/timestamp.