Rate limiting login attempts is a basic security principle that's both easy to implement and not overly intrusive. This once again confirms that Zoom just doesn't care about having a secure platform at all.
> This once again confirms that Zoom just doesn't care about having a secure platform at all.
I disagree. I think it shows that Zoom (at the time this was created) lacked the skill necessary to create a secure platform. But their prompt reaction and subsequent focus on security has given me hope.
According to wikipedia Zoom was founded in 2011, has 2000+ employees and had revenue of 600M last year. I somehow doubt that if they cared, it would be a problem for them to hire a security consultant (internal or external) and perform some pentests and I believe any professional pentester would find stuff like this AND their previous security mishaps (their definition of "end-to-end encryption", mac app backdoors, etc...)
I thin theyve been big enough long enough to have a guy or two who could look at the functionality or even the codebase and say: ' hold on a minute,how on earth we are doing this'.
It's pretty freaking hard to convince a PM to care about security. For that matter it's pretty hard to convince most engineers, let alone companies, even after a hack. Imagine yourself talking to the general counsel after an elasticsearch db gets hacked about ethical obligations to make customers whole. Then imagine that GC saying literally "ethics? It's not like we're building bridges here".
If a website stores passwords in cleartext instead of hashes, would you have the same response?
This isn't fancy stuff. This doesn't require tens of thousands of dollars in code-audits or pentests to come to light. It's literally the absolute basics of password management. There should be no need to "convince a PM".
Rate limiting, not silently truncating passwords, not setting an extremely low and arbitrary maximum on password length... All of this stuff is as basic as hashing a password.
I'm saying I've been in exactly that position in many companies. Spent all of my social capital to get password hashes fixed, or a hacked DB audited, or circuit breakers, or rate limits, alerts, admin and monitoring tools, etc. It's really easy to preach here on HN. Saying it's an uphill battle "out there" is a drastic understatement.
I get where you're coming from, I do these types of engagements often. I just wanted to highlight the difference between "Please spend $25,000 on this pentest engagement" and "Don't set a maximum password length of 10" or "Don't set the default password to be 6 digits".
One is an investment and requires convincing a PM or C-Suite. The other two are some of the most basic concepts possible (literally first semester, if not first week of CS) in the design of anything that has to do with a password.
The other two are some of the most basic concepts possible (literally first semester, if not first week of CS) in the design of anything that has to do with a password.
There are still ways this can fail: e.g. tech lead on a team full of good but uninformed bootcamp devs with an absentee manager and a domineering PM, run as a democracy when only a minority have (formal or self-taught) CS education. If the PM doesn't like your recommendation they'll get one of the bootcampers to do a crappy job without telling you.
That would help a bit, but you could probably still get the hash of the password and infinitely try. I honestly think them capping password at 10 characters is more egregious.
