Hi Jerry,

>>My understanding is if I use SHA-1, and the user knows I use SHA-1, there is no way to reverse it. Is that correct?

Re your provided example of a password: correct, if you only need to validate a value you can store just its digest (hash). Then at login when the user enters a password, you can regenerate the hash to confirm that it matches. So you can validate credentials without storing something that can be decrypted.

You're well advised to hash more than just the password- or else a hacker can simply replace a user's password hash with one for a known password, and now the hacker can log in as that user. Munging username or parts of other static fields into the hashed string prevents this sort of spoofing.

SHA-1 is not advisable. It has been considered cryptographically insecure for almost 20 years and is no longer allowed for site certificates by most browsers and many organizations. In truth it's probably "good enough" especially if used with multiple munged fields- but you can avoid potential security objections by simply using a longer hash.

MD5 has been popular for this purpose, but also is considered insecure these days.

Back to encryption: if it's not a password but a string you need to decrypt rather than just validate- e.g. a database connection string- then AES256 and Blowfish are widely accepted. Note that the usual default "ECB" (Electronic codebook) format is also now considered insecure since it can leave signatures for files with matching headers or other 16-byte blocks. Again- easy enough to prevent this by "salting" or "peppering" the string, but potential security objections are avoided by simply using one of the other formats.

Some of this is covered in my White Paper from last year's SW Fox if you can find it. It's for VFP, but same principles apply to NET.