7 ms·

Does anyone know how Project Euler was storing the passwords?

krapp 11y ago
Usernames cannot contain more than 32 characters and they may only contain upper/lower case alphanumeric characters (A-Z, a-z, 0-9), dot (.), hyphen (-), and underscore (_). Passwords must contain between 8 and 32 characters. My money is on "ineptly."
- uxcn 11y ago
  It used to be a salted MD5 hash, but it may have changed.
  - krapp 11y ago
    I would have assumed of course that the size limits were because the passwords were being stored in plaintext in fixed-length fields, but I guess they wanted to make sure they were 'complicated' enough? I guess salted md5 is literally better than nothing. 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.
    - uxcn 11y ago
      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.
      - krapp 11y ago
        Probably. If they're not using PDO then that needs to be their first priority, dead stop. After that, maybe looking at their captcha script, because those sometimes have issues if they're not well designed. I don't know where theirs comes from but it doesn't seem to use much obfuscation so it's probably old. After that, Twig. Although judging by a screenshot of the recent hack[0] posted here[1] escaping (and XSS) may not be an issue. [0]https://i.imgur.com/pl22srz.png https://i.imgur.com/pl22srz.png [1]https://news.ycombinator.com/item?id=9990221 https://news.ycombinator.com/item?id=9990221
        ProjectEuler 11y ago
        Admin from PE here. We've already been using PDO. As for overall privacy/security, please see https://projecteuler.net/privacy https://projecteuler.net/privacy
        uxcn 11y ago
        I genuinely hope the security hole is findable/fixable. Thank you guys for continuing to run an awesome service, despite asshats repeatedly trying to abuse it.
        krapp 11y ago
        And PHPass as well, fair enough. Thank you for showing up and addressing my armchair criticisms. I appear to stand corrected.
        sfrank2147 11y ago
        Thanks for the response!
        deleted 11y ago
        [deleted]
- terminado 11y ago
  There's really not much rational for capping passwords at anything beneath 256 characters. 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.
  - gherkin0 11y ago
    > 256 characters makes for a fairly sizable passphrase, and doesn't represent a substantial hit on storage space. 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.
    - bosdev 11y ago
      There is a slight exception to this. If they are using an older statically typed language like C, it might make sense for them to have a limit on the buffer ready to store your unhashed password. Yes it seems crazy these days, but it might apply to some of the older systems which have password length limits.
    - a_t48 11y ago
      When there will be multiple shorter passwords that hash to the same value, is there a point to a 20mb pass?
      - elektromekatron 11y ago
        Depends. Can you guess them?
        a_t48 11y ago
        If I'm an attacker who is running through hashes...yes. Faster than the 20mb one.
- chucksmash 11y ago
  I can't find it now but I seem to remember this came up in response to another breach ~24 months ago. At that time they made an announcement to the effect that from then on you'd no longer be able to have your password sent to you if you forgot it, but that you would instead need to use an account recovery key. 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!
  - chucksmash 11y ago
    Oh and on the topic of silently discarding portions of passwords, another outlook.com password deficiency (circa 2011, doubt it still exists): 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.

krapp 11y ago

Usernames cannot contain more than 32 characters and they may only contain upper/lower case alphanumeric characters (A-Z, a-z, 0-9), dot (.), hyphen (-), and underscore (_). Passwords must contain between 8 and 32 characters. My money is on "ineptly."

uxcn 11y ago
It used to be a salted MD5 hash, but it may have changed.
- krapp 11y ago
  I would have assumed of course that the size limits were because the passwords were being stored in plaintext in fixed-length fields, but I guess they wanted to make sure they were 'complicated' enough? I guess salted md5 is literally better than nothing. 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.
  - uxcn 11y ago
    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.
    - krapp 11y ago
      Probably. If they're not using PDO then that needs to be their first priority, dead stop. After that, maybe looking at their captcha script, because those sometimes have issues if they're not well designed. I don't know where theirs comes from but it doesn't seem to use much obfuscation so it's probably old. After that, Twig. Although judging by a screenshot of the recent hack[0] posted here[1] escaping (and XSS) may not be an issue. [0]https://i.imgur.com/pl22srz.png https://i.imgur.com/pl22srz.png [1]https://news.ycombinator.com/item?id=9990221 https://news.ycombinator.com/item?id=9990221
      - ProjectEuler 11y ago
        Admin from PE here. We've already been using PDO. As for overall privacy/security, please see https://projecteuler.net/privacy https://projecteuler.net/privacy
        uxcn 11y ago
        I genuinely hope the security hole is findable/fixable. Thank you guys for continuing to run an awesome service, despite asshats repeatedly trying to abuse it.
        krapp 11y ago
        And PHPass as well, fair enough. Thank you for showing up and addressing my armchair criticisms. I appear to stand corrected.
        sfrank2147 11y ago
        Thanks for the response!
        deleted 11y ago
        [deleted]
terminado 11y ago
There's really not much rational for capping passwords at anything beneath 256 characters. 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.
- gherkin0 11y ago
  > 256 characters makes for a fairly sizable passphrase, and doesn't represent a substantial hit on storage space. 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.
  - bosdev 11y ago
    There is a slight exception to this. If they are using an older statically typed language like C, it might make sense for them to have a limit on the buffer ready to store your unhashed password. Yes it seems crazy these days, but it might apply to some of the older systems which have password length limits.
  - a_t48 11y ago
    When there will be multiple shorter passwords that hash to the same value, is there a point to a 20mb pass?
    - elektromekatron 11y ago
      Depends. Can you guess them?
      - a_t48 11y ago
        If I'm an attacker who is running through hashes...yes. Faster than the 20mb one.
chucksmash 11y ago
I can't find it now but I seem to remember this came up in response to another breach ~24 months ago. At that time they made an announcement to the effect that from then on you'd no longer be able to have your password sent to you if you forgot it, but that you would instead need to use an account recovery key. 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!
- chucksmash 11y ago
  Oh and on the topic of silently discarding portions of passwords, another outlook.com password deficiency (circa 2011, doubt it still exists): 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.