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?
Project Euler Returns
51–60 of 104 posts
Re: Project Euler Returns
#52Earlier 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.
Re: Project Euler Returns
#53Earlier 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.
Re: Project Euler Returns
#54I 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?
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
#55Re: Project Euler Returns
#56Earlier 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.
Re: Project Euler Returns
#57it 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.
Re: Project Euler Returns
#58Earlier 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.
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
#59Earlier 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.
Re: Project Euler Returns
#60Earlier 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.
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...