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.
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 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 1 year ago.
Improve this question
How can I enforce new password rules (e.g. '12 chars minimum') on the backend, when the client sends up a one-way hash? If I used two-way encryption, the client would need the passcode, which seems to defeat the purpose. I'm using a salted hash in case someone intercepts the message, but couldn't they also intercept a passcode? This seems like a catch-22.
...but I can't think of anything better. I send down a one-time passcode (which I suppose is fairly safe over SSL), then decrypt the password on the backend and run my checks.
How do the experts handle this? Thanks in advance.
TLS is secure if you are using the up2date default policies.
It's not an issue to send over your passwords in clear text and hash them on the server. That's actually what most applications do, even big websites.
You can't enforce password rules on the backend when using a secure hashing algorithm such as argon2 already on the frontend.
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.
I'm working on a project with some sensitive data. I'm trying to do statistics about Facebook conversation with a client only website. Until now, I have a big JSON file of a Facebook conversation that I parse and do stuff with data. I want to be able to deliver this file only to my friends. So, what I thought is that I locally encrypt it (with I don't know yet which algo), deliver the encrypted file and give the password to my friend so only them can decrypt it. Do you think it will work and it will be secure enought ? I don't want someone to be able to bruteforce it or whatever, as it is private conversation. And do you have any recommendation about the algo I should use ?
You placed an abstract question so you may get only an abstract answer
deliver the encrypted file and give the password to my friend so only them can decrypt it. Do you think it will work and it will be secure enought ?
There are a few conditions to make encryption safe.
using any modern cipher which is not considered weak (e.g. AES-128 provides enough of security)
the encryption key is random (or password used to generate the key is long and random enough)
optionally you may add an authentication tag to ensure message integrity
And do you have any recommendation about the algo I should use ?
To encrypt data itself, any current modern cipher will do, e. g. aes, 3des,...
If you don't want to dive into security and you just want to encrypt a file, you can you some out of box tools which would do that for you. Try to look at openssl, pgp, gpg or nppcrypt (plugin for notepad++). Just make the password long and random.
The question is how do you get the key or password to your friend safely. You can either use different channel or using asynchronous (such as RSA or ECC). You can search, read, try out and ask more specific question
I am trying to design a pairing application for my university this valentine. How is it supposed to work, you ask?? The clients will submit preferences to the server and after some days if any two clients have the same preferences, they will be notified -- not in any other case. A fool-proof framework design needs to be built for this purpose. What I am willing to do is to ensure my clients that even though they will be submitting their favourite responses to me via my website, I will still not be able to see those as if I would, this application will have issues of privacy. I am trying to match the user preferences with each other, they will obviously be encrypted and there is no way I can match any two unless I decrypt them at some point in my server locally -- assuming the fact that RSA encryption mechanism has a very little probability of collision of hashed values and I definitely cannot match them :) . The bottleneck here then is >> never ever decrypt the client preferences locally on the admin's machine/server. One approach which is currently on my mind is to introduce a salt while encrypting which will stay safe in the hands of the client, but still decryption needs to be done at some point in time to match these hashes. Can there be some alternative approach for this type of design, I think I might be missing something.
Turn things around. Design a mailbox-like system and use pseudonyms. Instead of getting an email once a match has been found, make people request it. That way you can leave the preferences unencrypted. Just the actual user has to be hidden from public. Start with an initial population of fake users to hide your early adaptors and you will be done.
I.e.: In order to post preferences, I'll leave a public key to contact me. The server searches matches and posts encrypted messages to a public site. Everyone can see these messages (or not, if you design properly) but I am the only one that can read them.