Our iOS app stores messages that users send each other in a PostgreSQL database on our server. Therefore, our users can access their entire message history on any device (iPhone, iPad, iPod Touch) just by logging in.
We'd like to implement end-to-end encryption while still allowing our users to access their message history from any device.
Is this possible?
For example, if Apple's Messages app is end-to-end encrypted, then how is it able to sync across all of my devices?
Of course: you can go two ways (well, at least two ways): let the users register their devices and list all the devices public keys. Then encrypt for all the devices using a single data key and encrypting using the various public keys. Disadvantage: adding a device means re-encrypting for the device.
You could also distribute a single private key encrypted by the password of a user to each device. Now the user has to enter a password to access the private key and the messages encrypted for it.
These are two ways of doing this; there will be more. I don't know how Apple does perform end-to-end encryption though.
Related
I would like to create a messaging app that will be available both on website and mobile ie users can access there messages with their account both on the website and the app.
Now, the issue is that in order to keep the history of the messages I must save them somehow in the database. I do not want to save them in plain text to avoid any data stealing (the app might go in production someday). But, I do not see any way to save the messages encrypted in the database and decrypt them for both the sender and receiver.
What I thought about doing is to create two instances of each message sent in the db. One being encrypted with the sender's public key and the other one being encrypted with the receiver's public key. This way both sender and receiver will be able to decrypt every single message saved in the discussion with their private key.
However, I do not if this is the best way of doing it, what do you think about? Also, I guess the private key will be stored on the user's device but what would happen if the user deletes the app or changes device. Furthemore what about the website? How will it access the private key if it is on the user's mobile device?
Fyi I am using NodeJS, MongoDB, React, React Native and Socket.io
Suppose that I have a device with multiple users. User 1 will start a session with the device, send some telemetry data over a period of time and eventually end their session. Next, User 2 will start a session and also send some telemetry data from the same device. In IoT Central, I am interested in generating telemetry analytics grouped by user, not by device. Is it possible to send a user ID string once at the start of every session to indicate to azure that the following telemetry data is for that user? What is the best way to implement this?
Are you concerned with data isolation from user to use? If so, the best way to accomplish this is to delete and re-create a device instance (i.e. reprovision) the device when it gets moved from user to user; however this won't allow you to track device telemetry trends over time for the same device (i.e. battery life).
If you're not concerned with data isolation, you can send a device property that's unique per user and then be able to slice and dice the data by the device property. This won't be supported within the built-in analytics tool in IoT Central though. You can export the data using continuous data export and do the analysis offline (i.e. in PowerBI).
Despite controversy I like Telegram and it's bots. I would like using a couple of bots as personal assistants. However I'm paranoid with regards to secure network communication and data privacy. The idea of trusting my private data to some possibly mean kid or unsafe data storage is daunting.
So consequently I thought I snap twice, sing bibbidi-bobbidi-boo quickly and then have a self-written Telegram bot ready on a Raspberry Pi hosted in my basement (or possibly hosted in the cloud, when I trust the provider).
But then I'm wondering: Is end-to-end encryption implemented for private chats with Telegram bots? The Telegram clients are open source, however the server is not as far as I'm aware. And in general you never know what's happening behind the scenes on the servers of Telegram Messenger LLP.
I've ran up and the down the whole net twice, but I could only find the official, technical documentation about end-to-end encryption in general. To me it seems private chats with bots are encrypted, but I just want to double-check I am not overseeing something. Thanks.
No, Telegram Bot API's are not end to end encrypted. based on Telegram documentation end to end encryption are for user's chat, without mentioning about bots:
Secret Chats are one-on-one chats wherein messages are encrypted with a key held only by the chat’s participants.
You can implement it manually by adding encryption and decryption in both sides.
Same question asked here.
Some time ago, it was commonplace for smartphone apps to open a browser to a registration page with a CAPTCHA, or to require separate signup via web, because API signup was seen as vulnerable.
Now most apps seem to offer registration via native form, though endpoints for this are usually not documented in their public API. I haven't seen many reports of this being abused to create spam accounts.
How is this done? Is there a standard crypto/handshake process to verify real signups, or does signup typically rely on undocumented endpoints and simple API key passing?
Embedding yields a better experience but has the issue you mention. Yes, the service owners on the other end are still worried about this and combating the problem. And undocumented APIs don't help and the service owners know this.
One of the tools in the toolbox these days is keys assigned to devices which can be used for throttling. This would essentially let you limit the amt of service that can be consumed on a per device basis and it would require you have a device (or can steal the key from one) in order to provide service. So long as the process to issue keys to new devices is strong (a solvable problem) then you can offer a CAPTCHA-free signup experience within the confines of what you are willing to give to a device.
I'd also note that there are other well known approaches you can use, like IP throttling and handshakes with other service providers (like a phone carrier). Depending upon the problem domain these are on the table too...
I am creating a j2me application for mcommerce, which uses mobile internet(gprs). I wanted make it more secured by binding the application to the SIM card and the device. That is a user should be able to login to the system, only using his/her SIM card or from the registered mobile number.
To achieve this I need to fetch the mobile number.
So, on login i thought of Triggering an SMS from the server with a key, which the application reads and uses the key for the entire session. Here the challenge is, that sms should not go to the inbox.
Any suggestions pls?
Yes it can be achieved using the Wireless Messaging API. Have the MIDlet set up a server connection on a chosen port number, then send the SMS to that port number. It will go straight to your app, bypassing the inbox. If you use the Push Registry, you can even make the SMS start your app if it is not running.
It doesn't matter if the user sees the number in his/her inbox.
As long as the key is only used that session, it is her/his responsibility to not share the key with others.
The one thing you make sure is that ONLY the person who owns the SMS phonenumber gets the key and is able to log on.
This doesn't take care of the phone being stolen though.