Tell HN: Zoom truncates passwords to 32 chars
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.
117 comments
[ 3.0 ms ] story [ 157 ms ] threadThe number of rounds increases brute-force complexity linearly.
Adding more characters increases complexity exponentially.
Exponential is exponentially better than linear...
Did I misunderstand something?
https://news.ycombinator.com/item?id=13838342
They escalated to tier 2, then to engineering. It's really disappointing this wasn't fixed.
(I finally deleted my account there yesterday after close to 20 years; I should have done so years ago.)
I created a second one which worked but not using it any more. Will follow suit and close it too.
It might be plenty long for completely random characters, but when one uses a word sequence, the 32 characters are easily reached.
* 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 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.
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.
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.
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.
Though given what we’ve seen so far once people started taking a look that’s not out of the realm of possibility.
It's bad form in general to truncate a password.
Why: len(sha256sum(str)) = 64.
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.
But instead of the server accepting an arbitrary string, it only accepts hexadecimal or base64 strings of a specific length. Which solves the problem.
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?
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.
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.
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.
There's no need to have a cap bigger than a kilobyte though.
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.
Also if you put a limit, don’t silently truncate.
That was July.
https://www.schneier.com/blog/archives/2019/07/zoom_vulnerab...
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.
Zoom's older competitors; Microsoft (Skype), Google (Meet), WebEx, etc have undergone similar scrutiny with the similar results - bad press followed by engineering fix.
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.
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.
This software smells like it started as an internal tool for a company that escaped.
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.
... and so on
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.
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.
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.
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?
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.
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?
Ideally the flaws get fixed, and you end up not having to compromise.
Yes, there are going to be limitations; no resource is infinite. But 32 chars is just too arbitrary.
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 would toss in a numeric or a special character to really make it strong.
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.
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.
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.
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