Tag: client

As a contractor how do I work on multiple client networks without data leakage?

I am a contractor who does development for more than one client. Let’s call them Client A, Client B, and Client X.
I use my own laptop for all 3 clients.
Throughout the day, I have to work on and respond to emails and instant messages about projects for all 3 clients.
In order to work on Client X’s project, I must be connected to their VPN.
Client X performs SSL deep inspection on the traffic on their network. (I get errors from sites/apps that enforce key pinning)

I’m worried that information about Client A and Client B, (not to mention my own sensitive information) might be exposed to Client X. How can I prevent this, but still maintain my ability to communicate with A and B while working on X’s network?

I’ve tried giving each client its own VM on my machine, but the hefty resource requirements of the software I have to use (IDE) makes this prohibitively slow, to say nothing of the licensing difficulties.

Why Signal doesn’t have web client?

I’ve read about E2EE (end to end encryption) of Signal in web clients on a Signal Community discussion forum, and wonder why they say that the browser is insecure for E2EE and native apps are secure.

I think the security issues for clients are the same. It can be harder in various systems based on their security polices, but all of the clients are prone to various attack surfaces like MITM, viruses and rats and other malware. And something more important they emphasise is the delivery for javascript files, but doesn’t that use HTTPS? I guess if anyone could break the HTTPS security they can do anything more dangerous than what we think about.

Actually, we want to develop some chat service like signal with a web client, but this article made us confused. Should we ship a web client or not? Please explain this.

Common Client instead Many of them [closed]

I didn’t find any Appropriate place in stackexchange to ask my question. so sorry if my question is not exactly for this place. I use windows 10 and for gaming I have to use a lot of clients like Steam, origin, Epic ,… . Is any way for centalizing this clients? for eaxmple one common client instead of all of this or some apps to help? working and finding games in many clients are not easy work for me. thanks in advance

Pattern for access controlled client side encryption

How would you design a server/client system where a client is granted a key to encrypt/decrypt data, but the key could be revoked/redistributed by the server? Data encrypted prior must still be readable with the new key.

A simple scenario:

  1. Client wants to send a document to a server
  2. Client encrypts the document with some client-side credentials and sends to server
  3. Server receives document and stores in database
  4. Client requests document, receives, then decrypts. The roundtrip is complete.

Now, suppose the client credentials are compromised and key used to encrypt/decrypt data is stolen. The client changes their password, etc, but the key that can decrypt incoming data is still an issue.

My question is about redistributing an encryption key without having to re-encrypt all of the clients data. Are there any patterns that can help me with this? It feels like a variation of symmetric encryption with a KEK and DEK, but I’m having trouble figuring out how to encrypt something on the client side without exposing the DEK.

Is using Argon2 with a public random on client side a good idea to protect passwords in transit?

Not sure if things belongs in Crypto SE or here but anyway:

I’m building an app and I’m trying to decide whatever is secure to protect user passwords in transit, in addition to TLS we already have.

In server side, we already have bcrypt properly implemented and takes the password as an opaque string, salts and peppers it, and compares/adds to the database.

Even though SSL is deemed secure, I want to stay at the "server never sees plaintext" and "prevent MiTM eavesdropping from sniffing plaintext passwords" side of things. I know this approach doesn’t change anything about authenticating, anyone with whatever hash they sniff can still login, my concern is to protect users’ plaintext passwords before leaving their device.

I think Argon2 is the go-to option here normally but I can’t have a salt with this approach. If I have a random salt at client side that changes every time I hash my plaintext password, because my server just accepts the password as an opaque string, I can’t authenticate. Because of my requirements, I can’t have a deterministic "salt" (not sure if that can even be called a salt in this case) either (e.g. if I used user ID, I don’t have it while registering, I can’t use username or email either because there are places that I don’t have access to them while resetting password etc.) so my only option is using a static key baked into the client. I’m not after security by obscurity by baking a key into the client, I’m just trying to make it harder for an attacker to utilize a hash table for plain text passwords. I think it’s still a better practice than sending the password in plaintext or using no "salt" at all, but I’m not sure.

Bottomline: Compared to sending passwords in plaintext (which is sent over TLS anyway but to mitigate against server seeing plaintext passwords and against MiTM with fake certificates), is that okay to use Argon2 with a public but random value as "salt" to hash passwords, to protect user passwords in transit? Or am I doing something terribly wrong?

SSL Cert for client side web application, is it needed?


Introduction

I have tried to find good answer for it, but I haven’t gotten good article about this topic.

Since there are 2 types of client applications (in bigger picture) – one that runs on server and one that you download and runs in your browser.

My question comes in about the one, that runs in your machine (that you download at first visit – Blazor WebAssembly to be specific).

Questions

Do I need to enable SSL (HTTPS) for this application or web server, that hosts this application as well or is it not needed in the end?

Does only having API connection encrypted be enough?

Background

Yes, this is a cost saving masure, since this is for my hobby project and I would like to keep running costs as minimal as possible. But since I still exchange data, that should not be seen by 3rd party, this application needs to be secure.

To enable HTTPS I would need second Static IP, which is 3$ a month (which is not much), but again, it is additional cost for me, that I would rather not have.