adameasterling

A spokesman for CalTrans claimed today that Bay Bridge could have taken the same hit without damage, thanks to fenders that protects all pylons for all bridges in the San Francisco Bay Area (1). Cargo ships are heavy, yes, but it appears we have the technology to prevent bridge collapses due to these sorts of collisions today.

1. "The Bay Bridge’s fenders insulated the span during the 2007 incident, so that the Cosco Busan ship struck a bumper, never hitting the bridge itself, Ney said. He noted that fenders on Bay Area bridges should be able to handle a ship traveling at 8 knots, the velocity at which the ship hit the Francis Scott Key span."

> I'm not sure we need more high-end development - those tenants have plenty of options.

Evidence is strong that market-rate construction causes richer residents to exchange their current unit for a higher-end unit, opening up supply at the lower end. [3]

The problem with BMR requirements is the increased costs borne by developers, who have to offset those increased costs by charging more for the market rate units. There's a limit to that market, so fewer units are constructed than otherwise would be. Middle class families are especially worse off, as they neither qualify for BMR lotteries, nor earn enough for the rapidly accelerating market-rate unit. [4]

Further, rents are lower in states that disallow BMR mandates (like Texas) than those that have BMR mandates (like California).

The Open Web Application Security Project's Application Security Verification Standard recommends that you do a hashed password check [2].

For bigger companies, sure, go talk to legal, but for young startups, my feeling is it's not worth the $200 or whatever your counsel will charge to say it's ok. I personally did not ask anyone (am cto), I just added the check.

I don't have anything to back this up, but my guess is that the vast majority of compromised user accounts comes from credential stuffing/password re-use. It's really surprising to me when I hear that huge companies don't do this check.[2] It's simple, easy, takes about a day to set up.

If you're a young CTO or early-stage engineer working on a web app and have never been targeted with a credential stuffing attack, let me tell you: It's coming! It's just a matter of time before it's 1AM and your phone blows up; your site is getting hammered; you think it's DDOS, but then realize most of the hits are on your login page, then realize that and then realize with a horrible feeling that some % of those hits are getting through the login page. You'll be up all night dealing with it, and then you have to make breach notifications, and that really sucks.

Troy Hunt's free database will save you that heartache (probably). Just do it.

In my opinion, it is, actually, on 23andMe. At my tiny startup, I implemented a simple check against Troy Hunt’s compromised password database.[1] If I can do it, 23andMe can.

If anyone reading this is in the business of making web apps and there’s literally anything of value behind your login, prioritize this mitigation. OWASP recommends it too. [2]

It’s very simple, and I believe has been an accepted best practice since like 2017. This is 100% on 23andme. They are responsible.