I have a small device that contains a client program which communicates with a server over the internet. Pretty standard stuff.
I have a requirement that the server be able to authenticate messages coming from the device, meaning that all communications from the device be from the authentic client and not from some impostor. It's assumed that an attacker can reverse engineer the client and also load his own programs onto the device.
I'm questioning whether this is even possible. I could certainly load a client certificate into the client, but an attacker could get to this and use it himself. The cost of the device must remain low, so no fancy hardware tricks. Any ideas on how I could do this?
Depending on the device, and what kind of abuse you are talking about, you could use a scheme that needs some kind of activation. Like entering a master key into memory only - so its lost if power is lost - a technic used on some crypto cards.
A way to counter stolen devices could involve some kind of lease of keys that needs renewal on a regular basic by specifying a secret.
A way to counter an imitation/copy could be to works with a common state between the client and server that keeps changing. Like negotiating new encryption keys regularly.
We use a similar thing with our apps and web services. We call it ApiValidation where the client in each request to the service adds a header called ApiID which the server can decode to see if the client is authorized or not.
Related
Note: I am working on this as a learning exercise and not for using on an actual website.
I am trying to learn additional ways I could explicitly or statisticly identify a user so I could look at having a sort of "confidence scale" on how securer a users session is. So I could ask the user to re-verify their email if it looks like the password or authtoken has been leaked.
If a client is using a securer https connection then I believe that connection would be encripted in a way that is unique for that connection, and I'm interested in testing and trying to understand better how that information could be gathered and how it could be used.
So, Is there a way to collect the information exchanged during the server clients TLS handshake process on the web server?
I've been testing using Node.js at the moment, but would be happy to try a different langauge or software just to test this out.
Does anyone know if the client details would only be unique for the connection, or if they should be unquie for the browser or device or network interface? (For example if a mobile device goes from wifi to mobile data and the IP address changes Does the HTTPS handshake happen again wit the same or different values?)
And does anyone know if doing something like having multiple certificate for the domain and serving different certificate to differnt users would change the clients default responces on reconnections?
I would assume that the client could probably be identified by loading unique sub domains with unique certificates, and measuring timings to see what certificates in the certificate chain had been cached, and would like to test this, but also not sure if there would be a simpler or easier way?
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
I am building up a small iot-like system, where mqtt devices(clients) are sending and receiving security-related critical information or commands.
I have got to know that TLS connection can be built optionally without client authentication thru PK certificate on the client side.
Normally, mqtt client devices don't have enough resources to support PKI, where at first it has to store a certificate and from time to time, to update it with newly issued ones when validity has passed or when the original certificate has been revoked.
That was, I think, why many of mqtt brokers have an option to configure on/off the client authentication during TLS handshake.
However, my concern is if there would be any security issue from passing the client authentication step, like, for example, a chance that some other malicious devices impersonating one of my devices can connect to the broker could obtain those critical information and commands.
My question is what best options and practices I can take to minimize that kind of risk considering the constraint resource of devices.
Missing client authentication means that everybody including an attacker can claim to be a valid client. There can be use cases like public services where this is not a problem and there are other use cases where the server wants to restrict access to specific known clients only.
There is no definitive answer to this question, it will always depend on the following factors, and only you as the designer can answer them:
What is the threat model you are working with? E.g. Who are you trying to keep out of the system and why, what are the consequences of somebody connecting a rouge client?
How much are you prepared to spend? If you intend to deploy client certificate or even a unique username/password for each device, how will it be protected? Does the hardware you intend to use support a secure enclave/hardware secret store? Meaning how hard would it be for an attacker to extract the client username/password or secret key from the device?
What other security measures do you have in place? Do you have Access Control Lists to protect which topics a client can publish/subscribe to? Do you have monitoring in place to detect malicious actions from clients so they can be disconnected and banned?
On webpage (with https)
Client connects to server with websocket (secure wss over TSL)
Server send 'ready-for-user-and-password'-message
User enters info and Client sends it
Server validates and as long as websocket is connected, knows who the recipient is
EDIT:
I am considering the above instead of using a post method.
It can be safe against some attacks but as usual, there are ways to break into the site and we have to evaluate security holistically
DB passwords
It is not clear from the description but plausible that the setup you've described stores user passwords in plain text.
Best practice in that respect is to calculate password's hash sum with salt and keep that in the database, so if attacker manages to get a db dump, they will need a lot of time to guess a password based on that.
Rate limiting
You should limit unsuccessful login attempts so the attacker won't be able to easily pick a password by bruteforce.
Logging
Another thing which can be problematic here is logging: you need to make sure the credentials don't end up on application log files (I've seen that with credit card numbers).
Similar concern is retaining the sensitive info for too long after verification has ended which makes them more vulnerable (to e.g. forcing a heap dump in Java and picking them from that file)
SSL secret material
If you don't pay enough attention to reducing the access to ssl private key, somebody can play a man-in-the-middle attack.
Depending on the ciphersuites your app server supports, previously recorded communications can be vulnerable to decryption if an attacker steals the key. The concept of resistance to that is called forward secrecy. You can validate if you properly tuned your web app here.
Your cert authority (or any other else) can issue a certificate for your website to somebody else allowing the attacker to misrepresent you (see Mozilla and WoSign, Additional Domain Errors).
CORS
You should also set the Content-Security-Policy so that it will be trickier to force the browser code to send this auth info to other servers.
Social Engineering
Attacker can trick your user into launching some code in the web tools console - you can try opening a web console e.g. on Facebook and see what they've done against that.
New stuff
Vulnerabilities get discovered each day, some of them are published on bulletins, you should follow those for your stack (e.g. OpenSSL) and patch / upgrade where appropriate.
I have gone through RFC 5766 which explains TURN protocol in detail. However, I have some fundamental questions that I am not able to figure after downloading and installing COTURN the opensource TURN server.
What is a client for a TURN server? Is it the first browser that initiates a WebRTC call? TURN servers create an allocation for the client, targeted for a specific peer. Now in WebRTC, we talk about peer to peer communication. In the RFC it talks about client-server-peer communication. All requests/responses between the client and the server are TURN-driven while those between the peer and the TURN server are just UDP data messages relayed to/from the client.
My second question is more specific to COTURN. What is the "value" field in "turn_secret" table and where/when is it used? Does the "credential" property of iceservers correspond to hmackey in the turnusers_lt table by using HMAC over (credentials, realm and username)? Where does the "value" field of "turn_secret" table figure in all this?
tl;dr: TURN secret is used to restrict the leakage of TURN credentials, it is part of TURN authentication using REST api(doc)
from coturn docs:
In WebRTC, the browser obtains the TURN connection information from the web server. This information is a secure information - because it contains the necessary TURN credentials. As these credentials are transmitted over the public networks, we have a potential security problem.
If we have to transmit a valuable information over the public network, then this information has to have a limited lifetime. Then the guy who obtains this information without permission will be able to perform only limited damage.
This is how the idea of time-limited TURN credentials appeared. This security mechanism is based upon the long-term credentials mechanism. The main idea is that the web server provides the credentials to the client, but those credentials can be used only limited time by an application that has to create a TURN server connection.
you can take a look at this answer TURN secret usage example.