Skip to main content
Topic: 38k Member Forum (Read 11397 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: 38k Member Forum

Reply #30

True, if the encryption method is somehow compromised you regain the anti-sniffing advantages. But again I repeat, I'm not objecting to improving the current client-side hashing methods. Although I'd add that your message gave me a much graver impression of what's going on, meaning I wasn't really aware it'd been improved compared to SMF. Repeating that salt+hash a number of times (such as 256) would improve security, but I don't know if switching to SHA512 would matter. It's barely any slower. And for server-side hashing, from what I understand you want to use something much stronger like Crypt/Blowfish (or Crypt/SHA512 or Crypt/whatever) regardless.

But could you explain how problems caused by the submission, or rather the acceptance of a million-character password submission would be mitigated? Javascript would be no different than input pattern=".{88,88}". The actual check that anything submitted meets the requirements still needs to take place on the server side of the equation.[1] Loading the form through JS merely ensures that no one can submit their plain text password by accident.

As far as repeated login attempts go, that would be a temporary but welcome relief. In the long term I think that'll still be primarily dealt with by Bad Behavior, which luckily is already built-in.
Like so. :P

Re: 38k Member Forum

Reply #31

Quote from: Frenzie – But could you explain how problems caused by the submission, or rather the acceptance of a million-character password submission would be mitigated? Javascript would be no different than input pattern=".{88,88}". The actual check that anything submitted meets the requirements still needs to take place on the server side of the equation.
The Django issue was "simply" there was no limit to the password length (server-side), so you could send an arbitrary long password to the server, it would have to hash it requiring CPU-cycles. Of course, the longer the password, the harder is the hashing, so using a password in the realm of millions of characters would lead to a (D)DoS attack.
Using SHA\d+ the password is a fixed length, so you don't have to set a limit on the password length: if the hash passed to the server is not the expected length you send back to the client a NAY answer without even starting the server-side hashing.
That said, Elk enforces a max-length for the password (see your link), so it is less of a problem except for the few that would like to use a 64+ chars password and no javascript.
Bugs creator.
Features destroyer.
Template killer.

Re: 38k Member Forum

Reply #32

QuoteUsing SHA\d+ the password is a fixed length, so you don't have to set a limit on the password length: if the hash passed to the server is not the expected length you send back to the client a NAY answer without even starting the server-side hashing.
Yes, but although you repeated so at the end I just want to emphasize that as far as I can see, the difference between <= and == is a distinction without meaning. Either there's the potential for a DoS attack through extremely expensive computations or there isn't. Anything client-side does nothing to obviate that.