5 ms·

You could still use bcrypt and do the comparison work server-side. Depending on work factors and whatnot, it's now a backend load balancing issue. But it's pro

• sk5t 15y ago
  Hmm... 1,000 clients trying to log in from machines with pretty fast CPUs, and you want to shift this highly compute-intensive, uncacheable, froo-froo-feature support load to the 1/5/10 servers on the backend?
  • latitude 15y ago
    There's no need to derive hinting (reduced) hash from the bcrypt hash of the password. Since all that's needed is even distribution of password space into 2^N classes, it can easily be done by looking at N bits of any password hash. Since N is low, even something like a now-obsolete MD5 would work.
    • incandenza 15y ago
      But these "classes" have no meaning. The only thing that means anything is whether the entire hash matches or not. Comparing a subset of bits just gives you random results, (aside from the case where the entire original hash matches). If something like this worked, it would provide a method of breaking the hash in a piecemeal fashion, which would mean the hash algorithm never worked properly in the first place. EDIT: reply to below: The only thing it can tell you is that two passwords don't match. It tells you nothing about whether they're similar. (And also doesn't tell you they do match, for which you need the whole hash.)
      • latitude 15y ago
        > But these "classes" have no meaning. What do you mean? They work for my purpose, which is being able to tell "password" and "passwrod" apart. There will be false positives, of course, but an (educated) assumption is that they are not going to be frequent for lexically related inputs.
• deleted 15y ago
  [deleted]