> At this point, given the content on this thread, it seems that it's been explained clearly enough why salted SHAx is inadequate to that task. Do you still not

> At this point, given the content on this thread, it seems that it's been explained clearly enough why salted SHAx is inadequate to that task. Do you still not understand why that is? Don't worry, I understand very well (this is not rocket science :P). My problem, I think, was an inappropriate attitude toward the realities of stored password hashes on servers, in addition to having read that "scrypt is bad for password storage" (and having misunderstood the "badness" of it). I had read too many articles that treated HASH + SALT as "OK" for servers that stored user passwords, and I hadn't kept fresh in my mind the speed with which these passwords can be cracked today. For example, take the article I linked to in my reply to pbsd: https://crackstation.net/hashing-security.htm https://crackstation.net/hashing-security.htm (recently written). This article, and many many others like it, are written by seemingly reputable people, and yet their attitude is that HASH + SALT is OK for servers. Even though it discusses bcrypt, etc., it frames it as though it's an "optional" hardening technique, and places HASH + SALT under the category of "proper hashing": https://crackstation.net/hashing-security.htm#properhashing https://crackstation.net/hashing-security.htm#properhashing I haven't seen them called out on it. I agree with you and the others in this thread, that it isn't good advice. If 10-char passwords can be protected better with KDFs, then they should be.