Clubhouse user IDs, Chatroom IDs are transmitted in plaintext over the internet | Hacker News Reader

Clubhouse user IDs, Chatroom IDs are transmitted in plaintext over the internet

twitter.com

179 pointsamrrs68 comments

Only peripherally related but after the recent Robinhood fiasco I downloaded the Interactive Brokers mobile app, and they send your login user/password in plaintext:

https://twitter.com/arkadiyt/status/1356054340008460293

They’re not exactly security literate. Here is IB defending no pasting of passwords from a password manager. I tweeted this early last year and I guess Troy Hunt just revived the issue with them. https://twitter.com/mmaunder/status/1243592529855078406?s=21

ING Bank forces me to use exactly 5 numbers as my password. That happened after an update 2 years ago, when I had a long and safe password. They forced me to "update to a more secure password".

So 12 characters is not secure, 4 numbers is not secure, 6 numbers is not secure either. 5 numbers is the best security!

I don't think this is true (plaintext part), maybe they are doing some custom encryption for snoopy corporate firewalls.

Very doubtful. Traders tend to prize speed over all other considerations, and so I'm sure at some point somebody with a Pentium running Windows 95 said this would be faster without SSL. And it really would be (on a sufficiently crappy machine, and assuming you're doing HTTP/1.1) but most of us have long since reasoned that "faster but now I don't have any security" is a bad trade and also meanwhile faster encrypted-only alternatives emerged.

They've got a custom OTP setup which they've revised at least twice already, but as with this Clubhouse thing if you transmit your OTP as plaintext over unencrypted channels obviously a bad guy can intercept that. So basically that SSL box ought to be removed (in favour of always doing TLS) or at the very least default checked.

Well I expect Android since 2018 to force use of https when you create an app. So from my knowledge to make it not tls takes more effort than otherwise. They actively have to 'hack' around this requirement.

more than that as they have to use old tls libs no longer maintained and no longer receive security patches ouch!

This is pretty bizarre. I imagine it's due to user complaints about not being able to make trades while behind very strict corporate firewalls? Weird.

Their site claims it might be faster. Which totally made sense a decade or two ago, and they've been in this game for a very long time (the company itself pre-dates the Web substantially). Is it faster today? Probably not. And if you're trading from a phone app, the chances your execution happening 100ms later ruins your day is very tiny. Whereas if bad guys snoop your WiFi, MitM your login and use your capital to run the other side of a stupid scam (e.g. buying some penny stock with all your investment savings) that's really going to ruin your whole year.

I can most easily imagine they had a proprietary setup in the 1990s, and one day they make a web site because of this exciting new technology. Should it have SSL? Security sounds good, but it is slower. Traders demand an option. Now, fast forward a few years you're building an iPhone app, your prototype looks good, but traders ask, where is that SSL option? Chances are the answer is "Um, TLS is always On? Because switching it Off would be stupid?". Oh dear, are you calling a long time customer "stupid" for not clicking the SSL box all these years? No of course you aren't, you add the SSL box to the app and everybody working on it learns not to point out that this is stupid.

They do at least have almost-mandatory 2FA through SMS or Android app. So it's not quite as insecure as someone reading your email or snooping your WiFi getting the keys to the kingdom.

If you just have something scooping up all unencrypted data (which is something any bored teenager might set up) then you get a password but the OTP codes will be useless shortly afterwards and, if the implementation is competent immediately useless in another session once used.

[ Do I trust that they got that right? Maybe. Others might have a better idea how many off-the-shelf OTP implementations handle this correctly ]

However an active MitM just works. You give the user the illusion they're talking directly to the real system, but you actually keep working copies of their logged in state. When they're done trading, you just carry on. If there's an explicit "Log out" step you can dummy that out.

Forget passwords and OTP, even something modern like Security Keys (WebAuthn) would fall to this - except WebAuthn's APIs magically don't exist unless you have secure context (basically an HTTPS site) so for the web that can't happen. If you used the built-in Android / iOS FIDO implementation† and stupidly did HTTP backend in your app, you'd be screwed.

