256 characters makes for a fairly sizable passphrase, and doesn't represent a substantial hit on storage space. In reality, even if they were stored as encrypted binary/base64 in a nosql file system of structured data files, 4096 is pretty much the de-facto floor for disk space occupied by non-zero-byte individual files on most modern file systems.
...variable data size being a concern in cases where the transformed value is encrypted rather than hashed.
They shouldn't be storing passwords at all so storage space should be a non-issue. My 20 meg password should hash down to the same small(er) value as your 15 character one.
$ python -c 'print "8 bytes\n" * (20 * 1024 * 1024 / 8)' > 20meg.txt; time shasum -a 512 20meg.txt
59cb7f88ad8d6229e6d3a74ee422dff57e17f168c6e6fa44ef32c3f07a73a6e455d8b55c1265d5212b9ed5475b6d9364286645200dada59aa16905a9ce748561 20meg.txt
real 0m0.289s
user 0m0.284s
sys 0m0.004s
$ python -c 'print "8 bytes\n" * (16 / 8)' > 16byte.txt; time shasum -a 512 16byte.txt
b6043d3a520424d5ec17dc0c23ba3b591d74517e2b9faa0df2d69d13c89a5f372d6dc35f95836687ee05be18433277e1c4b67393eb2771b475d655a832b16654 16byte.txt
real 0m0.045s
user 0m0.040s
sys 0m0.004sHiding the technique to compute the hash is relying on security by obscurity. Ideally you want a system that is secure even if potential attackers know what methods you're using.
The benefit isn't in the entropy, it's in the abilities of your users to remember their passwords/passphrases in the first place.
> If you're not sending 20 megs of data,
> you're not getting 20 megs of security.
> So why allow it if it doesn't add anything?
> If you're not sending 2 KB of data,
> you're not getting 2 KB of security.
> So why allow it if it doesn't add anything?
Probably a good idea to pre-hash. Or use scrypt.
I took that to mean that prior to being pwnd they had been storing passwords cleartext and would no longer be doing so.
Also, the wording about allowed special characters seems to be incorrect. I personally have a non ./-/_ special character in mine. Unless they are doing something terribad like silently discarding noncompliant parts of the password.
Re: password length - at least 32 characters is respectable. I believe last time I used outlook.com they had a max length of 12-16!
When setting the password, max length was only enforced by a text input with a max length attribute. You could happily type more characters and everything would work as expected....until you went to log in. The max length on the password field on the login form was greater so those characters that were silently dropped when setting the password suddenly weren't.
The character limits for usernames, though... smells like a SQL injection issue. Which is an obvious and completely naive thing to assert but they're using PHP so my immediate thought is that they're passing raw userdata into the database as strings.
That was my first thought too. I'd guess that it's a vulnerability somewhere in the code for handling the forums.
I would be willing to bet that they could get rid of a lot of the attack surface just by using standard services for certain things.
Although judging by a screenshot of the recent hack[0] posted here[1] escaping (and XSS) may not be an issue.
We've already been using PDO. As for overall privacy/security, please see https://projecteuler.net/privacy
Thank you for showing up and addressing my armchair criticisms. I appear to stand corrected.