Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
This is a very general question. I am working on a project with my fellow students, and we are trying to create a blockchain-based communication platform.
One of the flaws we found in email security today, is that metadata is not encrypted.
I am finding it difficult to find an explanation of why metadata is not encrypted in the first place?
We separate an email into these two parts:
The payload (or content), which contains the actual text of the messages (or photos, or whatever you may send).
The metadata, which contains the information about the message, but not the message itself.
Consider the metadata as being the information on an envelope. Surely, if you want to deliver a message, you have to write the recipient's address on the front of the envelope. Also, on the back you may want to write your address, so that the postal company (mail server) can return the message when it is not delivered. Furthermore, the postal company knows additional information. For example, they know when the message was sent and when it was delivered. They also know the weight of the envelope.
All in all, the metadata cannot reasonably be encrypted, because 1) it is required for the email to be delivered, or 2) because it is an property of the email itself.
If we encrypt the recipient's address, the postal company would not know where to deliver the message. Encrypting the size of a message doesn't even make sense (although we could try to obfuscate it).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 months ago.
Improve this question
So, I am trying to safely store an authentication token using Angular, processed with additional encryption on top (in front end) and put it in browser local storage (so that not anyone can de-code it).
Many people recommend this method, but I came across several opinions that say even in such case one can access your source code through your browser and get your secret key to decrypt the Auth Token (for example experienced hacker).
Many people claim that Access + Refresh tokens are the best in terms of security.
So, my question is - what are standard practices for serving/ storing authentication token? Is token encryption in local storage good implementation or should we use refresh tokens (although, they are harder to implement)?
I think you should use both a refresh and access token for maximum security...the access token should have an expiration date and should be blacklisted after rotation(when you use the refresh token to get an access token)...if you need even more security,after rotation,the user should get a new refresh and access token
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 months ago.
Improve this question
Currently google single sign-on gives your real email address to everyone. Instead it could give each party a different identifier for you, such that these third parties wouldn't be able to correlate your data.
Moreover spam could be more easily identified and stopped. Google could manage a fleet of "salted" email addresses for each user, tracking which third parties send spam. Signin/gmail synergy.
My question: Does this exist already? Why does this not already exist? Do any other auth vendors do this?
Followup: Why is my email address even used as my primary id? I'd rather keep it private.
Your email is not used as a primary identifier at least not by Google. When a website such as Airbnb does an open ID connect dance with Google, Google replies with a unique identifier to Airbnb. That identifier does not mean anything to Airbnb as to what your email first name last name are. What also happens is that Airbnb can ask Google for your email and that is how they end up having your email.
Note that Apple have a privacy preserving mechanism where instead of returning your real email address they will return an Apple email address that points to your email. That gives you one level of indirection and more privacy.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
So, I'm using a simple, email/password authentication system and I wanted to know if there is a way to encrypt the information that I push there. If not how can I assure the user that their data is encrypted and their privacy is safe? Thanks for the answer!
No, you can't encrypt anything in Firebase Database. Google encrypts everything by itself and you don't need to care about hacker attacks. The only things you need to care about are the security rules and keeping your program, not too server or mobile dependent.
If you do want to assure your users that their information is completely private and only known to them, then you can manually encrypt the information. There are many encryption algorithms, but I would recommend the AES Algorithm, as it is fast and efficient. The encryption key can be stored locally on your device without having to transfer it to the server, ensuring the user's privacy.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We should log post data or not, if not then why?
I did not get proper answer anywhere.
It is best not to log any events containing personally identifying information (PII) or security credentials, as that makes your log storage system a greater privacy and security liability than is strictly necessary.
For this reason, people frequently avoid logging the body of POST requests, as they might contain user's email addresses, passwords, user or internal API keys, etc.
However, you may safely collect such logs if you write application-specific rules to sanitize these log messages of sensitive information.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
due to all this surveillance on the internet I was planning on writing a complete opensource, cross-platform and fully encrypted chat client including video functionality.
Similar to Skype, but messages and video stream should be fully encrypted and all communication must only occurs between the clients itself and never need to go through any server.
The registration, authentication and online checking, however needs to be done server-side to keep it simple and usable also for beginners.
So to keep it as simple as possible I was gonna go for public/private key encryption.
In order not to store the private key anywhere on the server and also not to carry it to each computer you want to log on, I thought about making password as the private key.
This way you could log on where ever you want and do not have to worry about the key.
If you add a person, you will then automatically send him/her your public key. If he/she accepts, he/she will respond with her/his public key and then you can both chat/video-call.
The problem I am seeing here is:
How can I remain the public key when changing my password (the private key)?
Can I use existing SSL Infrastructure to achieve this, without having to re-implement any encryption standard?
I have already a couple of people willing to help programming (C/C++), but unfortunately none of us is pretty keen on the encryption technology, so I will need to sort those things first. Once I know how to implement the encryption I will publish a diagram and ask for feedback about that.
Thanks in advance.
First, I think Jitsi roughly is the app your thinking of building. It does encrypted text chat via OTR , and encrypted voice and video chat via ZRTP for key negotiation and SRTP. In general, cryptographic protocol design is very hard and so if your going to write your own app, you should use these protocols and the libraries that do them.
To answer your question, you cannot directly derive the key from the password if you want it not to change between passwords. Instead, you store the key on a server encrypted(symmetrically) with a key derived from the password( using say PKBDF2 or scrypt). If the user changes the password, they decrypt the key with their old password derived key and reencrypt it with their new one.
In general, though, there isn't much of a point in doing this unless your using some webapp type solution where users might log on anywhere. That is actually a very bad idea. See some the the criticism of cryptocat's javascript bassed implementation e.g. here.