What does it take to make web applications auditable?

Here's why reproducibility matters, and how WEBCAT—a framework for signing and verifying web applications—approaches the problem in practice.

https://securedrop.org/news/webcat-towards-auditable-web-application-runtimes/

#WebCrypto #OpenSource #Cryptography #SecureDrop #WEBCAT

WEBCAT: Towards auditable web application runtimes

In this blog post, we examine the technical requirements for web applications to be properly auditable, arguing that reproducibility is a necessary condition. Enforcing the constraints needed to achieve this on the web is non-trivial, and we present a technical deep dive into how we approach this problem in WEBCAT.

SecureDrop
WebClients/packages/crypto/lib/subtle at main · ProtonMail/WebClients

Monorepo hosting the proton web clients. Contribute to ProtonMail/WebClients development by creating an account on GitHub.

GitHub

Парольная защита статичной HTML-страницы на JS

Обычно парольная защита производится через веб-сервер, который проверяет пароль и выдаёт контент. Стандартный способ: .htaccess и htpasswd . Но что, если нужно выложить зашифрованную веб-страницу и файлы на публичном хостинге, где у нас нет контроля над сервером? Эту проблему решают инструменты StatiCrypt и Portable Secret . Для шифрования HTML перед публикацией StatiCrypt использует AES-256 и WebCrypto, а расшифровка происходит с помощью ввода пароля в браузере на стороне клиента, как показано в демо (пароль test ). StatiCrypt генерирует статическую страницу, которую можно безопасно заливать на любой хостинг, в том числе бесплатный сторонний хостинг, такой как GitHub Pages.

https://habr.com/ru/companies/globalsign/articles/868780/

#StatiCrypt #AES256 #WebCrypto #парольная_защита #PBKDF2 #Portable_Secret #шифрование_файлов

Парольная защита статичной HTML-страницы на JS

Обычно парольная защита производится через веб-сервер, который проверяет пароль и выдаёт контент. Стандартный способ: .htaccess и htpasswd . Но что, если нужно выложить зашифрованную веб-страницу и...

Хабр

id like to share some details about how my app works so you can discover/give me feedback on my app. 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.

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

https://positive-intentions.com/blog/introducing-decentralized-chat

im not an expert on #cyberSecurity. im sure there are many gaps in my knowlege in this domain.

using #javascript, i initially created a fairly basic #chatApp using using #peerjs to create #encrypted #webrtc #connections. this was then easily enhanced by exchanging additional #encryption #keys from #cryptography functions built into browsers (#webcrypto api) to add a redundent layer of encryption. a #diffieHelman key #exchange is done over #webrtc (which can be considered #secure when exchanged over public channels) to create #serverless #p2p #authentication.

- i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have #openedSource my #cryptography module. its basically a thin wrapper around vanilla cryptography functions of a #browser (webcrypto api).

- 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 #githubPages (instructions are provided in the readme). im also working towards having better support for running the index.html directly without a static server.

- 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 received feedback the #Signal/#Simplex protocol is great. completely undertsandable and agree, but wonder if im reducing the #complexity by working with #webrtc. while it has its many flaws, i think risks can be reasonable mitigated if the #cryptography functions are implemented correctly. (all data out is #encrypted and all data in is #decrypted on-the-fly)

- the key detail that makes this approach unique, is because as a #webapp, unlike other solutions, users have a choice of using any #device/#os/#browser. while a webapp can have nuanced #vulnerabilities, i think by #openSourcing and providing instructions for #selfhosting and instructions to #build for various #platforms, it can provide a reasonable level of #security.

i think if i 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 #chatSystem with the "fewest moving parts". i hope you will agree this is true #p2p and i hope i can use this as a step towards true #privacy and #security. #security might be further improved by using a trusted #VPN.

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