† In this scenario, you're getting the same features as WebAuthn but backed by your device biometrics, and with a custom per-app identifier instead of a DNS name to stop you stealing the user's Google authentication or whatever.

Same reason Tinder ( Match Group who owns all the apps) sent user location data all over the place.

Normal people will never learn about this , and doing it right would take too much effort. While I would love new better social media to take over, I don't think social media which serves it's users is possible.

Hell, I self sensor more here than I do in real life. In real life if I say something odd it's forgotten within minutes.

Too much effort to use TLS?

EDIT: I didn’t realize initially this is UDP, but I think there is a similar solution like TLS for TCP

DTLS is the general "drop-in" TLS for UDP. It does have limitations and compromises, esp. in regards to real-time media, but this does seem like a situation where it would not be especially difficult to send this data over a DTLS-secured channel which is logically separate from the media.

Even with UDP it's still not hard.

Sure getting it right might be hard, but getting it somehow good enough to not be obviously bad is much less so.

Not only are there thinks like DTLS, in the worst case you could just "ship" a AES key when you login over TCP/TLS and then you encrypt any udp message with that key or something like that. Sure there are many ways you can get it wrong but it's easy to setup and better then plaintext.

And get the certs working ?

Why bother , move fast and break things yo

Technically you don’t need verified certs to get the encryption

So the PRC now has a list of PRC nationals, based on their phone hardware IDs, who discussed "sensitive topics" (phrase used by PRC state media about Clubhouse) on the app? Yikes.

In case you want to host your own Clubhouse or get a feeling for Clubhouse (or Twitter Spaces) without access to an iPhone and/or invite:

"Jam" is an open source implementation of the "audio space" concept that I built over the last few days w/ @DoubleMalt and @mitschabaude

There is still a lot to do but for now you can create rooms and moderate them (stage, audience, mic-flashing, …), powered by WebRTC and should work in any modern browser.

Any feedback, suggestions, thoughts welcome, might do a Show HN in the next days

https://jam.systems

Impressive that this literally only requires one click to get going, and seems to ask for no other requirements (and does browser + mobile equally well from what I can tell). Would be interesting to see how this behaves on large rooms (collections of people). Could also be useful as some sort of 'serverless' or quickly-deployable/click-and-run Clubhouse, perhaps even for certain countries that tend to shut these things down quickly.

We will definitely look into deployment options (& ux) as well as larger rooms which might need audio mixing on the server

I'm also looking forward to run a jam on my raspberry :))

Very impressive, is just peer-to-peer communication or do you have some type of coordination server.

