How can I securely store the p12 file?
As per my knowledge the in p12 file certs are encrypted with RC 40 bits and keys are encrypted with des3 but brute force is the technique which can reveal the password of certs and then same can be used to get the keys and this makes the p12 file bit insecure.
I want my p12 file to be securely stored in the file system.
Can I encrypt this file and store it.If yes, then will the file still be usable.
PKCS#12 by definition does not define what algorithms are legal to use. PKCS#12 is just a structure of a container for certificates and private keys. That container can be encrypted and signed. See more here: https://www.rfc-editor.org/rfc/rfc7292
Theoretically any encryption could be brute forced. The question is what is the cost and effort to do that successfully. By picking up a trusted algorithms (see the list of NIST approved algorithms for example) you can sleep your night rather well knowing that your private key inside of an encrypted PKCS#12 container would remain safe against brute force.
If your PKCS#12 file uses 3DES encryption it could still be considered safe. See more here: https://security.stackexchange.com/questions/146710/is-the-3des-algorithm-secure
But if you want to restrict access to the PKCS#12 file and the private key inside of it, cheap option would be restricting permissions of the file in the file system. This basically means that only the user running the process have access to that file. More pricier options would be to use hardware tokens and HSMs. Some vendors are SafeNet and Thales for example and you can use those through crypto engines and interfaces such as PKCS#11. The PKCS#12 file could also be protected by a passphrase, which is often recommended if you can tolerate human interactions. In server environments or other use cases where human interaction is not possible, passphrase protected PKCS#12 may be tricky since you need to find a way to protect the passphrase itself.
Related
I'm after some concrete advice on how best to prevent (or at least deter) unauthorised software upgrades on an embedded system. It doesn't need to be bullet-proof and we can assume for now that the system itself is sufficiently locked down so that no-one can get unauthorised access to it.
My plan is to basically have an installer process running on the system which would receive update packages from anywhere but that could ensure those packages came from a trusted source (i.e., me) before attempting to install them.
In simple form, the update package would have the actual installation package, plus a matching digital signature that could only be generated by myself. Moreover, the signatures would be purely self-generated with no external authorities involved.
So these are my thoughts on the possible process:
Generate a private/public key pair and distribute the public key along with the embedded system itself.
When creating a software install package, pipe the contents of the package (or an MD5 of the package) through a signature generator using our private key.
Distribute the software install package along with that signature.
Have the installer check the signature against the software install package (using the public key it already has) and only install if there's a match.
If anyone can find any problems with this scheme, I'd appreciate the details, along with any specific advice on how to avoid them. In addition (though this is not the primary purpose of the question), any advice on tools to generate the keys would be appreciated.
I do not see any apparent problems with your solution. I can suggest improvements that you may have already taken into account
If the embedded software is sufficiently locked, it is not necessary to take additional measures to protect the integrity of the public key distributed with the software (e.g. by signing the installer itself and obfuscate, that could be a headache)
I've considered a TLS connection to download the updates, but it would not really needed, because packages are going to be protected with a digital signature
I suggest encapsulating the public key in an X509 certificate. This way you can control the period of validity and even a possible revocation if the private key has been compromised. In this case you will need a hierarchical Certificate Authority, with a root certificate that issues the signing certificates. Include in the truststore of the installer the public part of the root certificate. Then using a different signing certificate after expiration/revocation will be transparent to installer.
The root certificate has a long duration and a large key size (and should be conveniently secured), and the signing certificates have a shorter duration and can use a smaller key.
With this CA you could also generate a TLS certificate if you need some additional service: e.g check available updates. In this case include the certificate in the truststore of the installer to avoid man-in-the-middle attacks (SSL-pinning).
You can sign the full distribution or a hash. It does not affect security (see https://crypto.stackexchange.com/questions/6335/is-signing-a-hash-instead-of-the-full-data-considered-secure) but do not use MD5 because has extensive vulnerabilities. Use a SHA-2 function.
To generate the keys you can use openssl in command line or use the GUI application KeyStore-Explorer
This question has probably been asked but I don't quite understand why people suggest to not store the keystore generated using java keytool in version control. As long as the keystore as well as the keys are password protected, is there harm in storing keystore in version control?
Would encrypting the keystore along with other settings like database password, mail server passwords etc with a single key and storing these in the version control (except for the decryption key) be useful even if some is able to guess the password for keystore and keys in there?
Similar question but not clear /accepted answer:
https://superuser.com/questions/749949/should-i-add-keystore-files-to-version-control
Passwords and other credentials are configuration aspects of the application, that are by nature environment dependent, whenever source control is meant to keep code and artifacts that are environment independent.
The-Twelve-Factor application has a good principle defined for that:
http://12factor.net/config
This is only one reason not to store credentials in the source control. The re multiple other aspects are not less important.
Why do sites provide MD5 checksums on file downloads? For example, XAMPP at https://www.apachefriends.org/download.html.
My understanding is that it is to show authenticity and credibility, but if that were the case couldn't the site calculate and provide a checksum of whatever file (malicious or not) that they are delivering to you?
It's true that if the site that is hosting the file is compromised, these hashes would provide little value - but it is common for there to be a third-party host (to save bandwidth, or provide backup sources). So, if I provide a hash for the file on my site, but I use a third-party host, you could double-check the value to ensure that the file is not being modified by the file host.
In your case, the installer is actually being provided by sourceforge.net (at least when I tried it), which, ironically, has been getting a lot of flack recently for modifying files just like we described. So, double checking the hash is probably a good idea!
Another benefit to sites provide these is because a MitM attack could modify files (like executables) in transit. This means that even though you trust the site and the host, there may be some intermediate vulnerability that is infecting the file. Sure, a sufficiently advanced attack could manipulate both, but if that's the case, they probably don't need to go to that trouble.
So, the hash isn't a way of saying that the file is safe. It's a way for you to see if the host providing the file is providing the same file. If you don't trust the web page, then the hash is of no value (security-wise).
You didn't ask this, but one reason for providing both and MD5 and SHA1 hash is that while it may be possible to create a file with an MD5 collision, and in some cases SHA-1 can be broken too, I haven't heard of any cases where you can generate a malicious file that is a collision for both. It's trivial for the site to calculate multiple hashes, but computationally unfeasible for an attacker to create a malicious file that "double" collides with the real file (as far as I know!).
Hash functions such as MD5 validate the integrity of a file. Authenticity verification is provided when you compare the hash value with one received from an authenticated source, which in this example is the XAMPP website. A hash function can be run against any file or data stream, so yes, a site can calculate and provide a checksum of any file, malicious or not.
I recently signed up for a cloud hosting service that allows for one click application setup and updates using GIT. I created a WordPress application and pulled the code, only to realize that they used my account password as the database password (i.e. the password I used when registering for the service).
This was a bit unnerving. If I ever had my laptop stolen, or accessed without my knowing someone could easily destroy all the apps that I host using the service. When I asked the host about it, they claimed to use AES encryption (as opposed to password salts) and that the connection to the repositories is protected.
Is this a bad design? Is it reasonable never to store passwords in a GIT repo and to enforce salting on passwords? My only other experience is with Heroku where passwords are not included in config files (and my password has never shown up as plain text). Thanks!
I'd like to say that they shouldn't store passwords in a format that can be decrypted at all, instead prefering hashed and salted.
However, the problem here is that they need to access the GIT repository on your behalf. Which means the password has to be decrypted by their servers at the time of use in order to pass it on to the other system.
In reality due to these requirements there is no real way to completely protect it. Sure it's encrypted, however, that decryption key is available to someone that hacks the machine.
It really doesn't matter if you use different passwords or the same one. If their site is hacked then the passwords can be exposed.
So, the real question isn't how are they encrypting it (doesn't really matter). The real question is how are they monitoring the site in general to ensure it hasn't been hacked. This boils down to whether they are using an IDS/IPS (Intrusion Detection/Protection System). If they aren't, then move on to a different provider that is using one.
Ahh, the old "Don't worry, we use AES!" defense. If I understand your statement correctly, it would seem that they're storing their users' passwords unhashed in a single file then encrypting that file with AES. If so, then yes that's bad design generally. The standard method is of course storing hashed and salted passwords in an unencrypted file.
Storing passwords in an encrypted file suffers from a number of problems:
1) What is the password to the encrypted file? For "turtles-all-the-way-down" reasons, you can't encrypt that password. It can be stolen / guessed.
2) You have the standard password problem on the encrypted file. Do you make it low entropy and memorize it? Do you make it high entropy and store it on a disk somewhere. Both have obvious issues, and remember that this key is a single point of failure for the whole system.
3) Anytime their system needs to verify a password, it has to decrypt the file. So in all likelihood, both the file's encryption key and all the file's passwords will be loaded into memory on the server in plaintext.
As for the "They use my one password for both my overall account and my database access" problem, that's more debatable I think. On one hand you might want to limit how much access any one password gets you. But on the other, having to make a different password for every little thing leads to bad password creation and password reuse.
I wanted to know what is the best way to encrypt storage at rest. Lets say financial information for 1000 users is on a system. Besides making sure nobody unauthorized gets to how do we encrypt the data that is being used everyday so that if god forbid they get it, it should be impossible for them to decode or read?
I believe AES is a correct measure?? How can i implement AES using PHP for phpmyadmin data?
Neither SHA nor MD5 are encryption algorithms, so forget them for now.
The answer to your question is more organizational then technical. First you need to identify what storage you plan to use for the data. If it is the DBMS, then (a) it can offer certain encryption and authentication mechanisms, and (b) you can store the files of the DB on the encrypted storage.
If you have files (either the data itself or the DB with the data), you can store them on encrypted disk. This can be an encrypted NTFS disk or virtual encrypted disk (the one which resides in a file and is mounted as a virtual disk by software).
If you create backups of the data, then backup tools usually offer encryption mechanisms too.
In all of the above cases used algorithms don't matter too much: modern algorithms, offered by above mentioned mechanisms, are secure enough given that you choose 128-bit or larger key for symmetric encryption and choose long passphrase (more than 22 characters if you only use [A-z0-9] alphabet for 128-bit symmetric encryption).
There exists symmetric encryption and public-key encryption (PKI encryption). PKI lets you encrypt the files using public keys (private key is used for decryption), and one of the benefits is that you can encrypt the data for several different private keys. This means that any of the given set of keys can be used for decryption, and the owner of one key doesn't need another key for decryption. The benefit is that you can assign keys to certain users or roles instead of sharing a single passhprase.
The above is just a small guideline and you need to learn a lot (or better involve a security specialist) before you implement the solution, cause security made wrong is worse then no security at all (cause it gives false sense of protection and this makes people careless).
That depends on your platform; most modern operating systems offer disk encryption options with various degrees of security. Note that SHA and MD5 are hash algorithms and thus unsuitable for encryption.
I'd base my choice of algorithm on the capabilities of the system that is supposed to work with the data. Some CPUs have special instructions for AES processing, which gives a significant speed boost here; also, there are harddisk controllers that include encryption support.
Dedicated hardware has two major advantages: it is significantly faster, and it is more difficult to retrieve the symmetric key as a prelude to stealing the actual disk drives.