Tell HN: Zoom truncates passwords to 32 chars
117 comments
That’s not as bad as Apple which silently removes white space within your password but doesn’t actually tell you it did that leading to locking yourself out after multiple attempts:
https://news.ycombinator.com/item?id=13838342
https://news.ycombinator.com/item?id=13838342
I was bit by this. Spent _hours_ on the phone with Apple support. They couldn't let me back in, and I was locked out for a week.
They escalated to tier 2, then to engineering. It's really disappointing this wasn't fixed.
They escalated to tier 2, then to engineering. It's really disappointing this wasn't fixed.
I honestly don't think I've used a space in a password before... not that it matters as far as the bug goes, but it just occurred to me.
I would bet it has become much more common since correct horse battery staple.
Related xkcd: https://www.xkcd.com/936/
Adding spaces to a jumble of characters is probably uncommon, but using something like a sentence as a password is very common, and also the main reason you want to support long passwords.
Indeed, I spent hours trying to figure out what was going wrong.
I found out the main reason why passwords are limited length even when using modern hashing techniques.
The problem is caused by the way multi-round password hashing algorithms are designed. Specifically, in each round, the full contents of the password is concatenated with the previous round's hash result as the input to the next round. This means that the processing complexity of password hashing is proportional to `number of rounds * password length`. Because the implementation has to tune the number of rounds to their authentication server's performance, and because the tuning is performed on "normal length" passwords, this opens the authentication servers up to a DOS attack by overwhelming them with very long passwords which is only a problem because password hashing has quadratic complexity thanks to this design. Thus, in response, administrators are forced (!) to limit password length just so their authentication servers can't be attacked.
This design flaw (imo) could be pretty easily solved by hashing the user provided password once first, and then using that hash to concatenate each round. This changes the complexity to `number of rounds + password length` (note the "+" !). As a secondary benefit, the multi-round hashing step actually becomes constant time because all inputs are the same length! In fact, I wonder if the current design makes it possible to infer a user's password length from timing attacks on the authentication servers while a user is logging in.
I've not got any satisfactory cryptographic reason why we still use this design for password hashing besides platitudes like "don't roll your own crypto", appeal to authority "It's been designed by the experts", or stupid reasons like "but network bandwidth!" -- as if an http authentication request that's 4kb is gonna slow down the network vs a 3kb request (and this is a worst case of a relatively huge 1kb password!). Availability is an important part of security, and sacrificing both availability (vulnerability to DOS) and security (admins forced to limit password length) seems like a doubly whammy argument against the current design.
The problem is caused by the way multi-round password hashing algorithms are designed. Specifically, in each round, the full contents of the password is concatenated with the previous round's hash result as the input to the next round. This means that the processing complexity of password hashing is proportional to `number of rounds * password length`. Because the implementation has to tune the number of rounds to their authentication server's performance, and because the tuning is performed on "normal length" passwords, this opens the authentication servers up to a DOS attack by overwhelming them with very long passwords which is only a problem because password hashing has quadratic complexity thanks to this design. Thus, in response, administrators are forced (!) to limit password length just so their authentication servers can't be attacked.
This design flaw (imo) could be pretty easily solved by hashing the user provided password once first, and then using that hash to concatenate each round. This changes the complexity to `number of rounds + password length` (note the "+" !). As a secondary benefit, the multi-round hashing step actually becomes constant time because all inputs are the same length! In fact, I wonder if the current design makes it possible to infer a user's password length from timing attacks on the authentication servers while a user is logging in.
I've not got any satisfactory cryptographic reason why we still use this design for password hashing besides platitudes like "don't roll your own crypto", appeal to authority "It's been designed by the experts", or stupid reasons like "but network bandwidth!" -- as if an http authentication request that's 4kb is gonna slow down the network vs a 3kb request (and this is a worst case of a relatively huge 1kb password!). Availability is an important part of security, and sacrificing both availability (vulnerability to DOS) and security (admins forced to limit password length) seems like a doubly whammy argument against the current design.
Easy fix:
Apply a regular ol hash function first, so the input to the the cryptographic hash function is the short'ish fixed length output of the regular hash function.
A good regular hash function will preserve the entropy of a long input password, so it doesn't hurt, and it solves the problem you present.
Bonus points for doing this on the client side so that you're not even using extra network bandwidth.
Apply a regular ol hash function first, so the input to the the cryptographic hash function is the short'ish fixed length output of the regular hash function.
A good regular hash function will preserve the entropy of a long input password, so it doesn't hurt, and it solves the problem you present.
Bonus points for doing this on the client side so that you're not even using extra network bandwidth.
Is this sarcastic? If your regular hash function isn't cryptographically secure then it doesn't guarantee lots of things that normal hash functions do. You are potentially reducing the input/preimage to your cryptographic hash function to the output/image of your insecure hash function, which could compromise the cryptographic hash's preimage resistance. Maybe a better point, what happens if there's a collision in your regular hash function?
Sammi is clearly assuming a cryptographically secure hash here which shouldn't provide any obvious problems with the method he proposes as far as I can tell.
Yeah I've mixed up my terms here. Sorry.
By regular ol hash I mean a Cryptographic Hash Function [0] (as in SHA1, SHA2...) and by cryptographic hash i mean a Key Derivation Function (as in bcrypt or argon2).
[0] https://en.wikipedia.org/wiki/Cryptographic_hash_function [1] https://en.wikipedia.org/wiki/Key_derivation_function
By regular ol hash I mean a Cryptographic Hash Function [0] (as in SHA1, SHA2...) and by cryptographic hash i mean a Key Derivation Function (as in bcrypt or argon2).
[0] https://en.wikipedia.org/wiki/Cryptographic_hash_function [1] https://en.wikipedia.org/wiki/Key_derivation_function
PayPal actually limits a password’s maximum length(!) to 20 characters.
(I finally deleted my account there yesterday after close to 20 years; I should have done so years ago.)
(I finally deleted my account there yesterday after close to 20 years; I should have done so years ago.)
Wish Paypal would allow closing accounts if it is locked. Have one lingering around because my bank made a mistake and no way to access it without sending them tons of personal data.
I created a second one which worked but not using it any more. Will follow suit and close it too.
I created a second one which worked but not using it any more. Will follow suit and close it too.
You think that’s bad? A bank here in Canada, Bank Of Montreal, was using a maximum of 8 characters (and I believe no special chars permitted). Couldn’t use them anymore.
I used to work infosec at a financial institution and I can explain why this is: the online banking systems have historically been extensions of the phone system. When bank-by-phone was popular, you’d have a four digit PIN to authenticate yourself. When they moved online, they used the same backend system but just doubled the required length of the PIN.
So 8 digits or maybe 12 or 16 indicates the system runs on a modified bank by phone system. That also means they have to restrict password characters to things that would work on a phone keypad.
Another place I worked had the same problem with passwords because any password that you use might have to be entered into a handheld scanner in the warehouse. And those handhelds didn’t have full keyboards so you could only use characters that exist on the handheld’s keyboard.
So 8 digits or maybe 12 or 16 indicates the system runs on a modified bank by phone system. That also means they have to restrict password characters to things that would work on a phone keypad.
Another place I worked had the same problem with passwords because any password that you use might have to be entered into a handheld scanner in the warehouse. And those handhelds didn’t have full keyboards so you could only use characters that exist on the handheld’s keyboard.
My german bank Haspa has a limit of 12. My guess for the reason -- apart from "we didn't have any problems, yet" -- is that part of the relevant infrastructure is ancient and uses a hardcoded max length...
They're now asking for new passwords:
* minimum of 8 characters
* one uppercase and lowercase letter
* one number
* one special character
They should just allow any character instead of requiring characters. At least they allow longer passwords...
* minimum of 8 characters
* one uppercase and lowercase letter
* one number
* one special character
They should just allow any character instead of requiring characters. At least they allow longer passwords...
I had a bank do that to me too.
I was logging in and sure I typoed my password but it worked.
Then I tried typoing it again and it failed.
Then I started to wonder ... yeah after like 8 characters it just didn't matter.
I emailed them and did not get a response, but to their credit they fixed it within about a month. Maybe that was planned already but at least they fixed it.
I was logging in and sure I typoed my password but it worked.
Then I tried typoing it again and it failed.
Then I started to wonder ... yeah after like 8 characters it just didn't matter.
I emailed them and did not get a response, but to their credit they fixed it within about a month. Maybe that was planned already but at least they fixed it.
If they could just fix it, it seems like they must be storing user credentials insecurely. At least, I can't figure out how to fix something like this without at least a password change for all users.
You mark the existing hashes as “only use the first 8 characters to compute the hash” and, from now on, clear that bit for every password that gets changed and for new accounts.
When all bits have been cleared, remove the logic for inspecting the bit and the mark bit. If that takes too long, force your users to update their password at whatever pace suits you.
When all bits have been cleared, remove the logic for inspecting the bit and the mark bit. If that takes too long, force your users to update their password at whatever pace suits you.
Oh I wouldn't be surprised.
A few years later I actually had visibility inside that bank due to my work. There was a whole IT team dedicated to "review this and fix the horrible decisions we made in the past". I didn't have visibility to their web interactions / front end and such but it wouldn't surprise me if that was just as much a project to clean up.
To their credit whenever I talked to the "clean up" type team they were super sharp guys and quite willing to listen to outside vendors (me) who sometimes saw stuff the guys inside maybe didn't.
A few years later I actually had visibility inside that bank due to my work. There was a whole IT team dedicated to "review this and fix the horrible decisions we made in the past". I didn't have visibility to their web interactions / front end and such but it wouldn't surprise me if that was just as much a project to clean up.
To their credit whenever I talked to the "clean up" type team they were super sharp guys and quite willing to listen to outside vendors (me) who sometimes saw stuff the guys inside maybe didn't.
Last time I changed my username and password for my AmEx login, their rules were very restrictive with the username (I couldn't use numbers at the beginning of it) and password (I could't use characters like commas or periods)...
Tangerine uses 6 digits
In Romania ING limits the password to 5 digits. However SMS 2FA is enabled by default (iirc, have been many years since I have this banking account).
How recently were they doing that? That would be utterly insane in 2005, let alone 2020.
charles schwab did that up to about 4 or 5 years ago
> While 32 chars is plenty long for a password, [...].
It might be plenty long for completely random characters, but when one uses a word sequence, the 32 characters are easily reached.
It might be plenty long for completely random characters, but when one uses a word sequence, the 32 characters are easily reached.
Wait a minute there young man, your password can only possibly be safe if it contains lowercase, uppercase, numeric and non alphanumeric characters!
And god forbid that you repeat two characters in sequence
I imagine that this limitation is fairly common, although it probably wouldn't cost them any more to move to truncating at 512 characters or something like that. There has to be a limitation at some point to prevent denial of service attacks caused by hashing super long passwords. Maybe 32 characters seemed like a reasonable choice when they set the system up. I'm guessing that a large number of rounds of a secure hash function on 32 chars is more secure than a smaller number of rounds on 64 chars (given that most passwords are well under 32 characters long).
> I'm guessing that a large number of rounds of a secure hash function on 32 chars is more secure than a smaller number of rounds on 64 chars (given that most passwords are well under 32 characters long).
The number of rounds increases brute-force complexity linearly.
Adding more characters increases complexity exponentially.
Exponential is exponentially better than linear...
The number of rounds increases brute-force complexity linearly.
Adding more characters increases complexity exponentially.
Exponential is exponentially better than linear...
But if the average password length is 12 characters, does the maximum password length make any difference for the average user? More characters would certainly be better for those users who generate super long passwords, but for the service as a whole I would think that setting a lower maximum and more rounds would be better.
Did I misunderstand something?
Did I misunderstand something?
[deleted]
I have a sneaking suspicion that xfinity does this. When signing up they said there were no password restrictions. So I generated ~64 character password using my trusty password manager, and used that. Went to log in and couldn't, wrong password. So I changed my password, again ~64 characters, with the old trusty companion. Again, couldn't log in.
Finally, I just changed my password to a randomly generated password of a commanding ~16 characters and haven't had a problem logging in since. I've spent more time than I care messing with my password on xfinity's site. There was exactly no scientific endeavor, and is purely conjecture. But it really feels as though there is some chicanery happening with passwords.
Finally, I just changed my password to a randomly generated password of a commanding ~16 characters and haven't had a problem logging in since. I've spent more time than I care messing with my password on xfinity's site. There was exactly no scientific endeavor, and is purely conjecture. But it really feels as though there is some chicanery happening with passwords.
I usually try to sneak comment characters and sequences from various languages into my passwords. That way if I sign up for a new account somewhere and the website gives me some really unexpected output back after I click "submit" I know that I probably don't want an account there anyway. Plus I feel like there's a chance it could screw up some script kiddies scripts if he gets my password into a wordlist for some second-rate hacking tool.
Do people make passwords longer than 32 chars?
I was under the impression that with 16 random ascii characters it would take all of the computing power on earth until the heat death of the sun to crack it.
I was under the impression that with 16 random ascii characters it would take all of the computing power on earth until the heat death of the sun to crack it.
Ever since correct horse battery staple, I'd bet plenty of people are going for long passwords. Though that might be offset by the surge in popularity of password managers.
Seems like a series of words would be susceptible to rainbow table attacks and brute force via dictionary.
I would toss in a numeric or a special character to really make it strong.
I would toss in a numeric or a special character to really make it strong.
That's why salts are used
What is your expectation for allowed password length and why?
It’s not so much why the OP thinks they’re entitled to arbitrary password length, it’s that the UI/UX does nothing to inform the user of this. And also the bytes they save restricting password length to 32 instead of 128 or 256 would be a few dollars rounding error in the end of the Year budget.
I fucking hope they don’t save any bytes doing that given that’d mean the passwords are stored in clear text.
Though given what we’ve seen so far once people started taking a look that’s not out of the realm of possibility.
Though given what we’ve seen so far once people started taking a look that’s not out of the realm of possibility.
[deleted]
I am really struggling to come up with a situation where this would actually matter. I guess if for some reason the first 32 characters of my password got leaked but not the next 32? But why would that ever happen, and who wouldn't change their password in that situation anyway?
32 characters might be safe, but we could make the same argument for 16 characters, yet there is a huge vulnerability there: Someone might have a perfectly secure series of words as a password, but only the first three words survive truncation. Now they can be brute-forced easily.
It's bad form in general to truncate a password.
It's bad form in general to truncate a password.
proper hashing yields no saving of bytes.
You're right, I forget about that. Which is why I'm not a backend programmer.
You are only storing the hash of the password so there is no reason to have arbitrary length constraints like 32. Why not make it several thousand characters?
There is actually a reason (though 32 seems pretty short. Something like 256 is probably more reasonable).
Several thousand characters (or worse, unlimited length) opens up your attack to a form of DDoS where you can exploit the fact that password hashing is a computationally heavy operation. See here: https://arstechnica.com/information-technology/2013/09/long-...
> Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large—and guaranteed-to-fail—passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher. This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.
Several thousand characters (or worse, unlimited length) opens up your attack to a form of DDoS where you can exploit the fact that password hashing is a computationally heavy operation. See here: https://arstechnica.com/information-technology/2013/09/long-...
> Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large—and guaranteed-to-fail—passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher. This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.
55 would make sense if they are using bcrypt. But since it's 32, they're probably not actually securely storing (password hashing) them at all.
The real problem there is using an algorithm that gets slower on longer passwords.
There's no need to have a cap bigger than a kilobyte though.
There's no need to have a cap bigger than a kilobyte though.
Is there a cryptographic hash algorithm that doesn't? It seems like that would make it non-cryptographic (since you will need to read each byte at least once).
Reading each byte once only takes a few microseconds. That's not the issue.
What you need is for the slow core of the algorithm to be fixed-speed.
Either by only reading the input bytes during initialization, or by only feeding a fixed number of input bytes into the core during each round.
What you need is for the slow core of the algorithm to be fixed-speed.
Either by only reading the input bytes during initialization, or by only feeding a fixed number of input bytes into the core during each round.
Isn't this mitigated by hashing the password on the client (in addition to hashing it on the server).
But couldn't an attacker just skip the client-side hashing?
Then the server will reject it for being the wrong size.
The GP suggested it would also be hashed by the server - presumably because you can't trust client input.
You would hash it on the server because you don't want to turn the 'hash' into a plain-text password.
But instead of the server accepting an arbitrary string, it only accepts hexadecimal or base64 strings of a specific length. Which solves the problem.
But instead of the server accepting an arbitrary string, it only accepts hexadecimal or base64 strings of a specific length. Which solves the problem.
I'm not quite understanding the protocol here.
If the client sends only a hex/base64 string, how can the server trust that it's the result of a password being fed to a KDF?
If the client sends only a hex/base64 string, how can the server trust that it's the result of a password being fed to a KDF?
[deleted]
It doesn't matter.
The threat model is: Password is too long, lots of CPU is wasted, denial of service.
By only accepting strings of a certain length, the threat is defeated.
The client could send an intentionally bad password even if they weren't lying. If they lie, only the client is harmed, and in a non-new way.
So this scheme has one notable upside, and no notable downside.
There are better solutions, but this one is valid.
The threat model is: Password is too long, lots of CPU is wasted, denial of service.
By only accepting strings of a certain length, the threat is defeated.
The client could send an intentionally bad password even if they weren't lying. If they lie, only the client is harmed, and in a non-new way.
So this scheme has one notable upside, and no notable downside.
There are better solutions, but this one is valid.
Hmm, I can see some benefits to the scheme, such as using the client's CPU cycles, and the plaintext password never having to be sent to my servers.
Maybe it's just that it's not the norm, but I'm still unsure I'd actually use this scheme.
As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries.
TBH, my preferred solution here is never to silently truncate passwords, and just to set a "sensible" limit on password length, e.g. 256 characters. Yes, it's still an arbitrary limit, but it should be long enough to cover 99.9999% of users.
Maybe it's just that it's not the norm, but I'm still unsure I'd actually use this scheme.
As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries.
TBH, my preferred solution here is never to silently truncate passwords, and just to set a "sensible" limit on password length, e.g. 256 characters. Yes, it's still an arbitrary limit, but it should be long enough to cover 99.9999% of users.
> As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries.
The code doing the client-side hashing is just as secure as the rest of the client interface. You don't compromise anything by doing it.
Still, it's easier to do the extra hash locally on the server if you need it.
The code doing the client-side hashing is just as secure as the rest of the client interface. You don't compromise anything by doing it.
Still, it's easier to do the extra hash locally on the server if you need it.
How?
Yep. You do want a limit though as you don’t want random attackers to DOS your login server by feeding megabytes you your kdf.
For me it's not the maximum length which is the issue. It's the silently accepting input which is too long.
I usually sha256sum a string whose format I know to generate the 64 char password. My expectation of password length is that I should simply paste the result into the password field and not have to think about it any more.
Why: len(sha256sum(str)) = 64.
Why: len(sha256sum(str)) = 64.
A few hundred to thousand characters, because you don’t want to send megabytes of garbage to your KDF and that’s more or less the only reason to limit password length.
Also if you put a limit, don’t silently truncate.
Also if you put a limit, don’t silently truncate.
I find 64 characters a pretty reasonable expectation.
a lot of people use bcrypt and that has effective truncation at 72 bytes unless you are pre-hashing for longer inputs or doing something else non-standard.
I guess Zoom devs have never heard of "no artificial limitations".
Yes, there are going to be limitations; no resource is infinite. But 32 chars is just too arbitrary.
Yes, there are going to be limitations; no resource is infinite. But 32 chars is just too arbitrary.
This used to be an issue with ebay.com back in the day. I used to be able to log in, but not change my password, because the length constraints were different.
[deleted]
Apple does this too. Gmail is the best, something like at least 99 characters allowed.
Still much better than most banks and miles ahead of ssa.gov
I suspect these Zoom posts are primarily aimed at damaging the brand, rather than highlighting product flaws.
Then, your user account is more "suspect" than the original poster's.
No affiliation with Zoom, but wow - the unrelenting torrent of negative coverage on HN over the last few days has been remarkable. It seems there's at least two or three negative articles on the front page at all times.
There was plenty of criticism before. Remember they were the company that ran an unauthenticated web server bound to localhost so that any website could make requests to it and get the video stream. And they made it so that an uninstall wouldn't remove that.
That was July.
https://www.schneier.com/blog/archives/2019/07/zoom_vulnerab...
That was July.
https://www.schneier.com/blog/archives/2019/07/zoom_vulnerab...
Zoom IPOd in mid-April 2019. In terms of "start up that made it" or "growing pains", this is what happens when you don't hire a seasoned PR team (and even then). No one was looking all that hard at Zoom's technical practices because no one technical cared that much. Now that the UK Prime Minister is tweeting screenshots which include the zoom meeting ID, it's suddenly become a lot more interesting to lots of people, some of them less scrutable than others.
Zoom's older competitors; Microsoft (Skype), Google (Meet), WebEx, etc have undergone similar scrutiny with the similar results - bad press followed by engineering fix.
Zoom's older competitors; Microsoft (Skype), Google (Meet), WebEx, etc have undergone similar scrutiny with the similar results - bad press followed by engineering fix.
It actually sounds more like technical hiring and engineering culture was not good, rather than just PR.
I know we all make mistakes, bugs happen, etc. However, if you can't reason through why it's not safe to bind an HTTP server to localhost and consider clients trusted on a laptop that might also run a web browser ... This and other prominent bugs suggests that among other things, security was not a part of the culture or mindset of the rank and file. I don't think you can use "it's a startup, bro" as an excuse for that.
I know we all make mistakes, bugs happen, etc. However, if you can't reason through why it's not safe to bind an HTTP server to localhost and consider clients trusted on a laptop that might also run a web browser ... This and other prominent bugs suggests that among other things, security was not a part of the culture or mindset of the rank and file. I don't think you can use "it's a startup, bro" as an excuse for that.
> unauthenticated web server bound to localhost so that any website could make requests to it and get the video stream
I read the linked article. At no point did it (or as far as I can recall any of the coverage at the time) say that the video stream data could be accessed via the local web server. The problem was already bad; no need to make spurious claims to make it worse.
I read the linked article. At no point did it (or as far as I can recall any of the coverage at the time) say that the video stream data could be accessed via the local web server. The problem was already bad; no need to make spurious claims to make it worse.
Ok, maybe that was my slight misreading of the situation. It definitely involved use of the webcam without user consent, however. And an attacker could make you join a meeting that they control, effectively being able to watch and hear you.
Oh absolutely. I'm not trying to downplay the serious nature of the vulnerability, particularly because it also lead to the possibility of remote code execution. Just want to keep the record straight that at no point did this vulnerability allow people to actively spy on your legitimate meetings.
Excuse me, what the f? Link? edit: Thanks
I think directing the Eye of Sauron upon any company-required software is a modern form of collective bargaining. Individually, at many companies around the world, one engineer's concerns about Zoom or w/e will not reach or convince HR. But that same number of engineers all finding and publishing vulns in unison will convince the same number of admin people to not use Zoom. Because it gives a sense of "technical consensus" - the engineering-decision version of solidarity - I guess??
It's software that's taking over the world by the storm, suddenly used by countless companies, governments, hospitals, schools, etc.
They need scrutiny, especially given that their security record is subpar. Bad actors aren't self-isolating themselves from internet during pandemic.
If I were a bad actor, I'd totally go after Zoom as an attack vector, given its sudden adoption, without proper security reviews by organizations.
They need scrutiny, especially given that their security record is subpar. Bad actors aren't self-isolating themselves from internet during pandemic.
If I were a bad actor, I'd totally go after Zoom as an attack vector, given its sudden adoption, without proper security reviews by organizations.
That's just because their approach to building secure software for the masses is garbage.
This software smells like it started as an internal tool for a company that escaped.
This software smells like it started as an internal tool for a company that escaped.
It certainly has a weird janky feel for how it integrates with the system.
My wife sent me a link to join a meeting for testing. Normally when you have a link and want to have a desktop app use it there's some protocol handler that's registered with the app.
Nope - you click the link, it downloads what appears to be an on-the-fly generated exe that talks to desktop zoom.
I get the "remove all friction" sentiment but it feels so off compared to any other web/desktop stack of technology.
My wife sent me a link to join a meeting for testing. Normally when you have a link and want to have a desktop app use it there's some protocol handler that's registered with the app.
Nope - you click the link, it downloads what appears to be an on-the-fly generated exe that talks to desktop zoom.
I get the "remove all friction" sentiment but it feels so off compared to any other web/desktop stack of technology.
Any time something gets this sort of massive usage boost it is going to be targeted by security researchers.
The best way to weather it is to write secure software that doesn't do stupid thngs (like reinventing sudo without protections) and not to slimy things (like trying to deceive your users about your lack of end-to-end encryption). If you choose to do those things instead, people are going to talk about it.
The best way to weather it is to write secure software that doesn't do stupid thngs (like reinventing sudo without protections) and not to slimy things (like trying to deceive your users about your lack of end-to-end encryption). If you choose to do those things instead, people are going to talk about it.
Because many more people have started using it and are running into a multitude of issues... with everything.
It doesn't help that Zoom has a history of bad practices. Just last year Apple had to issue a silent security updates to macOS to patch Zoom's zero day vulnerabilities Zoom denied existed.
It doesn't help that Zoom has a history of bad practices. Just last year Apple had to issue a silent security updates to macOS to patch Zoom's zero day vulnerabilities Zoom denied existed.
It's a side effect of the flurry of covid stories. See https://news.ycombinator.com/item?id=22751116 for more.
I think that people are taking discount shorts of the stock (which are unlikely to pay out right now) and then trying to cause price dips to profit from disclosing their information. If someone just released a zero day about Zoom without prior disclosure to Zoom, it would be a useful thing for the SEC to look into more closely.
I've noticed this too. It's also on other news sites like Slashdot. It comes off like a smear campaign
I don't think so, the criticism seems well-deserved. It just seems like a natural effect of being thrust into mainstream consciousness due to more people using it while working from home.
The edge cases get a lot more attention when the sample size is increased.
I'm not at all saying this is one, but this is what an organized campaign looks like.
Have you noticed the number of people claiming that Zoom is the subject of an organised campaign? I'm not saying it's an organised whitewashing counter-campaign, but that's what one looks like ...
... and so on
... and so on
So is today attack Zoom's security day?
Is today a day that ends in Y?
Feels like this whole week has been attack Zoom week.
Can we PLEASE put a stop to the endless 'crap on zoom' articles on HN, this is getting out of hand.
Is anyone else getting tired of all the zoom hate? Yes, they have problems. But this company is holding the world together during a global pandemic. The service has worked great, and it must be a herculean effort to keep things running during all this. Zoom devs, if you're reading this, thank you.
EDIT: I'm somehow being downvoted for expressing my gratitude to zoom for providing a service that is almost certainly saving lives. You're simply amazing HN, never change.
EDIT: I'm somehow being downvoted for expressing my gratitude to zoom for providing a service that is almost certainly saving lives. You're simply amazing HN, never change.
I'd argue that focus on Zoom's security is important now more than ever, precisely because so many people are now using the service.
And to be fair, having a 32-char password limit, and silently truncating passwords to that limit, are both pretty poor practise - especially nowadays, we just shouldn't be seeing flaws like this.
And to be fair, having a 32-char password limit, and silently truncating passwords to that limit, are both pretty poor practise - especially nowadays, we just shouldn't be seeing flaws like this.
The existence of zoom is saving lives. Outrage against zoom is misplaced.
Sorry, I think this product-worship is misplaced. Calling out security flaws does not mean you are "hating" on Zoom.
Furthermore, if you want Zoom to keep being beneficial, it's important that there is a focus on finding and fixing security flaws. How many lives is it going to save if attackers can use it as a springboard for malware, or if they can bomb into government or NGO meetings?
Furthermore, if you want Zoom to keep being beneficial, it's important that there is a focus on finding and fixing security flaws. How many lives is it going to save if attackers can use it as a springboard for malware, or if they can bomb into government or NGO meetings?
Calling out a major security flaw would make sense. Calling out clickbait security flaws like 32 bit password truncation in the context of a global pandemic is ridiculous. Zoom will fix things, but there is no better platform to host large, interactive events than zoom.
It's healthy to call out the flaws in products that you use and like.
Ideally the flaws get fixed, and you end up not having to compromise.
Ideally the flaws get fixed, and you end up not having to compromise.
Just because Zoom's product has value, doesn't mean that its product's problems should be ignored.
I'm just asking for things to be put in proper context. These problems are only being highlighted because zoom is providing an extremely valuable service during an unprecidented time. How many lives have been saved due to zoom allowing people to socially distance better? I'd guess quite a lot.
Video conferencing is a dime a dozen. There are so many other services, that I fail to see why Zoom should be given any sort of pass.
Facebook is probably one of the best ways to connect to and stay updated with your extended family during a time like this. Should they be given a free pass for any scandals that come to light during the pandemic?
Google is probably one of the best gateways to information about COVID-19. Should they be given a free pass for any scandals that come to light during the pandemic?
Facebook is probably one of the best ways to connect to and stay updated with your extended family during a time like this. Should they be given a free pass for any scandals that come to light during the pandemic?
Google is probably one of the best gateways to information about COVID-19. Should they be given a free pass for any scandals that come to light during the pandemic?
There is nothing that offers a "brady bunch" view in as scalable way as zoom does. It's enabling types of interaction that aren't available on any other platform.
If they can survive the onslaught and actually fix some of the more glaring issues, they may come out considerably stronger. They've got the attention of the world right now, for better or worse.
Are they? Other teleconferencing systems exist, in fact there's a multitide of them. Zoom's may be better in a few ways, but it's not like the world couldn't cope without them.
Initially, my password only had lower case letters and numbers. Zoom refused to allow me to use this string because it didn’t have any upper case letters. I figured they were only trying to help so I changed the last alphabet to upper case. Same error. I then thought that maybe they were expecting more than one upper case letter so I changed a few more letters in the second half of my password to upper case. Still the same error.
Annoyed, I changed the first few alphabets to uppercase and this time zoom accepted the new password.
I don’t recall what made me notice this but it turns out that zoom only takes in the first 32 chars of the password which it presumably stores in some hashed form in their backend.
While 32 chars is plenty long for a password, I just wish they’d mentioned this limitation on their website.