Live data from Hacker News

Matrix.org hacked

web.archive.org

271–277 of 277 posts

Re: Matrix.org hacked

#271
post #266

Earlier quoted context omitted.

Maybe I'm not clear -- destroying any user's data without user's explicit authorization is unacceptable for any non-joke of a system. If users' keys are linked to the session key then the system has to be designed in a way that the centralized session key store is protected like a pot of gold. That's a design constraint and dictates operational constraints. > Matrix doesn't store messages locally long-term and all yo…

If Riot kept around your session keys even if you were logged out I guarantee that a similar complaint would be made about it being insecure since it leaks keys. I would also like to point out that e2e is still not enabled by default because of issues like this. If you enable it you should know to enable key backups. Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't…

> Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't have had a problem (yes it should've existed earlier but there are a lot of things for the underfunded Matrix team to deal with). And the reason it's not default is because making such a system opt-out would also make people start screaming about how Matrix is insecure because "it stores your keys on the server".

Encrypt the bloody backup keys with a key derived from a passphrase selected by a user.

> I think in many respects, the people working on Matrix are going to get criticised like this no matter what they do. I note you haven't actually suggested a specific proposal for how to fix this -- you're just going on about design cinstraints and how Matrix is therefore a joke system. To me that seems to be more snark than useful advice.

The snark would be to say "Use Matrix. Who cares about the system not being built to deal with the design constraints"

No one should defend Matrix after this. It was not a mess up. It was an Equifax level fuckup that was totally preventable.

Re: Matrix.org hacked

#272
post #266

Earlier quoted context omitted.

If Riot kept around your session keys even if you were logged out I guarantee that a similar complaint would be made about it being insecure since it leaks keys. I would also like to point out that e2e is still not enabled by default because of issues like this. If you enable it you should know to enable key backups. Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't…

> Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't have had a problem (yes it should've existed earlier but there are a lot of things for the underfunded Matrix team to deal with). And the reason it's not default is because making such a system opt-out would also make people start screaming about how Matrix is insecure because "it stores your keys on the server". E…

Yes - on their operational security.

Not the implementation of the encryption code.

Which we'll continue to use from people like www.modular.im, and whoever else springs up. As well as self-hosted servers.

Don't trust them? Host it yourself, and it's easier every day.

That's what drew me to the platform, and what will keep those serious about security, and decentralization/federation.

Re: Matrix.org hacked

#273
post #268
post #265

Earlier quoted context omitted.

>they want to eventually disable or turn off matrix.org. What happens to everyone on matrix.org?

Disabling registrations of new accounts, not deleting old user accounts. However something that they are working on (which is a fairly complicated project) is making accounts migrateable between homeservers. Then, users would be able to seamlessly migrate their accounts off Matrix.org.

That sounds great!

Re: Matrix.org hacked

#274
post #266

Earlier quoted context omitted.

If Riot kept around your session keys even if you were logged out I guarantee that a similar complaint would be made about it being insecure since it leaks keys. I would also like to point out that e2e is still not enabled by default because of issues like this. If you enable it you should know to enable key backups. Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't…

> Riot has supported automatic key backups for the past few months, and if you'd used that you wouldn't have had a problem (yes it should've existed earlier but there are a lot of things for the underfunded Matrix team to deal with). And the reason it's not default is because making such a system opt-out would also make people start screaming about how Matrix is insecure because "it stores your keys on the server". E…

> Encrypt the bloody backup keys with a key derived from a passphrase selected by a user.

Actually the system they have is better than that. You generate a random Curve25519 private key and the public part is stored. This allows your client to upload backups of session keys without needing to constantly ask the user for their recovery password.

You can then set a password which will be used to encrypt the private key and upload it to the homeserver (but you can just save the private key yourself).

So, not only do they have a system like you proposed, it's better than your proposal.

> It was an Equifax level fuckup that was totally preventable.

I agree with you that their opsec was awful on several levels, but you're not arguing about that -- you're arguing that their protocol doesnt fit their design constraints (by which you mean that they clear keys on forced logout without prompting to enable backups if you don't have them enabled yet -- as I mentioned there is an open bug about that but that's basically a UI bug).

All of that said, it's ridiculous that they don't have all their internal services on an internal network which you need a VPN to access.

Re: Matrix.org hacked

#275
post #203

Earlier quoted context omitted.

Unless I'm missing the joke, this is a bug bounty with extra steps.

My idea was to not require any explanations, so that blackhat could grab that wallet too. It's just about being able to say "this server is $1k secure". I think it's fantastic that we have a technology to do that. You still need some trust that private keys to given wallet are on the server, but apart from that, when you know there's $10,000 dollars on the server for anybody who can access it, it says something about…

How would a blackhat grab the wallet if it's GPG encrypted and needs the passphrase from the dev?

Re: Matrix.org hacked

#276
post #248
post #56

Earlier quoted context omitted.

I have been asked twice or more why I insisted on not using a Continuous Integration environment for publishing some software releases that are installed by third-parties. My team was automating the infrastructure to build internal software and naturally they wanted to be able to simplify things. The idea that was proposed to me was the following: once I push a new version tag to GitHub, the deployment CI server is g…

Unless you audit the entire codebase prior to a manual build, from a machine you know hasnt been compromised with a key you know hasnt leaked, how is a manual build different to CI/CD securitywise?

Auditing the entire database is hard and is not part of my concerns why I rather not to use a CI/CD in my specific case.

This is what I gain by not using the CI/CD the rest of my team uses:

* isolation: I build applications to be delivered to personal computers of software engineers (mostly), they build applications to run on our own internal servers. * my SSH client requires I have my SSH key with me, while I believe I can achieve something similar with a web-based CI/CD, the client-side certificate isn't something as "production ready" out of the box as 24 years old SSH is. * if someone manages to push malicious code to my code base, I am going to notice during manual check: yes, I manually check the diff commits to see if anything weird came up (mostly thinking about bugs). In practice, I basically check if the commit hash is the same as the one I just pushed (usually containing the release notes). If it is, I build. Otherwise, I check what is going on (most likely, I forgot to checkout the tag).

You can say that this doesn't rule out my machine from being compromised, and I must agree... However, besides being very unlikely that I am a target of such a complex attack, I try to do my best to have a secure development environment.

If I were a high profile target, I would just use a spare safe machine to use in deployments (I believe Linus Torvalds use something like this to vet the security of the Linux kernel but I couldn't find the reference).

Re: Matrix.org hacked

#277
post #216

Earlier quoted context omitted.

Ehh... not really. I still can't find a good combination of server, desktop client and iOS client that support things like OMEMO, history sharing between clients, and voice/video chat. And the one iOS client (ChatSecure) looks really dodgy and regularly fails while setting up push notifications.

And instead of adding those features to existing clients, let's create a brand new protocol, server, desktop client and mobile client. Because why not?

maybe because, among many other reasons, it takes so much f time for something to change in the XMPP world, because you have to wait for the XSF to validate any change, then all the server devs to implement it, then all the client devs to implement it, then all the sysadmin to update their (very often very old version of) XMPP server, then for the users to update their clients (which, with Android fragmentation for example, is a PITA) ?
Post reply on HN