Live data from Hacker News

Project Euler Returns

projecteuler.net

51–60 of 104 posts

Re: Project Euler Returns

#51
post #50
post #46

Earlier quoted context omitted.

A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.

A noob question I suppose, but couldn't the salt be generated deterministically from the email and still serve it's purpose?

Then it's just a more complicated hash function.

Re: Project Euler Returns

#52
post #32

Earlier quoted context omitted.

I think you are at least slightly overstating how inconvenient this is. I mean, yes, I could wish it was easier. No, this isn't going to stop me from getting back on the site.

And how many answers did you lose? Because I lost a bunch. I'm not overstating anything, I'm honestly frustrated and dispirited because of a high degree of incompetence and bad judgment.

I only have about 50 anyway. So, not that big of a deal just to redo.

Re: Project Euler Returns

#53
post #38
post #37

Earlier quoted context omitted.

It's one thing to decide not to store emails (sure, why not?) but account recovery shouldn't even require one to store email addresses. Check the the email provided by user via the recovery form against a hash of the email saved during registration, if it matches send the reset link. This way when data is breached, figuring out what the original email should be hard (if not impossibly hard, depending on how they hash…

You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords. Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.

A little off topic, but is there any reason to still be talking about salted hashes when we have bcrypt and scrypt these days? Seems like an anachronism.

Re: Project Euler Returns

#54
post #3

I have been curious for a while: What is in the opinion of the HN community a good score on Project Euler? For which scores do you tip your figurative hat?

Not scores so much as specific problems.

If I work on it for a week, get frustrated, google for solutions, and can't find any, and you solved it, you're a beast.

Also if you solve 328 tell me how. And no, dynamic programming is not efficient enough.

Re: Project Euler Returns

#56
post #32

Earlier quoted context omitted.

I think you are at least slightly overstating how inconvenient this is. I mean, yes, I could wish it was easier. No, this isn't going to stop me from getting back on the site.

And how many answers did you lose? Because I lost a bunch. I'm not overstating anything, I'm honestly frustrated and dispirited because of a high degree of incompetence and bad judgment.

You mean you didn't save all your results? Don't a lot of the problems build on previous results? Why would one lose anything? FYI I was interested but did not start down the projecteuler rabbit hole myself, so perhaps I'm missing something.

Re: Project Euler Returns

#57
post #14
post #10

it would be great if PE was open source :)

Anyone interested in creating an open source version? It could have more features - such as running the code online, and more topics - such as non-math challenges.

I think that would be an interesting problem itself. Does PE export its problems & solutions in some kind of easily consumable way?

Re: Project Euler Returns

#58
post #46
post #38

Earlier quoted context omitted.

You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords. Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.

A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.

You could have one of two approaches. 1. Don't use a per user salt and just use a global salt. You can counteract this decrease (a bit) in security by increasing the key stretching part of your hashing algorithm. or 2. Require the user to submit their email address AND username and store the salt in the user's record.

I agree with someone up there that email address != password. It's refreshing to see someone that gives a crap about my privacy though.

Re: Project Euler Returns

#59
post #38

Earlier quoted context omitted.

You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords. Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.

A little off topic, but is there any reason to still be talking about salted hashes when we have bcrypt and scrypt these days? Seems like an anachronism.

An attacker can pre-compute hashes of common passwords for common settings of bcrypt/scrypt. With a salt, they have to start from scratch every time.

Re: Project Euler Returns

#60
post #46
post #38

Earlier quoted context omitted.

You should not simply use a hash, but at least a salted hash, or even harder stuff like bcrypt. In other words, treat emails like passwords. Apart from that, I don't see any issues with that approach. Not sure why project euler doesn't use that approach.

A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.

Hello? Lets say you have 5 billion accounts, in salted sha1. According to openssl speed sha1, you'd take less than 38 minutes on my ancient desktop to look up an email, on average half that. If the shoe fits, send the email, if not don't?

Sure having another field to match on (eg: username) for locating the correct salt would be good -- but it's certainly not infeasible to do a brute force search (probably want to queue up password request requests, though). Now, if you went with bcrypt or scrypt -- things would, by design, break down a bit. I still think you'd be able to send a reset mail within 24 hours for most reasonable configurations and number of users...

Post reply on HN