HN user
[ my public key: https://keybase.io/ermanc; my proof: https://keybase.io/ermanc/sigs/We6gefFcJKnFOBUazQmR_Kt6mW-BEgJKaRbvalykSq4 ]
While wealth (or rather, being "wealthy") is absolutely a success, it is not the only way to succeed nor is its definition "not being poor".
As such, I'd like to believe people at places like /r/povertyfinance would still consider themselves successful if they moved beyond their financial challenges through a ton of work even if they don't end up wealthy.
Simply by grouping clients into rooms by their public IP.
You can be discovered by everyone on this network
Assumption here being that the devices on the same network are all NAT'd behind the same public IP, which usually holds true.
See the server code for designating rooms & peers: https://github.com/RobinLinus/snapdrop/blob/master/server/in...
Can also test that there is no "discovery" beyond public IP grouping by turning off wifi on your mobile and joining from mobile network.
To be fair, Recurecur said:
New reactor designs completely eliminate the possibility of meltdown.
not necessarily of any failure, to which they were willing to accept that things can fail in novel ways, just not meltdowns in their view.
Taking unnecessarily long to handle a lookup request might leave server very vulnerable to DDoS attacks leveraging this "account recovery" option, I think.
Even worse, an invalid email would take the longest possible time, every time.
And since this is only an email address we are talking about, a global salt + more stretching (like runamok mentioned above) could be secure enough while still providing faster lookups.
Right, which is why I said
figuring out what the original email should be hard (if not impossibly hard, depending on how they hash it)
I mean, passwords are way more sensitive than emails, especially given that many people re-use them. So, how you hash passwords is more critical than how you hash emails (which is rarely done, I guess).
On the other hand, there is no reason to not have the same level of protection for emails, if you are already following best practices for passwords anyway (PBKDF2, bcrypt, scrypt etc.).
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 it).
Am I missing something here?