I want to implement in-app messaging in my iOS and Android application, and I am unsure about how the backend functionality should be created. From before my backend is running with Node.js and users etc. are stored with MongoDB.
I figure that I quite easily could implement messaging just by saving the messages in the database and sending a push to the recipient with the new message and also showing it in the app, but I do not want the messages to be readable on the server. It would therefore be necessary to encrypt them in the database and decrypt them on the clients.
Do anyone have any suggestions for either how the encryption could be implemented or about node frameworks to use? I have looked at socket.io, but this seem to be created for real time chatting applications, which is not exactly what I'm looking for. I have also looked at RabbitMQ, but I don't really understand if it suits my requirements or not.
Many thanks in advance!
You are talking about end to end encryption. Your encryption would be easy to break if the key for the encryption is hardcoded inside the application. In order to implement something like this, you'll need a library for iOS and a library for Android.
For iOS, I recommend using OpenSSL and implementing a encryption scheme(Public key Cryptography). For Android, you can use the Spongy Castle library.
Due to limitations with iOS push notification size, it is not a great idea to send data via PUSH.
You will also (probably)need to implement a authentication mechanism for users to login.
You can go on two paths here..
Have the server generate a secret for the clients to decrypt
Separate keys, (hashed password on database, and public/privatekeys on client)
I have not used socket.io/rabbitmq, so unfortunately I cannot help you there. It seems like you are new to this, I would take a good look & reading on public key cryptography. http://en.wikipedia.org/wiki/Public-key_cryptography#Examples
Related
I need to store login credentials with electron js because it doesnt save them like all browsers. I have seen a lot of questions like this, but I never found a solution. I have seen in the electron docs about the safeStorage feature. is the it safe enough/good enough to store login credentials on the client side? if not what other tools are available to do that? I have heard about keytar but is it good?
The safeStorage api in electron exposes OS-level encryption/decryption using current user's secret key - please refer to electron source and chromium's os_crypt. On windows it utilizes DPAPI while on *nixes it uses whatever password manager the OS has as the documentation suggested.
is the it safe enough/good enough to store login credentials on the client side?
Depends, you should define "secure" first.
Ask yourself, should the same user allowed to read whatever value inside the encrypted text? A tech-literate person might write his own tools to decrypt things you store using that API you are out of luck. See this QA for further discussion.
if not what other tools are available to do that?
There are a lot of tools (and encryption algorithm) to encrypt stuff in nodejs. However, you have to remember an encryption require you to have a key of some sort and the key need to be protected too. Hence, try your best to avoid egg-chicken problem with your key of keys.
OS-based key storage avoids the key of keys problem by storing the "master key" in a way that only accessible using its API. At runtime, you can't retrieve the key at all, you just send a set of bytes for the OS to magically encrypt/decrypt. While at rest, the OS may rely on secure storage such as TPM (Trusted Platform Module).
is electron's safeStorage for passwords and login credentials?
Depends, if you are running a web service it is preferrable to not doing so. You should never dump end user's user name/password directly on a storage that you can't guarantee its safety by yourself (e.g. your server). You should, put an identifier which can be revoked or may expire at later date - token or cookies.
Imagine the trouble when your end user device get stolen. If it's a token/cookie, they can request you to revoke their access from that device - similar to "Log me out from all other device."
However, if its an in-situ application that authenticates to itself then its a fair game - though keep in mind about the first point. Its all down to your security model.
Im building a chat that uses a api rest full, but i found a problem storage jwt in client side (cookies and his problems), so i opted to use sessions(it's a better option in security terms), that adds state to my app.
I should create a separate server that handles the sessions and also have my rest api?, and apart another server that implements some functionality such as a push server (which I plan to implement). Because I really don't like the idea of having everything on one server, and if so, what should I take into account? (have more than an rest api server and other with his funcionality).
I'm a developer and i think so this require architecture knowledge, and i have no many idea about servers. If you can give me some idea about the topic to get better on it will be great, and what's the better option in this case.
Thanks, give a nice day
Note: This is not a duplicate. Please read the question carefully.
I'm building a chat app with socket.io; however, I have a lot of concerns about the security. Basically, anyone can connect to my namespace and get messages that are sent from the server. After reading many SO posts and looking over the web, I concluded that I need to encrypt the data.
The problem: Encryptions and decryptions need keys. I can store a private key on the server, but since everything client-side is visible to the client, how do I keep some malicious hacker from seeing the key on the client side?
I’ve looked at socket.io-encrypt, but that just confuses me even more, because it seems like the client side is also written in Node.js. The other answers on SO I either can't understand why it helps or they don't solve my problem
Background:
My company has a REST-api developed in Play Framework 2.2 and we use Play's built in authentication using signed cookies as security. Our application is split up into multiple instances of Play all sharing the same application.secret. This enables us to read the session cookie on all instances of Play very easy.
Problem:
Right now we're in the process of migrating some parts of the REST-api to Node.js and would like to use the same session cookie there (with same application.secret) to detect if a user is logged in or not. I've searched the internet and I haven't found anything on the topic.
Question:
So, is it possible to do it? Is it considered secure enough or do I need to migrate to another method of authentication?
The cookie is encoded in CookieBaker:
https://github.com/playframework/playframework/blob/master/framework/src/play/src/main/scala/play/api/mvc/Http.scala#L430
with an HMAC-SHA1 signature using Crypto.sign:
https://github.com/playframework/playframework/blob/master/framework/src/play/src/main/scala/play/api/libs/Crypto.scala#L98
You have the application secret and presumably Node.js has the same signature algorithm, so you should be good to go.
I have question about credential caching in applications. I've searched around on the net for solutions to this problem, but I haven't found anything (which is really surprising, since this is something that every Facebook, Twitter, and email client application has to deal with).
My question is this:
Let's say I'm building some simple Twitter client. I don't want to force the user to enter their password every time. How do most applications tackle this problem? At some point, the client needs to make an API call to authenticate (which includes the password, which is usually in plain text). However, saving the password in plain text somewhere not the correct solution, obviously. So, how do most apps do this safely? I suppose you could cache the password in a file or db if the password is encrypted, but then how do you safely store the decryption key? Or is it generated at runtime using unique information from the client machine as a seed?
Are there any resources (articles, books, etc.) that talk about this? How do most apps handle this?
Thanks!
Single-sign-on (SSO) setups accomplish what you describe typically by providing centralized methods to generate, distribute and validate a key using some type of session ID.
See for one method (used by StackExchange/StackOverflow):
http://openid.org/
Here's something I didn't know: This category of functionality is known as Federated Identity. For instance, our web system where I work offers (but doesn't require) Shibboleth. See here for a list of options:
http://en.wikipedia.org/wiki/Category:Federated_identity