[samuel]

You say it's _unnecessary_ and "there's high chance of someone accessing the password". Under that premises, obviously, it's foolish not to use one-way hashing. Mine is that may provide value and there are sensible ways of mitigating the risk, miles away from accessing the data directly from your application, by using software and hardware designed and implemented by security professionals. That's all.

[throwaway64]

The problem is, the application fundamentally HAS to be able to access the password, either through direct comparison to authenticate, or some mechanism to mail out the password. This fundamentally cannot be separated, that's why hashing is always better, and why the risks are nearly impossible to meaningfully mitigate.

[Xylakant]

How does that statement hold true? I can easily think of an application that just uses a simple service on a separate box behind a firewall that only accepts an email and then sends the password. Authentication works via CHAP or any other auth protocol. The application itself never has access to the plaintext password. Granted, an attacker may gain access to the app-server and then proceed to crack the authentication server, but he could also just rig the application to pass on any password it receives. Just about as good as cracking the auth server and far easier to do. (Added bonus: works for hashed passwords just as well). Granted, this may seem tons of work for a simple solution, but from there on, it's a business decision.