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.
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 a windows service that downloads and saves oAuth tokens and I need to store them encrypted on the local hard drive until they expire and reuse them later. The problem being a service is that I cannot ask the user for a password. Is there a safe or suggested method to secure files when storing them and prevent other processes decrypting it? My language of choice is python and it would be relatively easy for someone to find out the encryption algorithm.
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.
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 Windows batch file which runs periodically to update data on my MySQL database. I now want to make the batch file secure so that no-one can see the password used to connect to the database. I have thought of two potential solutions:
Encrypt the password in the batch file
Encrypt the entire file.
Id prefer to go with option 1. Is there a quick method to encrypt a password which can be used in a batch file?
Only encrypting the password just moves the problem to how you secure the decryption key.
If you're on NTFS you should secure the whole file instead. On the file properties encryption is accessed by the Advanced... button under Attributes, and access controls are on the Security tab.