I have written an R package that connects to some services
requiring username and password.
I want to avoid typing my username and password
every time, so I have my package read them from a file
encrypted using AES (I use the digest package in a way similar to the answer to this question: How do I read an encrypted file from disk with R)
The AES key is generated when a user installs the package and it is used to encrypt and decrypt the users credentials.
This way the users only need to insert their credentials once at the moment
of installation and then do not need to write them in any place in the code.
However if somebody gets access to their laptop, it is very easy for him to
decrypt the credentials using the key generated by my package.
Is there any way I can protect the key (possibly in a cross-platform manner,
since the package has to be used in Windows, Linux and Mac)?
The best way to protect encryption keys are Hardware Security Modules like Thales PayShield / nCipher or SafeNet PSO / PSW / Luna, etc... The Key Encryption Keys (KEK) are stored on separate devices and in OS you just keeping cryptograms, keys encrypted under secret key to which you can not get any access (such devices are strongly secured from "intrusion"), The code to use such devices you can write on Java or Python for example, it will make your software OS independent. But it costs some money :)
Related
So I just got my first Computer with MacOS (never used MacOS, idk anything). I am trying to make a password manager which stores all my data (usernames, emails, passwords etc.) so I only need to remember one MasterPassword.
All the Data is AES encrypted with that MasterPassword and the hash of that Password is currently stored in a .txt file. Now I am thinking: What if someone just puts his own hash into that file and just logs into the program ?
How do I store this hash safely?
In general, the number one rule of crypto is "never roll your own crypto". (never write your own system to be secure when somebody else has already written one.) There are a number of reasons for this, but the most obvious is that even if you are very smart, an established package will have had more smart eyes on it to patch any security issues you might have missed.
If you want to safely store your data, use a password manager that is well-established.
If you want to make a password manager as a personal project though, here are some things to consider.
The most secure way to store a hash is to not store it at all. If you're AES encrypting your data, the way to verify that it has been decrypted is that the decrypted plaintext is correct. That way, you don't need to store anything regarding the password at all.
You want to salt your hashes so that common passwords do not lead to common hashes. The SHA-512 sum for password is 9151440965cf9c5e07f81eee6241c042a7b78e9bb2dd4f928a8f6da5e369cdffdd2b70c70663ee30d02115731d35f1ece5aad9b362aaa9850efa99e3d197212a. Here are the google search results for that string. If we instead hash password+EsistDerPascal K we get a string that returns no google search results. See the link for standard hashing techniques.
Use a proper cryptographic hash. While many things still use SHA-512 others have moved to bcrypt or other algorithms. If you're here from the future and Ubuntu isn't using SHA-512, don't use it.
You want your hash (and salt) to be only readable by users who should be able to use it. The easiest thing here is probably using chmod 600 to restrict read/write of the file to your user (or another user, or root).
This is an incomplete list and you should not rely upon any of the above to protect sensitive information.
In light of the upcoming GDPR regulations, the company I work for is looking at upgrading their encryption algorithms and encrypting significantly more data than before. As the one appointed to take care of this, I have replaced our old CAST-128 encryption (I say encryption but it was more like hashing, no salt and resulting in the same ciphertext every time) with AES-256 and written the tools to migrate the data. However, the encryption key is still hardcoded in the application, and extractable within a couple of minutes with a disassembler.
Our product is a desktop application, which most of our clients have installed in-house. Most of them are also hosting their own DBs. Since they have the entirety of the product locally, securing the key seems like a pretty difficult task.
After some research, I've decided to go with the following approach. During the installation, a random 256-bit key will be generated for every customer and used to encrypt their data with AES encryption. The key itself will then be encrypted with DPAPI in user mode, where the only user who can access the data will be a newly created locked down domain service account with limited permissions, who is unable to actually log in to the machine. The encrypted key will the be stored in an ACL-ed part of the registry. The encryption module will then impersonate that user to perform its functions.
The problem is that since the key will be randomly generated at install time, and encrypted immediately, not even we will have it. If customers happen to delete this account, reinstall the server OS, or manage to lose the key in some other manner, the data will be unrecoverable. So after all that exposition, here comes the actual question:
I am thinking of having customers back up the registry where the key is stored and assuming that even after a reinstall or user deletion, as long as the same user account is created with the same password, on the same machine, it will create the same DPAPI secrets and be able to decrypt the key. However, I do not know whether or not that is the case since I'm not sure how these secrets are generated in the first place. Can anyone confirm whether or not this is actually the case? I'm also open to suggestions for a completely different key storage approach if you can think of a better one.
I don't see the link with GDPR but let's say this is just context.
It takes more than the user account, its password and the machine. there is more Entropy added to the ciphering of data with DPAPI.
See : https://msdn.microsoft.com/en-us/library/ms995355.aspx#windataprotection-dpapi_topic02
A small drawback to using the logon password is that all applications
running under the same user can access any protected data that they
know about. Of course, because applications must store their own
protected data, gaining access to the data could be somewhat difficult
for other applications, but certainly not impossible. To counteract
this, DPAPI allows an application to use an additional secret when
protecting data. This additional secret is then required to unprotect
the data. Technically, this "secret" should be called secondary
entropy. It is secondary because, while it doesn't strengthen the key
used to encrypt the data, it does increase the difficulty of one
application, running under the same user, to compromise another
application's encryption key. Applications should be careful about how
they use and store this entropy. If it is simply saved to a file
unprotected, then adversaries could access the entropy and use it to
unprotect an application's data. Additionally, the application can
pass in a data structure that will be used by DPAPI to prompt the
user. This "prompt structure" allows the user to specify an additional
password for this particular data. We discuss this structure further
in the Using DPAPI section.
I am currently in the process of making an online desktop of sorts, and one of the offerings that I will advertise is that the data on your online desktop is encrypted with your password, not our key. So instead of checking the password with a database then decrypting the data with our key, I would like to have each customers data encrypted with their password. The server will then try to decrypt the data with the password. If the decrypting is successful, the data is sent to the client for JavaScript or another language to organize and display. Otherwise, a failed password attempt is sent back. I would also like to completely take myself out of the equation with the passwords by making it impossible for the server to log the password or see the password in any way whatsoever, so your security is in your hands, not ours.
My question is what language would be best suited for that, and the proper methods and functions for doing this. Once I have that information, I will learn that language, and those methods and functions to do this.
I am not too worried about a quick release of hiring a dev as rite now this is a project I challenged myself to, and doing it for fun.
Thanks in advance!
I have some R scripts which rely on ODBC to retrieve data from a server database. Although this is shared within my team only, we wish to hash the database access password nevertheless. Greatly appreciated if fellow users could share best approaches for doing so. Thanks.
What you probably want is PKI: store the password as vector encrypted through PKI.encrypt, with a key shared between team members, and then prompt the user to decrypt it which requires the key only your team has - when the script first runs. R is sort of slim on encryption/decryption packages; you basically have PKI and digest which is asymetric, and that's it.
What are your thoughts about SQL Server's symmetric key functions? Specifically, I have two questions:
Which set of functions is better... EncryptByKey or EncryptByPassPhrase?
Both functions require a passphrase of some kind. In a typical web-application architecture, where should this passphrase be stored? (i.e., hard coded within a stored procedure in the database, or stored as a configuration setting in the web application)
I'm eager to see what the best practice is for these functions.
Encrypting using a passphrase is easier but the advantage of using a key is that the key can be secured using built in SQL sever roles. You can lock down use of the key to only those users that require access to that data.
If you use a certificate then you only need plain text during the initial setup and can store it outside your system. Again, the certificate is a securable object and can be locked down.
Hope this helps.