For an article of such importance, to botch the visualisations so badly, to the point of being unreadable, is absurd. Can they not afford to get a designer or data viz person to spend a day and put the data in a decent choropleth map so we can actually see the maps clearly?
yes, this is ironical. I was away and thanks for the HN hug of death my blog went down :-). My blog provider throttled it down severely and I was able to restore it from backups just now. I blog occasionally to put down notes on what ever I am working on or thinking through, in the hope that maybe it would help some one or myself in the future. Apologies if I wasted your time.
My retina MBP developed a really sticky 'L' key. A few blasts of compressed air and a few taps it sorted it out completely. Your mileage may vary, but worth a go.
Maybe a stupid question, but once your list grows large, how would you then check if a new address is in your salted hashed list without iterating over every item? Unless I’m mistaken, you can’t index salted hashed lists unless the salt is predictable (which defeats the purpose of a salt).
It does not entirely beat the purpose of a salt, because still the existence of a rainbow table for that particular combination of algorithm and salt is a lot less likely than for the algorithm unsalted.
As for your question, a solution could be to allow the account at first and perform regular checks in the background. It won't make a big difference if the account is never created or deleted within 10 minutes. In fact, the latter could be better, because it will be harder to check for any outsider (including the offender) whether an address is blocked, which is good for privacy and helps keep the offender busy, because they can't use a different address right way—they first spend some time in vain.
> However, this would also mean that logging in using an email/username would also require a full scan
No it wouldn’t, and that’s what makes this specific case different. In your scenario, you can lookup the column you need by username or email, which is indexed. You can then retrieve the unique salt and password hash with no lookup penalty. This is not possible in the other case because there is no known column that can serve as the index.
It is great to see more people sharing their strategies for managing legacy codebases. However, I thought it might be worth commenting on the suggestion about incrementing database counters:
> "add a single function to increment these counters based on the name of the event"
While the sentiment is a good one, I would warn against introducing counters in the database like this and incrementing them on every execution of a function. If transactions volumes are high, then depending on the locking strategy in your database, this could lead to blocking and locking. Operations that could previously execute in parallel independently now have to compete for a write lock on this shared counter, which could slow down throughput. In the worst case, if there are scenarios where two counters can be incremented inside different transactions, but in different sequences (not inconceivable in a legacy code), then you could introduce deadlocks.
Adding database writes to a legacy codebase is not without risk.
If volumes are low you might get away with it for a long time, but a better strategy would probably just to log the events to a file and aggregate them when you need them.
We are also now starting to use Okta and SSO extensively too.