
Tell HN: Zoom truncates passwords to 32 chars - saimiam
I tried to reset my password to a random alphanumeric string, 64 characters in length.<p>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.<p>Annoyed, I changed the first few alphabets to uppercase and this time zoom accepted the new password.<p>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.<p>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](https://news.ycombinator.com/item?id=13838342)

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

~~~
rootusrootus
I would bet it has become much more common since correct horse battery staple.

~~~
SwiftyBug
Related xkcd: [https://www.xkcd.com/936/](https://www.xkcd.com/936/)

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

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

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

~~~
Sammi
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](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
[1]
[https://en.wikipedia.org/wiki/Key_derivation_function](https://en.wikipedia.org/wiki/Key_derivation_function)

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

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

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

~~~
yc-kraln
easy enough; on next successful login re-hash the full length of the password
and store it.

~~~
Someone
That would be somewhat risky; the user might have mistyped the password
somewhere in the part that up to now got ignored.

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

~~~
SwiftyBug
And god forbid that you repeat two characters in sequence

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

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

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

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

~~~
efreak
That's why salts are used

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

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

------
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...](https://www.schneier.com/blog/archives/2019/07/zoom_vulnerabil.html)

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

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

------
hsnewman
So is today attack Zoom's security day?

~~~
Hamuko
Is today a day that ends in Y?

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

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

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

~~~
ZitchDog
The existence of zoom is saving lives. Outrage against zoom is misplaced.

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

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

