Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Project Euler Humble Return

projecteuler.net

Post reply on HN
Print view View original

31–40 of 127 posts

Re: Project Euler Humble Return

#31

Post by Freaky »

h0w412d wrote: post #23
terminado wrote: post #15

Earlier quoted context omitted.

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…

BCrypt has a character limit of 72.

Hard limit of 72, beyond which many implementations will silently truncate, and reduced entropy from each character beyond 55 bytes.

Probably a good idea to pre-hash. Or use scrypt.

Re: Project Euler Humble Return

#32

Post by krapp »

uxcn wrote: post #13
krapp wrote: post #12

Earlier quoted context omitted.

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."

It used to be a salted MD5 hash, but it may have changed.

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.

Re: Project Euler Humble Return

#33

Post by uxcn »

krapp wrote: post #32
uxcn wrote: post #13

Earlier quoted context omitted.

It used to be a salted MD5 hash, but it may have changed.

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 m…

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.

Re: Project Euler Humble Return

#34

Post by bosdev »

gherkin0 wrote: post #19
terminado wrote: post #15

Earlier quoted context omitted.

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…

> 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.

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.

Re: Project Euler Humble Return

#35

Post by dyoo1979 »

It would be nice if source were provided, so that we can do a whitebox analysis. I don't have confidence that there is one single point of failure here, given that the site has already been compromised multiple times.

Re: Project Euler Humble Return

#36

Post by ajkjk »

zajd wrote: post #3

It's a shame the maintainer of the site is going to let it fall into obscurity instead of just adopting more modern development practices. edit. Such as allowing people to audit the source of the site as opposed to requesting pentesting.

It's a shame to not be more sympathetic to people with less experience or less time on their hands, especially when they run a widely appreciated site.

Re: Project Euler Humble Return

#37

Post by logicrime »

Haven't they been wrecked once before this most recent incident?

I find it concerning that folks are so eager to rush back into a warzone when they know it's not safe. Piling onto a recovering website after a cyberattack is akin to running back into a field where landmines were found. Maybe somebody was able to remove a landmine or two, but wouldn't it be wiser to just walk around it?

Re: Project Euler Humble Return

#38

Post by lukev »

logicrime wrote: post #37

Haven't they been wrecked once before this most recent incident? I find it concerning that folks are so eager to rush back into a warzone when they know it's not safe. Piling onto a recovering website after a cyberattack is akin to running back into a field where landmines were found. Maybe somebody was able to remove a landmine or two, but wouldn't it be wiser to just walk around it?

Except that as long as you use a unique password, and don't give any details that you don't mind falling into the wrong hands, there is absolutely no risk.

Unlike, for example, actual mines.

Re: Project Euler Humble Return

#40

Post by krapp »

uxcn wrote: post #33
krapp wrote: post #32

Earlier quoted context omitted.

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 m…

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.

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

[1]https://news.ycombinator.com/item?id=9990221

Post reply on HN