Hi I have a quick question about exporting my code signing certificate from Internet Explorer 11 as a password-protected PFX file. When asked to set the password I get the option of choosing TripleDES-SHA1 or AES256-SHA256. This is for a Sectigo/Comodo certificate and the representative I talked to on the phone claimed AES256-SHA256 wouldn't work (not sure I believe him...). Is the rep correct? Should I be choosing one instead of the other or does it not really matter? Anything else to know?
Thanks!
So the representative was totally wrong; I just signed my program with a certificate protected by AES-256 encryption. AES is superior to 3-DES so it's definitely the choice to go with and the signing process should be 100% compatible with AES-256 since the protection is for the PFX file only not the signing interaction with Sectigo/Comodo.
Related
it looks like hex code... (it can be other code) anyway, it is someone's account PW..
how do I decode it?
I want decoding C code or other programs..
the code i have is this :
cb7c3218f1051b2b$c72d8b27d15df9cd7828820d7adc2cceb3e14b9c35d3526638036efa8631eebc:122.46.153.158:1452510156007
01e1811495434703$5537c833a30f83f6645b1c7f4f98824284a18cffd77e16671ef807f55cd6bf0c:112.162.84.36:1452517801693
49cf183fc1f80a2b$58f6a6fe3676e3d9634ac518bf3e7358dc3879a3d01c7139541be2fcdcabc18f:125.177.65.41:1452646507979
6ab4384bf46b191a$fa807a3eb5457e55fa0da1cb768d00314fb0e88e3db829ad67e73f94dadfb974:58.140.228.254:1452906489410
b81243544ad7436b$c9461e4cfc10494272d5ac310938d4c53e7b84b33b3c21959d60c7c9c2f8aa35:175.123.188.192:1452939778425
ae78842c36cc9478$81f93354d49bfcce9cbfb7d09e35e53c54b1ac554fe4982597828f4670c3211d:121.153.189.25:1452939896767
081ceb7b6fd960c1$3976b5d5f4131e0ec69a31c98f61c032db94242896ea233e08205a272f819046:121.159.227.166:1452940209396
f62015dd0f9b3634$d45f89b7d8a4729606943aad29d94b4463dece80c655ff2da259261b87d41993:127.0.0.1:1453184959658
that.. on back is IP. I think that does NOT matter...
You just posted password hashes, together with IP Addresses, to a public web forum.
There may or may not be a way to decode these (which depending on the algorithms used may be impossible or may simply require lots of computing power and guesswork, or rainbow tables or the like to bypass some of that computing power).
But you should not be decoding them, if only because you do not realize that this is a major violation of secure practices. You should be sending an apology to your friend for grossly violating his system's security by posting a list of password hashes and IP addresses to a public web forum. And he should be sending a notice to all of these users to update their passwords, and to update their passwords on any other systems where they use the same password. (Or if they are all his accounts, he should be updating them.)
I edited this question to clarify why I asked this question again (I had weak Google-Fu and found these rather old 1 2 3 pretty-much-duplicates only after posting).
Approaches to accessing a password-protected resources that I've seen in the wild.
Plaintext storage in script (might often end up being shared, or in a Dropbox)
Plaintext storage in a config script
You can do password = readline("Password: ") but of course the password ends up in plaintext in the console (and thus in console logs etc.), so might as well store it in a plaintext config file.
I found this little trick to avoid displaying the password in the Terminal, but running system("stty -echo") on OS X Mavericks leads to the error stty: stdin isn't a terminal, so I guess it wouldn't be particularly portable.
Using tcltk. Has the unfortunate effect of making Rstudio crash and being difficult to install.
keychain. It's not on CRAN, so I don't think I can use this as a first-line approach, I'd also like a bit more detail about where and how passwords are stored on various systems (i.e. will it end up in plaintext on Windows?).
Access tokens, OAuth etc. seem to have similar problems.
I don't know any R packages which use PGP for connections? Probably also a bit difficult for newbie users.
I'm not asking for myself mainly, but I want to provide somewhat sensible defaults for nontechnical users who might store plaintext passwords enabling access to sensitive data in their Dropbox.
Unlike others who asked similar questions, I could also change the server-side of things if I had a better approach.
Are there best-practice approaches that I'm currently missing? My focus on interactive sessions is because I assume that's how most nontechnical types use R, but of course it would be nice if it worked during e.g. knitr report generation too.
Some suggestions to solve your problem securely. These solutions match all programming languages.
Establish a secure connection to your resource without R, like a SSL tunnel.
If you need a secure password in R to establish a secure connection, then you can read this from a secure config file and remove this password variable if you don't use the password anymore. A secure config file is a config file that is not part of your code repository (Git, SVN, ...). You have to manage your secret independent of your code. This mean separate your code and your secrets. One simple way is to put your private and secure secret in your private and secure user home directory. Then you have delegated your security problem to your operating system. Your secret is now save as your OS and your home directory. Pleas check the rights of your home directory and enable the file system encryption if they are off. Notice, this is the way like Maven handle passwords.
You get more security if you encrypt your password/secret config file. Then you have second line of defense.
For most applications is point 2 enough.
Notice, be sure that your secret is not deployed with your code. You need a second way to manage and deploy your secret to production systems.
Notice, be sure that if your programs jams, that your secret is not in memory anymore.
Notice, use always strong algorithms for encryption. Don't implement your own security algorithm, is a high complexity task. Better use standard implementations of strong encryption algorithms.
With the included zip utility in CentOS5 (zip command): i.e. /usr/bin/zip -P $ZIP_PASS ...
I haven't been able to find any documentation on this. I am trying to find out how secure the password is. Is this encrypted? How is it protected if not with encryption?
Thanks
Ok I found the answer I was looking for.... From http://en.wikipedia.org/wiki/ZIP_%28file_format%29 and http://en.wikipedia.org/wiki/Known-plaintext_attack
Encrypted file archives such as ZIP are prone to this attack.[citation
needed] For example, an attacker with an encrypted ZIP file needs only
(part of) one unencrypted file from the archive which forms the
"known-plaintext".[4][5] Then using some publicly available software
they can quickly calculate the key required to decrypt the entire
archive. To obtain this unencrypted file the attacker could search the
website for a suitable file, find it from another archive they can
open, or manually try to reconstruct a plaintext file armed with the
knowledge of the filename from the encrypted archive.
So... the zip is not completely secure - but with random file names (when implemented well) for the file(s) inside the zip, and immediate deletion of the unencrypted file (which is also non-web-accessible) - this appears to be a POSSIBLE solution...
More resources:
http://linux.101hacks.com/archive-compression/password-protection-for-zip-files/
However, the more I read, AES 256bit encrypted zips by 7zip (once installed on the server) is much, much more secure. It is NOT susceptible to the known plaintext attack, either.
Yes, it is encrypted. Per the manual:
-P password
use password to encrypt zipfile entries (if any). THIS IS INSECURE! Many multi-user operating
systems provide ways for any user to see the current command line of any other user; even on
stand-alone systems there is always the threat of over-the-shoulder peeking. Storing the
plaintext password as part of a command line in an automated script is even worse. Whenever
possible, use the non-echoing, interactive prompt to enter passwords. (And where security is
truly important, use strong encryption such as Pretty Good Privacy instead of the relatively
weak encryption provided by standard zipfile utilities.)
This is just found from running "man zip" on a centOS machine.
As the manual entry notes, for high security it is not good to use the password in the command to zip the file, as others could check the process list and see the password as zipping.
I don't know what kind of encryption this uses, but I looked around some and it doesn't appear to be great. There are some similiar questions on stackoverflow to this. Look into using a different zip library if encryption is truly important, use something that allows AES, such as GPG.
I need a system to exchange very secret data (source code that is a trade secret). I will use Crypto++ so practically I can use all encryption algorithms, although I really prefer to use an industry standard.
Currently I'm thinking on these methods:
Have the server generate 2048/4096-bit RSA keys, send the public key over to the client, have the client encrypt the data then send it over to the server.
Use a key exchange method like Diffie-Hellman (Diffie-Hellman-Merkle to be correct) to exchange an AES-256 key.
Initiate a TLS connection and tell the server the AES key directly.
Which approach do you believe I should use? I'm not concerned about performance as long as it's reasonable; security is what matters. If none of them, please suggest another method.
P.S.: I might use chaining on the symmetric algorithm, like AES-Twofish-Serpent.
EDIT: Any recommended software must be in a license that won't restrict proprietary usage. LGPL is as restrictive as it must get. That rules out GPL.
Don't develop your own key exchange and/or key provisioning protocol(s). This is what historically breaks most products and, unless you are a cryoptographer (not a programmer with crypto experience), you'll likely get it wrong.
Use off-the-shelf protocols like SSL/TLS. Eg. TLS initialized with RSA keypairs for mutual authentication and AES session keys sounds appropiate for what you describe
Updated
Bruce Schneier:
"A colleague once told me that the world was full of bad security
systems designed by people who read
Applied Cryptography"
erickson in his post has already give you plenty of evidence why designing your own key provisioning and management protocol is flawed. I just want to drive the point home why Mallory is alive and doing quite well, thanks to overconfident developers:
You design the scheme you propose where the client encrypts with a public key and sends the document back to you. Things work great, but 1 year down the road the certificate is approaching expiration. You send an email out to your clients with the new certificate containing the public key you want your users to sign encrypts the documents with for you. Unknown to you is that over the past 4 months your ISP admin has received a bribe to route all your IP traffic through a remote machine. Your email is intercepted before distribution and your attached certificate is replaced with another one. All your clients are now sending their ultra secret documents encryted for someone else's private key. An application decrypts each one, stores it, then encrypts it with your public key and forwards the traffic to you. You won't even know is happening, untill by accident during a visit to a client's site you notice that the certificate he uses is not the one you distributed.
You mention in your post as an option to chain algorithms. Nobody is going to brute force you. Your weakness will be key management, and the attack will take some form of social engineering to fool someone is using the wrong key, or reveling the private key (again, bribes go a long way). Industry agreed protocols have steps to prevent man-in-the-middle attacks, they may rely on PKI infrastructure that recognizes designated key use and trusted authorities, they add certificate revocation list check steps to the validation etc etc. Just 'I encrypt with public key, you decrypt with private' does not make a secret safe.
I'd recommend using an existing S/MIME (or CMS) implementation with a solid cryptographic module to encrypt your content.
S/MIME enveloped data makes a nice format for storage of encrypted data "at rest": the envelope records information about the algorithms and keys used so that the information will be available to authorized recipients later, when it is needed.
Also, even if it doesn't support the "best" algorithms (like ECDH key agreement), a good library is much less likely to have vulnerabilities than something written by a general programmer. Since it is far, far more likely that security will be breached by an implementation error than cryptanalysis, it makes sense to minimize those errors.
In legitimate protocols, public keys are signed by one of a small number of trusted issuers, whose public keys are distributed by some secure means "out-of-band". If you already have a secure means to get a public key to the message sender, why bother sending another? And if you don't, you're screwed.
TLS and S/MIME depend on having a set of well known CA certificates at every client. These are used to sign the server's public key so that a client can detect attempts to substitute keys. The protocol can't bootstrap itself; there must be a secure way to distribute "trust anchors" out-of-band.
Also note that RSA is incredibly slow compared to symmetric ciphers. Real protocols generate a "content encryption key" for a symmetric algorithm like AES, then use an RSA public key as a "key encryption key" to encrypt the content encryption key for the message recipient(s).
So, the main problem is getting your public key to the client securely. If you can do that, either option #1 or #2 is good—assuming that you just use that public key, rather than trying to send another one "in-band". In fact, in CMS, Option #1 is called "key transport", and Option #2 is called "key agreement".
In practice, the "server" could use a certificate issued by a CA that is already well known, or the client can compare a hash of the certificate with one that you tell him over the phone, or carve into the face of a cliff, or whatever. The critical thing is, all of your security depends on the integrity of the certificate. You have to protect it from tampering.
While Crypto++ is an "industry standard", its security depends on how you use it. Just like Jerry told Kramer, "the door must be… closed!" Using the cryptographic primitives in Crypto++ with in a poorly designed protocol will get you nowhere. That's why I'm stressing the use of CMS (a higher-level protocol) together with a good cryptographic module (cryptographic primitives).
What about ssh ? (rsync on ssh for example) ?
I'm using an identical call to "CryptUnprotectData" (exposed from Crypt32.dll) between XP and Vista. Works fine in XP. I get the following exception when I run in Vista:
"Decryption failed. Key not valid for use in specified state."
As expected, the versions of crypt32.dll are different between XP and Vista (w/XP actually having the more recent, possibly as a result of SP3 or some other update).
More specifically, I'm encrypting data, putting it in the registry, then reading and decrypting using "CryptUnprotectData". UAC is turned off.
Anyone seen this one before?
The CryptUnprotectData function documentation states that it usually only works when the user has the same logon credentials as the encrypter.
This suggests to me that maybe the key is tied to the user's current token. Since you mention Vista, this makes me think UAC and restricted tokens.
Can you show us some code? Can you give us more information about what you're doing with the data -- i.e. are you moving it between processes, or users, or computers?
Nice. Hopefully this is my bone-head move of the week! ;-)
This suggests to me that maybe the key
is tied to the user's current token.
That was it. Turns out I was using encrypted data from another machine (the XP one) and trying to decrypt on the Vista machine.
As the MSDN documentation states:
Usually, only a user with the same
logon credentials as the encrypter can
decrypt the data. In addition, the
encryption and decryption must be done
on the same computer.
Once I re-encrypted the data on the Vista machine, decryption works as expected.
Thanks.