I've got some data that's going to be sent over a websocket. A lot of different devices are validating the packages contents, like a blockchain, so I can't send the event directly to the receiver of the data. However, I don't want the other people to read the contents of the message.
Is there a secure way to encrypt the data so that only the other person can read it?
The only data the first user has access to is the other person's username.
I was thinking about using RSA encryption using a method something like this, but I don't know how to get the private key to the other person. I would prefer if I didn't have to send a direct message to do this.
Thanks!
All right, so I've been intending to use Telethon to automate several things on telegram with Python, but I'm not sure I understand the gist of it.
First of all, you need an api_id and an api_hash. To do so, you go to my.telegram and go to API development tools. There you are sent a code to your telegram android phone and after submitting, you receive an unique id/hash. First question, is this code you are sent in order to generate an app necessary any more?
Now in python, you can start a client as follows.
from telethon import TelegramClient
api_id=12345
api_hash='abcdef12345ghij'
client=TelegramClient('name of the session',api_id,api_hash)
You can try to connect the client, but it can lead to it not being authorized or the phone not being signed up, so you can use start, which will decide between sign in, or sign up.
Among the parameters you can set in start, there is force_sms (bool, optional) to force telegram to share the code needed to register and log in by sms.
My question here are, if the phone is not signed up, what other means could have telegram used? I mean, they can't send it to the mobile app as that phone doesn't have one.
If a phone not being signed up is a possibility, does this mean the phone with which you got your id/hash is is not necessarily the same with which you create the client?
As this method has a callback, you can input the code sent to your phone and connect to telegram.
Another way to connect a client is using StringSession. I found this piece of code:
from telethon.sync import TelegramClient
from telethon.sessions import StringSession
# Generating a new one
with TelegramClient(StringSession(), api_id, api_hash) as client:
print(client.session.save())
# Converting SQLite (or any) to StringSession
with TelegramClient(name, api_id, api_hash) as client:
print(StringSession.save(client.session))
# Usage
string = '1aaNk8EX-YRfwoRsebUkugFvht6DUPi_Q25UOCzOAqzc...'
with TelegramClient(StringSession(string), api_id, api_hash) as client:
client.loop.run_until_complete(client.send_message('me', 'Hi'))
This bring several questions on its own. According to the docs, this is a way to storing in a string the credentials needed to login, including the authorization key and the phone.
How is this obtaining the authorization key? In the other method, it was sent to your phone for you to input, but here? How can you specify the phone to which you want to connect? Is this a method you can only, or you should only use after the phone has been given access?
In code, is this a possibility?
#Obtain an api_id, api_hash from phone 777777777
from telethon import TelegramClient
from telethon.sessions import StringSession
api_id=12345
api_hash='abcdef12345ghij'
client=TelegramClient('name of the session',api_id,api_hash)
client.start(phone='5555555',force_sms=True,code_callback=True,first_name='John',last_name='Doe')
#Asked to input the code sent to the phone 555555 by sms. Is this code the authentication key?
string = StringSession.save(client.session) #Now I can connect whenever I want using string session.
Two last questions
Can you have more than one session for the same number, even if they don't try to connect at the same time? Like for example, with different api/hash starting the same phone at different times, or as the first session is stored within telegram, creating the second severes the link to telegram of the first?
Can you skip in any way the verification code using for signing up?
Kind regards
is this code you are sent in order to generate an app necessary any more?
Yes, like with many online services offering an API, you register your developer account and get a token (in Telegram's case, api_id and api_hash combination) that can be used to access the API (at all or with less limitations).
It might seem a bit confusing that your application is bound to your user account, however this doesn't mean it can only be used in your account. You, the developer, create an application, and any other user (or even bot) can run your application using your api_id and api_hash.
As an example, when you use Telegram for Android or Telegram Desktop, you are running the application they developed, and are logging in using the api_id and api_hash of the respective developers, not your own.
if the phone is not signed up, what other means could have telegram used?
Telegram may send a SMS to the phone number or perform a phone call. You can use https://tl.telethon.dev to find that send code returns, at the time of writing, a SentCode. This comes with a SentCodeType which currently can indicate: sent via app, call, flash call, or SMS.
does this mean the phone with which you got your id/hash is is not necessarily the same with which you create the client?
As explained above, the api_id and api_hash is for the developer of the application, not the users that will login to your application. When you get started, this person is often the same (you, the developer), but when you publish your application, anyone can sign in without needing to provide their api_id and api_hash. Of course, you would need to keep those secret to try to minimize people from using your key in their applications, although this is not really doable.
How is this obtaining the authorization key?
StringSession embeds the authorization key that was generated to be used for encryption inside the string itself. Next time you use the client, all you need is this key, as Telegram already knows who you are with it, because you signed in before.
How can you specify the phone to which you want to connect?
There is no need. Telegram remembers the account that logged in with a certain authorization key. In official clients, you may see which devices are logged in and terminate their sessions (invalidating their authorization key) to log them out.
Is this a method you can only, or you should only use after the phone has been given access?
You can use StringSession to login, too, and just print it and reuse it later. In this case, the StringSession would begin empty, Telethon would generate an authorization key, you would login, and saving the session would produce something that can be reused.
Can you have more than one session for the same number, even if they don't try to connect at the same time?
Yes, this is what happens when you use, for example, Telegram for Android and Telegram Desktop. Adding a third with Telethon is not different.
Can you skip in any way the verification code using for signing up?
No, because Telegram needs to validate the phone exists and is in use.
We are building an android application and one of its features is to book a cab service provider's cab (say an Uber).
We have an application specific user ID. Let us call it AUID. To book the cab, the application would Post a request to server and send AUID along with other relevant information (like lat, long etc). How do I make sure at the server end that the request is indeed coming from the correct user and it is safe to book the cab? In the current form, if a third party gets to know the AUID of another person, the third party can book a cab on behalf of that person.
One of the solutions I thought of was using asymmetric encryption. The application would hold the public key and the server would contain the private key. Instead of sending the user ID to the server, we'll instead send an encrypted key where the key would be AUID + timestamp encrypted using the public key. We'll then decrypt the message using private key at server end to obtain the AUID. If the timestamp at server does not lie within a certain interval of the timstamp sent by the client, we reject the request.
Is this a safe enough approach? Is there any other practice widely followed for such scenarios?
What you propose is sensible: encrypt the AUID on the client app and verify on the server. As comments suggest, SSL is vital.
The problem is that if how to encrypt the AUID is in your app, it can be figured out by anyone dedicated enough.
You can drastically reduce the risks of fake requests by issuing a separate encryption key for each user. This means that if someone cracks your code, they can still only spoof from one account. However, once an attacker had decompiled your app, they could theoretically start new accounts, get a valid encryption key and spoof requests.
What you need for 100% reliability is some form of authentication which is not stored in the client app - like a password or TouchID on iOS or fingerprint api on Android M. So when a user orders a cab, they need to enter some piece of information which you also encode with the AUID and check on the server. That secret information is not stored in your app, so no-one can fake requests.
Requiring a password from a user is pretty inconvenient. Fingerprint scanning is much easier and probably acceptable. You could also use a trust system - if the user has ordered cabs before and everything was OK, they can order without special authentication. Using Trust together with individual encryption keys is pretty effective because anyone trying to spoof requests would need to do a successful order before being able to spoof - which is probably too much hassle for them.
Our vendor needs some access to our test server, and thus we send them email with username/password (i think it's unencrypted).
What is the most unintrusive way to bump up the security level?
Thanks
Call them on the telephone.
Send the two parts with separate communication channels.
Use a combination of any two of the following.
Voice phone call.
Fax.
Snail Mail.
Encrypted Email.
Separate channels makes it very hard to reconstruct the credentials.
Depending a the level of security you're going for. It's usually inversely proportional to convenience. So here are some in order of least secure.
Zip file with password protection (winzip)
If you're both using Windows send them the information in locknote.exe. It's very easy and the security in the code is very tight. ( http://www.steganos.com/us/products/for-free/locknote/overview/ )
Get their public key and have them SCP to your server to pick up the password file.
Setup encrypted email and either send them your key or setup your public key on a public key server.
These are just some thoughts off the top of my head.
Call them, especially if you already know their voice. A more traditional solution (that requires some setup) is GPG.
Im trying to design a payments API, and it requires the sending of CC info over the wire. So for this I was thinking of using a public key to encrypt the CC info and decrypt it on the server. Keep in mind that the connection is https also. Any suggestions on the topic?
If the connection is https encrypting it a second time won't do any good, except if someone breaks SSL/TLS. In that case trust me your API will be the least of the world's problems..
If the connection is HTTPS, no need to encrypt the CC details.
In contrast to the earlier answers I would strongly suggest you read up on PCI-DSS. Basically you want to keep the card number encrypted until it is absolutely needed in plain text, such as when authorizing or settling. Its not clear what exactly your api calls will do, but at a guess you almost certainly don't want the card number to appear in plain text as soon as it hits your webservice.
In addition if you have a client side component that captures card details, then that will fall under the scrutiny of PA-DSS.