I'll try to be clear (not great at that ;p). There are TWO distinct types of operations here, though they are similar in nature, it is just that one has a larger bitspace to reduce collisions to a near zero possibility.
The terms ARE *often* interchangable in the real world, so either is valid, but I prefer this way of thinking. You can use whichever
term you want - just make sure you pick the right algorithm.
1. Hash - short bitspace, collisions can occur
2. Digest - larger bitspace, collisions have near zero probability, designed to be mathematically irreversible by people smarter than me (cryptographically secure)
In practice, this means no two data sets are likely to result in the same DIGEST, so it can be used reliably to uniquely identify a data set. HASHes are used often for quick data integrity checks in the old days, or quick lookups in arrays and databases. Collisions are expected and accounted for.
DIGESTS are usually much larger in length than HASH. Instead of 32-bits, you may be speaking of 128-bits, for example. These are mathematically formed in such a way that no two data sets should produce the same DIGEST.
That is why a password is stored as a DIGEST, and thus when you type in the plaintext password, the DIGEST is computed and compared to the stored DIGEST. In this way, even if an attacker compromised the site or software and retrieved the password's DIGEST, they'd NOT know the actual password. However, that is what 'Rainbow Tables' are for (pre-computed digests of common passwords). These are getting larger all the time. Still, unless you used a word in the dictionary, or some short password, you're likely ok.
Why is it called a 'digest'? Well, think about it -- the data set is 'digested' through an algorithm and out comes a 128bit (or however long) 'digest'.
Example HASH algorithms: CRC32, Checksum
Example DIGEST algorithms: MD5, SHA1
Again, the *terms* HASH and DIGEST are often interchanged in the real world, but that's MY definition. In the real world, you can say either one and be fine.
To web site owners *and* even software authors --- NEVER, EVER store a password plaintext. ALWAYS store its digested form (usually SHA1 or MD5). Sometimes people also 'salt' the outputed digest with a quick XOR or some other operation, just to throw off rainbow tables.
This is the 'one way encryption' I believe you speak of. Does that sum it up? This would be in a CS101 class I believe, it's pretty introductory stuff, some of the first things you learn in college other than OS fundamentals and classical algorithms that still are used to this very day (e.g. search and sort algorithms, or the basics of compression algorithms later).
e.g.:
Last month I created this 'online tool', one of thousands I'm sure, to do a quick MD5 or SHA1 computation of given plaintext:
Calculate MD5 or SHA1 DigestMD5 of 'mypassword' is '34819d7beeabb9260a5c854bc85b3e44'
All that need be stored is '34819d7beeabb9260a5c854bc85b3e44'. Then when the user types in 'mypassword' the MD5 is recomputed and compared to '34819d7beeabb9260a5c854bc85b3e44'. If match, then all is good. If no match, then it's the wrong password. In that way, the actual password need never be stored. Note that MD5 has been compromised in that it has been shown to produce collisions, as shown here:
http://en.wikipedia.org/wiki/MD5 .. Thus, SHA1 is the preference usually .. but it hardly matters unless you're into banking or some really hard core stuff.
