News for hackers. Stuff that matters.
Re:How to Safely Store Your Users' Passwords in 2016 by JadeNB on Thursday February 18, 2016 @06:29PM (#11130245)
> This does mean that you need to be able to check subsets of the characters in the password, which rules out hashing the whole password in this case.

As you implicitly point out, however, it doesn't require any portion of the password ever to be visible to the call-centre employee; one can just supplement an individual hash by a collection of hashes of appropriate character subsets, and then (say) randomly pick among the available subsets.

Re:How to Safely Store Your Users' Passwords in 2016 by Vendan on Monday February 22, 2016 @11:03AM (#11151709)
note though, that this means you have a collection of hashes for the password that are each 3 characters or whatever long, which can be brute forced in essentially no time at all. Crack em all, lay them out according to what letters the hash is for, put it all together and you are done. Even just having 1 subset reduces your passwords security by that many letters, if not more (you can filter out dictionary guesses that don't match those letters and such)
Re:How to Safely Store Your Users' Passwords in 2016 by JadeNB on Monday February 22, 2016 @10:42PM (#11156343)
Good point. Would salting them obviate the problem?
Re:How to Safely Store Your Users' Passwords in 2016 by Vendan on Wednesday February 24, 2016 @12:55PM (#11168693)
nope. Salt is good for eliminating rainbow tables and similar vectors. At this level, let's just say you go after uppercase, lowercase, digits and 20 different symbols, (a total of 82 letters) you'll wind up with 551,368 possible combinations. The only way to make it "safe" would be to get a hash method that would take multiple seconds to run on good hardware. (as a comparison, I crack raw NTLM at something on the order of billions of hashes per second)