I want to build an app where users upload files. But the owners of the server should never be able to have access to any data from the files, only encrypted content.
If I had to implement it myself using Java, I would do something like:
symmetric encryption for the files using a random key per file (or per user because I don't need per file access control). The random key is then asymmetrically encrypted (one time for each user needing access to the file) and stored along the file on the server
Users have a password encrypting their randomly generated on account creation private key stored on the server along with the public key.
The user password hash (not the password itself) is also used as an authentication password to avoid having multiple passwords but also to avoid sending the user password to the server (the server then normally computes and compares the salted hash of this hash of the password)
How can I implement a custom app like this (using libraries?, running additional servers with http APIs?, something else?) ?
I found https://www.minio.io/features.html, an http server with s3 compatible rest APIs which has "Both server side and client side encryption are supported" but couldn't find enough documentation on the client side encryption.
Related
I have an issue when it comes to encrypting user passwords. I have a authorization services with which one can create a user account. Given is an email and a password. As for now I encrypt the user password in the server before persisting it in the database.
However I feel that is somewhat wrong because the password is in plaintext when coming in through a https request. So I actually could log the real passwords of users.
Isn't that a dangerous way to handle user passwords? I think it would be better to encrypt user passwords in the client side code (javascript) before submitting a form (either registration or login). So the password will arrive encrypted already.
Am I right with my concerns?
I encrypt the user password in the server before persisting it in the database.
Please don't. Use slow salted hash if possible (BCrypt, SCrypt, Argon2,..)
If you really cannot use the mentioned functions, than a database native hashing functionality is better than encryption.
https://practice-code.github.io/architecture/how-to-store-passwords-in-a-secure-way/
the password is in plaintext when coming in through a https request
Nope, the https encrypts traffic between the client (browser) and the server.
Yes you can see the password in the browser side before encryption (but the user entered the password, so it looks ok to access its own data) and the server needs to validate the password anyway.
Isn't that a dangerous way to handle user passwords?
Indeed. So maybe it's a good idea to offload the user authentication to already proven services (AWS Cognito, IBM AppID, Azure AD,..) or to social accounts (Google, FB,..)
I think it would be better to encrypt user passwords in the client side code
As already commented, that is not helping at all. Then the encrypted value becomes the password
Nothing is in clear text when using HTTPS, data is encrypted that is the main point of using server certificate !
As an alternative approach usually one stores the password hash in db instead of the password text, so eventually your code uses hash algorithm to generate the password hash and compare it versus one stored in DB, by that even if someone was able to access the database records ,that one is unable to figure out what is the password because all he gets is the hash value
Using Hash in C#
I am developing an application that'll decrypt encrypted files when a user successfully logs in. From what I understand, OpenSSL does not have a built-in function for this. So what I plan to do is zip up a folder and encrypt the zip file when I want to encrypt the directory and the reverse when I want to decrypt it. I will use the aes-256-cbc algorithm. The problem is, a user could change their password in my application, so the new password will generate different key and IV pair meaning that I can't decrypt the folder. Does anyone have any suggestions? Login credentials are verified on the server and encrypted zip files are located on the computer running the client application.
The problem is, a user could change their password in my application, so the new password will generate different key and IV pair meaning that I can't decrypt the folder.
The practice is not to use the user credentials to encrypt the data. If the user forgets his credentials, the user is done for.
Login credentials are verified on the server and encrypted zip files are located on the computer
That's actually giving you an option. If you don't want to store the encryption key on the client side, the server could send the key back as a part of the response and the client application could use it to decrypt or encrypt the data.
I'm implementing 2FA on my app with phone number verification. As SMS are not free, I really need to ensure that a request to my server comes from my app and not from any third party http request launcher.
For this purpose, I thought about encrypting the http request with a key provided by my server within my app, and send that encrypted request. As my app is a binary (this is not applicable for web of course), I was thinking it would be difficult to see the encrypting method. The process would be the following :
my app asks my server a key
my server generates, stores and returns a random key
app encrypt the whole actual request with a "secret" method, depending on that key (secret = in binary so hardly readable)
app send to server the encrypted request + the key
The server sees if the key exists, and tries to decrypt the request. If it manages to decrypt, it proceed the request, and then remove the key from its storage so no one can use it anymore.
I don't see any to compromise this system, except if someone manage to read from apple/android binary app the encrypting system the app uses.
Do you think this can be a good process ? Do you see any way to compromise this system ? Is reading from a binary file is really difficult ?
I will start with the flaws in your design, from an android perspective, even if you have enabled pro-guard for your app, we can still decompile the app and trace back the api calls
If your server is not using HTTPS - its easy to trace the calls going
back to the backend server by routing through a proxy server like
charles proxy, and analysing the response, even if you are using
https its possible to install ssl certificates to trust the proxy and
get the response. Also by analyzing the outbound requests its
possible to extract the signed key from the app
Its easy to decompile an apk package and opening it in IDEs and
searching for the backend server url by inputting 'api' or
'http','https' keywords on the ide project search window
If you are storing the secrets in shared preferences or storage, it
can be read from the device ,if the attacker has root access to file
system.
then remove the key from its storage so no one can use it anymore.
For the above scenario, i will run the app and once it stores the key , i can change the permission to read only , so even if the app tries to remove it , it wont be deleted
You can use SSL-Pinning, and putting the keys in compiled libraries making it difficult for the attacker to decrypt the key, also you need to make sure that you don't create any other loop holes
You may also share the common key between app and server through alternate channel , like an email . Where the user once he registers for the App gets and Email with a QR code which once scanned will give the server key. The security of this approach is tied to the secure access of the email by authorized user.
You may them follow the standard approach of sending the encrypted request to server to verify the phone number , once done you may delete the data form your app storage.
If I want to encrypt data on a server, and send it to a client program which I have implemented and sent to the customer, is there anyway that I can store the decryption key and algorithm in the client program, without risking that reverse engineering my client program will enable the user to decrypt all the data I send.
That is, I want my client program to control what it decrypts and what not.
Thanks
Jeeji
You can hard-code the algorithm with no risk. The security must be based in the secrecy of the key, not of the algorithm.
To secretly store the decryption key, you can use a keystore.
I don't know which language you are using, but Java includes its own keystore, and for C you get a keystore through NSS. To open these keystores you will need a password that the user can type in when the client application starts up.
If your client runs on linux and gnome, then you could also use Gnome's keyring, in which case the user will not need to type the password to open the keyring (the log-in password is also used to open the keyring).
I have a project to generate PDFs on a server using ASP.NET (C #). But now we need the customer to be able to digitally sign these PDF. From what I saw, the documents must be signed at the client side, using an applet, as in the server I have no access to the private key of the certificate, but as I said above, the PDFs are generated on the server and I keep them there.
So, what I need is to digitally sign PDFs on the server, taking the client's certificate.
Thanks
Since it is not possible or anyway safe to extract and send the client's private key, to sign pdfs on the server you need to establish a "session" with the client and let them calculate the signature.
The steps should be something like:
the client sends his public certificate to be embedded in the signed pdf
the server generates the pdf, embeds the certificate and calculates the hash (eg: sha1)
the server sends the hash to the client applet
the applet calculates the digital signature with her private key
the applet sends the signature to the server
the server embeds the digital signature and closes the pdf.
To do this with itext you will have to use the preclose method after ambedding the certificate, so to be able to alculate the sha1 hash on the final document.
Then after pre-closing the pdf you will have to calculate the hash of the pdf and send it to the client.
Be careful: while preclosed you will have to keep the document in memory, for example in a server session.
To generate the pdf, embed certificates and prepaare the document you can use itextsharp, the c# port of the itext library. To calculate the hash and create the pkcs7 envelopes you can use the .net crypto api.
Hope this helps.
You might be missing the point of digitally signing a document. The act of signing a document is meant to be a user activity.
You can create the document on the server side and serve it with the content-type "application/pdf" and that will serve the document to be signed. When they sign it you can use pdf form submit to submit the signed document back to the server.
AspPdf + USB Network Gate or AnywhereUSB might help if the client uses USB smard card on their machine.
you can also use a signing service like (I'm sorry, I just know this one as working) http://www.signagate.de - these guys offer an Web service that enables you to 'upload' an unsigned pdf which will be sent back with an so called 'intermediate' signature that is conforming to even all signature laws in the EU as a qualified signature (at least for invoices as I know).
The fun is, you just need to be able to do a post call to their service to get the pdf singed back as answer.
So the 'intermediate' thing allows you (from a legal view) to NOT promote the private key etc. around the world but getting a valid signature on your PDF and keeping so the legal needs by a proper authentication to the signature service of this company.
Jimmy