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

Project Euler Returns

projecteuler.net

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Project Euler Returns

#81

Post by jeorgun »

teach wrote: post #77
bellerocky wrote: post #36

Earlier quoted context omitted.

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.

So, you 1) had solved a bunch of Project Euler problems, but fewer than 200 (account recovery is still available for those folks), 2) lost/forgot your signon information, and 3) lost/deleted all the code you used to find the answers? You, sir, are in a very small boat. A frustrating boat, to be sure, but I suspect that virtually none of their users share your fate.

I'm in pretty much the same boat. The actual problems I don't really mind (I have to code to some, and it wouldn't hurt to revisit the rest), but I'd very much like to have my username back.

OK, so it's an extremely minor issue, but given that the reason for it is so silly, it's still kinda irritating.

Re: Project Euler Returns

#82

Post by alexforster »

stouset wrote: post #46
vog wrote: 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.

The salt for the email could be a CRC, or a Fisher-Yates, or any of a dozen other novel one-way transformations.

Re: Project Euler Returns

#83

Post by stouset »

owenversteeg wrote: post #79
runamok wrote: post #58

Earlier quoted context omitted.

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

A global salt is called 'pepper'.

This thread is dishearteningly full of cargo-culted cryptography. You would think HN would do better. A global salt is not a thing. It's a misapplication of a cryptographic component. The appropriate tool when you think you need something like this is an HMAC and a secret HMAC key.

Re: Project Euler Returns

#84

Post by stouset »

lallysingh wrote: post #78
runamok wrote: post #58

Earlier quoted context omitted.

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

.. can't you just use a few bits of hashing (via a second algorithm) the original email address for the salt?

Now you just have a different, slightly more complicated hashing function.

Re: Project Euler Returns

#85

Post by stouset »

e12e wrote: post #70
stouset wrote: post #65

Earlier quoted context omitted.

38 minutes to log into your account seems excessive. Remember, this isn't just for password resets — it's to look up an account in the database by email address.

Ah, fair point. So we agree they need a (possibly not unique) user name too. [edit: note this is for 5 billion accounts, on a 10 year old cpu. So for 500.000 accounts, it would be ~1 seconds (average 0.5). Still probably too long for log-in (or particularly log-in failure feedback)).]

If you have a username and emails aren't used for contacting users, why bother storing the email address to begin with?

Re: Project Euler Returns

#86

Post by stouset »

alexforster wrote: post #82
stouset wrote: 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.

The salt for the email could be a CRC, or a Fisher-Yates, or any of a dozen other novel one-way transformations.

You do not appear to understand the purpose of a salt. A salt should never be derived from the data it is to be used with. The entire purpose of a salt is to cause two identical inputs to a hash function to produce distinct outputs.

Re: Project Euler Returns

#87

Post by stouset »

Arnor wrote: post #67
runamok wrote: post #58

Earlier quoted context omitted.

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

I had a visceral reaction to "global salt" (I've always heard this called: "pepper") because it's so insecure for passwords, but I guess it's not as bad for email addresses. In the case of passwords, we find that a global salt is fairly ineffective because too many people use common (stupid) passwords like "password." If 10% of the hashes are the same, you can probably figure out what that hash means pretty quickly.…

A global salt is not a thing. Not is a pepper. The actual cryptographic construct is an HMAC and secret HMAC key.

Re: Project Euler Returns

#88

Post by stouset »

hyperpape wrote: post #45
pgeorgi wrote: post #17

Earlier quoted context omitted.

The combination of email address + password (even hashed in some way) isn't quite as public anymore. Not having any personally identifying information doesn't protect your Project Euler account, it protects your other assets.

This is a good point, and a reason to do the right thing with regard to emails--which is to store a safe version of them (bcrypt). Because while an email and a password is not public information, a username and a password isn't public information either. If you don't trust yourself to store the former, you shouldn't trust yourself to store the later much either.

Using bcrypt on email addresses is pants-on-head retarded. Please stop cargo-culting cryptography.

How do you propose to look up accounts by email address if they use a salted hash? You would have to bcrypt the email against every row in the database until you found the correct one. If you use a username to do the lookup instead, why store the email address at all? You can't use it for anything.

Re: Project Euler Returns

#89

Post by rikkus »

I created an account but couldn't log in. As I've had the same happen before, I tried using only the first 32 characters of my password when logging in. That worked.

Remember kids: Most software development isn't about puzzle solving and algorithms, it's about making stuff like forms work properly.

Of course the puzzles and algorithms are fun, which is why I'm signing up for PE again!

Re: Project Euler Returns

#90

Post by gizmo686 »

taeric wrote: post #23
bellerocky wrote: post #22

Earlier quoted context omitted.

> "Account recovery will no longer be possible." A site that purports to teach is incapable of learning of how to strike a balance between securing confidential information and making it possible to recover an account. This is a solved problem. If my bank can have a password recovery system, a site about numbers can have one too. > " With respect to this issue it is quite possible that some members will have genuinel…

To be fair, your bank likely has a bit more money to throw at this problem. I would think in this case the entire point is not so much to help them secure stuff, but an attempt to remove them as a target for hacking in the first place.

A bank also has a lot more law enforcement to through at this problem.
Post reply on HN