this post was submitted on 26 Jul 2024
7 points (68.4% liked)

Cybersecurity

5689 readers
194 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Community Rules

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !cybersecurity@lemmy.capebreton.social !securitynews@infosec.pub !netsec@links.hackliberty.org !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub

Notable mention to !cybersecuritymemes@lemmy.world

founded 1 year ago
MODERATORS
 

https://github.com/positive-intentions/chat

probably not... but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify... but i want to understand why?

im not a cyber security expert. im sure there are many gaps in my knowlege of this domain.

using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman (which can be considered secure when exchanged over public channels)

  • i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.

  • another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages and instructions are provided. im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.

  • to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.

i think if stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the frontend and the peerjs-server to be hosted independently, im on track for creating a chat system with the "fewest moving parts". im hoping this will lead to true p2p and i hope i can use this as a step towards true privacy and security.

i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work.

i created a decentralized todo list demo using the p2p framework used in the chat app. this is to demonstrate the bare-minimum functionality of decentralised messaging and state management.

while there are several similar apps out there like mine. i think mine is distinctly a different approach so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.

you are viewing a single comment's thread
view the rest of the comments
[–] positive_intentions@lemmy.ml 1 points 3 months ago

thanks for the info.

threat agents

in a p2p system the key components seem to be things like the network, peer, device, os, browser. all those things can be compromised either on yourside or on the peer's side. its critically important for security that these components are secured to a reasonable degree. threat agents could mean things like device manufacturer, ISP or even someone looking over your shoulder taking notes. not sure how exhaustively to describe threat agents here but these are the components that make up the system and have understandable nuances to thier vulnerabilities.

HTTPS and an honest server

this is true but it critically depends on your definition of these. there are many decentralised chat apps out there like matrix. unlike matrix, a selfhosted solution on my app is something that is easier to setup that others because its basically a website on a url. this might lead to less technical people using my app with ease. these are the users that may not be able to distinguish on these security relevent information.

verify that the JavaScript they’re executing is the correct JavaScript

the app is a offline-first PWA. its practically works offline. im sure its possible to make it so that fetching new statics can be done explicitly. the app otherwise is already able to do things like startup while offline from the cache (sometime it takes a couple refreshes (a bug for another time)). i prefer for it to take the latest javascript because especially at this early stage, it something im actively working on and fixing. i can imagine if the project isnt abandoned, it would make sense to have certain security assessed version to use.

compel you to serve malicious JavaScript to specific users

i think there isnt a way to implement something like this in this app. firstly im taking a hard stance on external javascript. that isnt to say my due-diligence is perfect... thats to be indentified from it being open source. the app doesnt have anything like tra traditional registration system. data is stored locally in browser storage and user ID's are cryptographically random. if there is concern about seving a different script to certain regions by IP, here is a prev post on the matter. ultimately users have to be responsible with how they use the app. "do not connect to people you dont trust" is the general advice.