91–100 of 104 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Wrong, because it's the logical conclusion of the belief that emails must be treated with as much care as passwords. If you really think that, then you need to encrypt them, and therefore you have to give up the ability to look up user accounts by email address. All you could do is verify that a user-submitted email is associated with a user-submitted account. That's where you end up when you have that sort of paranoia about email addresses.
But that conclusion is, like you said, absurd, and I never should've implied otherwise. I wasn't thinking when I wrote it.
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.
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.
(I did, cannot recall that password so far and it's not in lastpass for some reason - maybe too long ago/before I got into that habit)
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.
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.
Earlier quoted context omitted.
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.
> To be fair, your bank likely has a bit more money to throw at this problem. I suppose they could charge 1 USD for (lifetime) membership and store the last four digits of your credit card in lieu of a username, so that they could easily look up the salt that gives the salt with witch they've hashed your email... ;-) (Would require that you could supply the last digits of your possibly expired credit card, when you l…