Tell HN: Zoom truncates passwords to 32 chars

[saimiam]

I tried to reset my password to a random alphanumeric string, 64 characters in length.

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.

[koolba]

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

[hellcow]

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.

[duxup]

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.

[satya71]

Indeed, I spent hours trying to figure out what was going wrong.

[infogulch]

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.

[Sammi]

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.

[sneak]

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.)

[smartbit]

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.

[davidg109]

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.

[freehunter]

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.

[0xFluegel]

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...

[roter]

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...

[duxup]

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.

[l31g]

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)...

[moltar]

Tangerine uses 6 digits

[prostanac]

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).

[meowface]

How recently were they doing that? That would be utterly insane in 2005, let alone 2020.

[pdexter]

charles schwab did that up to about 4 or 5 years ago

[0xFluegel]

> 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.

[tachyonbeam]

Wait a minute there young man, your password can only possibly be safe if it contains lowercase, uppercase, numeric and non alphanumeric characters!

[snazz]

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).

[londons_explore]

> 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...

[lilott8]

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.

[zelon88]

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.

[nickthemagicman]

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.

[rootusrootus]

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.

[psim1]

What is your expectation for allowed password length and why?

[wishinghand]

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.

[cmcd]

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?

[nicky0]

For me it's not the maximum length which is the issue. It's the silently accepting input which is too long.

[saimiam]

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.

[masklinn]

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.

[Hamuko]

I find 64 characters a pretty reasonable expectation.

[benmmurphy]

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.

[throwaway55554]

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.

[randunel]

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.

[rshnotsecure]

Apple does this too. Gmail is the best, something like at least 99 characters allowed.

[satya71]

Still much better than most banks and miles ahead of ssa.gov

[sm2]

I suspect these Zoom posts are primarily aimed at damaging the brand, rather than highlighting product flaws.

[thanatropism]

Then, your user account is more "suspect" than the original poster's.

[dgritsko]

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.

[asveikau]

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...

[lainga]

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??

[justapassenger]

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.

[MPSimmons]

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.

[_jal]

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.

[dmitriid]

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.

[hsnewman]

So is today attack Zoom's security day?

[hkchad]

Can we PLEASE put a stop to the endless 'crap on zoom' articles on HN, this is getting out of hand.