(note: this app is an #unstable, #experiment, #proofOfConcept and not ready to replace any other app or service. It's far from finished and provided for #testing and #demo purposes only. This post is to get #feedback on the progress to determine if i'm going in the right direction for a secure chat app)

GitHub - positive-intentions/chat: Decentralized chat

Decentralized chat. Contribute to positive-intentions/chat development by creating an account on GitHub.

GitHub

@kkarhan

thanks for the reply! far from being discouraged, i appriciate your engagement. i will try to be reasonably brief in my reponse to your points and give a general update on progress and objective.

> scout out existing solutions

i have seem similar #webapp implementation, i think so far for "that kind" of chat app, the chat app is able to demonstrate similar basic functionality. for a wider adoption, the user interface needs to be more appealing, but i think its important to have a working proof-of-concept first. the project is specifically aiming to be a #javascript #localFirst #webapp.

a couple notable similar implementation to mine are:
- https://github.com/cryptocat/cryptocat
- https://github.com/jeremyckahn/chitchatter
(im sure there are many more, but i think my approach is yet different and unique to the ones i've come across.)

> DO NOT DIY ENCRYPTION!

this is indeed a reccomended practice i have seen several times. here is a previsous reddit post on the matter: https://www.reddit.com/r/cryptography/comments/1cint8h/what_are_your_thoughts_on_subtlecrypto_vs_wasm ... tldr; the underlying implementation provided by the browser is the best way to go. i have implemented the #encryption using the #webcrypto #api. i aim to not use a library for this.

i generally try to word things in a way that users can provide feedback on features. the app is still in a very early stage, but has a reasonable amount of features. im generally open to requests and questions.

> minimum viable product

what you see as the chat app is also the #minimum #viable #product. i think its sufficiently demonstrates the basic functionality of a chat app. i think the next step is to make the app more stable and user friendly.

those other apps youve mentions ive come across before. what sets my approach apart is that mine it's purely a webapp. with what id like to describe as #p2p #authentication over #webrtc, im able to remove reliance on a backend for #authenticate #data #connections. in some cases, bypass the internet (wifi/hotspot). while there are several ways to #selfhost, in this approach of a #javascript implementation, im able to store large amounts of data in the browser so things like images and #encryptionKeys can be #selfhosted" in the browser. while this form has nuanced limitations, it also has interesting implications to security and privacy.

there are many nice features from the different apps you mentioned and i think i have some unique features too. the bottle neck in this project is that i dont put in enough time to the app.

> feel free to slowly ibtegrate them.

this is basically already my approach to get the app to where it is now.

thanks for the luck, take care and i hope you stay tuned for updates.

GitHub - cryptocat/cryptocat: Secure chat software for your computer.

Secure chat software for your computer. Contribute to cryptocat/cryptocat development by creating an account on GitHub.

GitHub

Going to try #deno2 out for a little util. I want to download my gmail archive, process it with #duckdb and then store it somewhere as #parquet

Lots of interesting stuff in my email, links, lyrics, etc. But its also storing a lot of things I'd rather not be on the internet at all.

Last time I tried out #deno I really liked it but ran into API compat issues with the #webcrypto API so its been a little while since I used it last.

Let's see if the marketing is legit.

#programming #webdev

I am going over some encryption code, namely https://gitlab.com/oncer.io/oncer.io-web/-/blob/main/src/helpers/encryption.ts?ref_type=heads#L18 and I am wondering things:

should pbkdf2Iterations be bumped up from 10000?

should PBKDF2 with SHA-256 for key derivation be replaced with something else?

are there additional precautions that could be taken when running this in a browser? (I'm thinking something like https://engineering.fb.com/2022/03/10/security/code-verify/)

happy to hear feedback!  

#encryption #webcrypto #javascript #security

src/helpers/encryption.ts · main · oncer.io / oncer.io-web · GitLab

Oncer.io - send encrypted messages without history

GitLab
Both web browsers (#DOM) and #NodeJS have a #WebCrypto implementation as a global `crypto` object, but @types/node only knows `import { webcrypto } from 'node:crypto'`, so I wrote a trivial #npm package to have access to that object in the same way in both environments: https://www.npmjs.com/package/@panzi/isomorphic-webcrypto
It's 1 relevant line of #JavaScript (2 more for ECMAScript module and strict mode) and 2 lines of #TypeScript type declarations.
@panzi/isomorphic-webcrypto

Expose the WebCrypto object in browser and NodeJS including types.. Latest version: 1.0.0, last published: 11 minutes ago. Start using @panzi/isomorphic-webcrypto in your project by running `npm i @panzi/isomorphic-webcrypto`. There are no other projects in the npm registry using @panzi/isomorphic-webcrypto.

npm

Gunnar and I have finally figured out why CryptoKit's encryption didn't produce the same result as the WebCryptoAPI.

Turns out the Nonce/IV parameter filled with zeroes was just as important as the timestamp used as authentication data.

#webcrypto #swift #cryptokit