On Aug 31, 2010, at 5:39 AM, Peter Sharp wrote:
Also, and I hate to say it, but if a user is for some reason using their banking password for any other public site, then they must wear the lions share of the responsibility if or when it is discovered and used by a malicious user. I mean, you have a role to play in the users security, but so do they.
This is an excellent point. All the security technology you implement won't help if your user just uses the same password on your site as they use on their WorldOfWarcruft gaming account, and that account gets hacked. Voila! The attacker can access that same user's account on a number of other sites. That's why it's important for every user to use a distinct password on each site where they have an account, because if you use one password for all accounts, the security of all your accounts is only as good as that of the weakest site.
Another risk is that attackers sniff network packets and discover a password transmitted in cleartext, because your site doesn't force logins to use the https protocol. Using https is important.
On Aug 30, 2010, at 10:56 PM, Hector Virgen wrote:
Bill, do you have any concerns about hackers recovering the user's original (raw) password to log into their other accounts such as banking? That's where I see the salt coming in as a protective measure -- they would need the db as well as the code to discover the password.
That's the point of using one-way hashing. We don't store the original, raw password, we store a hash digest. Hash digests are not reversible, so an attacker can't "unhash" it into the original password even if he knows the salt. He can only try a bunch of guesses, hash them, and compare the hash digests until a match is found. Knowing the salt for a given password hash is crucial for that process, but it still doesn't mean the attacker can get the password in one step.
Regards, Bill Karwin