atm based on signalhub (https://github.com/mafintosh/signalhub) and there is also a TURN server

https://gitlab.com/jam-systems/jam

to support rooms with larger audiences we'll probably need to add support for mixing on the server side as well eventually

Show HN:

https://news.ycombinator.com/item?id=26131123

Hmm maybe I'm missing something, but why does this matter? For a long time, on Facebook, you didn't have a "username", you just had your "ID" in the URL. I'm just not sure how it could be exploited.

I'd be more worried about it being hosted in China than user IDs being unencrypted.

It's a metadata leak, not an authentication leak. A mapping of who is talking to who could be built up over time.

As long as proper authorization for resources is in place I don't see the issue either.

I kind of like that Facebook is considering to compete with Clubhouse.

There are a lot of software features that Clubhouse can add, but they have to or choose to focus on many other things instead. Something simple like a "shut up" button "we got your point two minutes ago".

Competition will force them to re-prioritize just to keep the users.

Who could've guessed? It would be interesting to see a "move slow and fix things" approach for once. But I guess it isn't compatible with ruthless expansion.

Clubhouse is a startup, what ruthless expansion? A lot of startups cut corners to get to market faster, but this is just inexcusable.

Haha, this is one of the tamest instances of cutting corners in the news lately. It's not like this is super-secret information either. It's not health, finance, or legal data.

Some people on HN seem to take security much more seriously than necessary, as if security is the most important feature. But in business, it usually isn't.

I, uh, sincerely hope you’re not in charge of any apps I use.

> Some people on HN seem to take security much more seriously than necessary

Necessary to who?

Maybe I'm stupid but how are user IDs and chatroom IDs sensitive information? How can I join a room or interact with a user if I don't know the ID?

Just trying to understand the severity here and if I'm doing something wrong in my apps.

User IDs are sensitive because they can be used by internet service providers to track and identify users as they move through various networks. And they can be associated to figure out who your contacts are. As others have mentioned, the CCP could use this information to punish users for joining rooms they don’t like.

The rule is, if ever in doubt, send all data through https. There is just about no reason to use unencrypted http or tcp in 2021.

Why is your app sending anything over the network unencrypted? You're making HTTP requests (not HTTPS)??

I think it's UDP. Probably for the audio

That may be true of Clubhouse but not necessarily for the person I responded to. Anyway, there's plenty of ways to encrypt UDP, such as DTLS; see this RFC: https://tools.ietf.org/html/rfc6347

and why not ? Why do you insist everything should be encrypted ?

You can tell who is talking with whom.

Snowden exposed mass 'metadata' collection, most didn't seem to care, sadly.

Everything can be sensitive if you don’t get informed consent.

It's amazing that cases like this still come up regardless of all the breaches. The level of carelessness blows my mind.

What language are they using for the backend?

Edit: It's off-topic. Chill out.

This is what I found from their job posting for a backend engineer, ”You have deep expertise in building, deploying, monitoring and scaling systems on AWS. You understand the ins and outs of Python, Postgres, Redis and more.”

I also found out there’s a project management app called Clubhouse, so that’s a little weird.

https://jobs.lever.co/joinclubhouse/939f5935-98cc-49af-8d6e-...

This is not the bug of the year. Ok, the id is not the encrypted. So encrypt it and next. Nothing to see

> This is not the bug of the year. Ok, the id is not the encrypted. So encrypt it and next. Nothing to see

The privacy implications of leaking user identifying information are massive. Not something that should be dismissed so quickly as “nothing to see”.

Maybe not interesting for you, but many of us care about holding companies accountable for bad practices. If you don’t, this will become more common as it’s effectively being tolerated.

There is no evidence that they tried to hide that. The company was created in 2020 and one of their API is not encrypted, that kind of things has probably happened to most of companies created less than a year ago

> that kind of things has probably happened to most of companies created less than a year ago

No company gets a free pass on the implications of sacrificing privacy or security. Even if “less than a year old”.

This is serious:

“Any observer of internet traffic could easily match IDs on shared chatrooms to see who is talking to whom. For mainland Chinese users, this is troubling”

Like somehow you're the judge the jury and the executioner of said conpanies. Don't use their product.

Right. Do the obvious and right thing after you’re caught. No big deal.

A dangerous and all too common pattern of negligence. Willful or otherwise.

Why I can't register for an account even if the app is not available? Why, again, Android users get discriminated against and iPhone users get a leverage again and again?! How hard is to create a signup form and give everybody an equal chance to reserve their username?

why do usernames need to be reserved? everyone on the service has a unique numerical identifier and email addresses are also unique.

do the display name thing and use email as your auth identity. stop doing the same namespace mistake everyone else has made

That's how many services lure people in with "Hurry up and reserve your username." It's like usernames matter anymore as URLs and domains lose their attractiveness, too. The worst mistake, though, is to piss people off and don't let them preserve their identity. For example, many startups use Twitter usernames, and it's pretty much one of the fairest options.

If I was Clubhouse and when I launch a new service one day when I'm not so busy with my day job, I will have a sunrise period where GitHub user will reserve their username. There will be phase 2, when Twitter users will be able to grab theirs, too, and will get the option to use the "@" prefix if somebody with GitHub grabbed theirs or change it. Lastly, there will be Facebook and LinkedIn phases, too. How can one be pissed in such a scenario? Plus, I will be onboard the most influential people first.

yeah I figured it was a hype building tactic.

I do like your ideas though, that's definitely a new one!

Reply on news.ycombinator.com