We have a new Code Sign certificate. This time it is an EV Code Sign certificate from GlobalSign. The certificate is now only available in Azure Key Vault as RSA-HSM.
I did manage to sign dll's and executables using AzureSignTool where I also asked this question
Todo:
Use AzureSignTool inside Installshield professional, which is sadly not possible
Use AzureSignTool inside Wix toolset
This question:
Sign VBA (Macro's inside doc and/or docx)
After reading into what VBA signing is, I figured out that Signing a VBA file is in fact done by SignedCms. Looking at the source from EPPlus I found that it is doing it that way.
Except that we do not have a private key directly, the azure key vault has. A piece of code can obtain it when it has access to the key vault, but only the RSA private key.
Perhaps this issue is related?
dotnet/runtime#24707
Which is implemented into .net core 3.0 and newer
dotnet/corefx#29219
I recently had to do exactly this and it was more painful than I had expected. It turns out that Azure Key Vault is currently the only cloud KMS that can do it. This is because VBA Macro signing requires at least one signature that uses MD5 and the other KMS providers (i.e., AWS KMS and Google KMS) only support SHA-256, SHA-384, and SHA-512 signature schemes. Azure Key Vault can do it because it supports RSNULL which means you can hash the data and apply the ASN.1 encoding client-side (in your cryptographic service provider) before sending it to Azure for signing.
Long story short, you need to implement the CNG interface to create a KSP that does the client-side hashing, ASN.1 encoding (since it is an RSA signature), and then sends the result to Azure for signing while specifying RSNULL as the signature algorithm. Alternatively, you can use a third party solution that does all this for you. We use this one, although there may be others out there as well.
Related
I have an app in which users need to enter their API keys for third-party services,
What is the best way to store users' API keys? I know we can encrypt them using a private key but that arises another problem, how to securely store the encryption key? We don't want to have a like one encryption key for all of the users.
Thanks for your help
The correct answer is dedicated secret storage. If you are using a cloud deployment the AWS Secrets Manager, GCP Secret Manager or Azure Key Vault are the offerings from the big three cloud vendors.
If you are deploying on a kubernetes cluster you can use the built in secret storage.
Or in any scenario you can use dedicated third party secret storage software, such as Hashicorp Vault, akeyless or others.
If you have very valuable keys that should never be out in the open (and you have plenty of money to spend) you should look into hardware security modules, for example ulitmaco. These can provide key usage without the key ever leaving the secured device. The cloud vendors also offer services using HSMs, for example AWS CloudHSM, GCP Cloud HSM, Azure Dedicated HSM.
For keys you need on the application side: You should never store secrets in the code repository nor on disk during deployment. A good practice is to either use environment variables or a temporary file that gets deleted after startup (in case of containers, where you can restart the whole container).
Why Hadoop prefers Kerberos instead of PKI(Public Key Infrastructure) or oAuth for authentication? What are the design reasons which led to Kerberos?
You might find the below link useful: https://issues.apache.org/jira/secure/attachment/12428537/security-design.pdf
Update: The doc says "...We choose Kerberos over SSL for the following reasons.
1. Better performance Kerberos uses symmetric key operations, which are orders of magnitude faster than public key operations used by SSL.
2. Simpler user management For example, revoking a user can be done by simply deleting the user from the centrally managed Kerberos KDC (key distribution center). Whereas in SSL, a new certificate revocation list has to be generated and propagated to all servers."
I was wondering the same thing and after doing some brief research it seems to me that the primary reason for not using OAuth might have been quite trivial - the pdf linked in the previous answer dates back to 2009 whereas OAuth 1.0 was officially released as a standard in late 2010 and OAuth 2.0 which is de facto the standard today was published in late 2012...
Seems there are some misty plans on adding OAuth support to Hadoop: https://issues.apache.org/jira/browse/HADOOP-11744
Starting completely from scratch with a new server. Do we need to specify a filekey? If so, does it has to be something specific when I use AWS storage or not?
In parse-server you dont have to put this keys
this is from parse-server wiki
Parse Server does not require the use of client-side keys. This includes the client key, JavaScript key, .NET key, and REST API key.
The Application ID is sufficient to secure your app.
However, you have the option to specify any of these four keys upon
initialization. Upon doing so, Parse Server will enforce that any
clients passing a key matches. The behavior is consistent with hosted
Parse.
The problem with this keys that they publish with you app and all of them (javascript key file key...) are not private. So their is no security benefit to use them.
Normally I would add the secret key as an environment variable, but what is the best way to do it in Parse?
The Parse config functionality doesn't solve my problem because the secret key would be available on the client side. There are not security mechanisms to prevent access to specific config variables.
The only solution I can think of, is creating a class to store this really sensitive information and add security so it can not be accessed from a client application (or by certain users).
I don't love this solution because it adds extra requests each time the secret key is needed, which is bad in terms of response time and request usage limits/cost.
In AWS ..
You can use role based authentication using AWS SDK, where it get the role of you resource (ECS, EC2) and retrieve access and secret key from resource registry.
which is a similar implementation you mentioned in your post. That is quite helpful to provide security for your access key and secret, where you don't have to parse or get it from ENV as that can be compromise any time.
Also resource registry based key keep on changing over time so if anybody gets that also can't use it.
You can try to check the implementation how AWS resource / role based authentication works for AWS SDK.
I am looking for the best practice for storing user credentials in a windows 7 phone app. I am writing an app for a web service that requires authentication. Thankfully it is only basic authentication at this point. What is the best way to store those credentials?
The best way to store credentials in your case would be encrypting them and storing in the application-specific isolated storage - basically, it cannot be accessed by any other application, so that gives another protection layer.
In terms of security, the best practice would be to avoid storing user credentials if possible. MSDN states:
Applications often ask users to
provide a username and password that
is used as credentials to authenticate
the user with a web service or
website, yet if they do so each time
the application is run, users can
become annoyed.
It is strongly recommended that your
application prompt for usernames and
passwords each time your application
needs them from the user; if you
attempt to save the credentials on the
phone you risk exposure of those
credentials to a malicious application
if the Windows Phone is lost or
stolen.
Actually, in the data encryption tutorial mentioned in the other answer, Rob Tiffany makes a similar disclaimer:
The OS Does Not include framework
support for storing your passwords and
salt values securely nor does it come
with any kind of built-in key
management. This means the only way
to ensure your encrypted data is
actually secure is to never store
your password, salt value or keys on
the phone.
...
If you see an app in the Windows
Phone Marketplace that allows you to
cache your credentials or keys locally
for convenience, be aware that these
are Not Secure solutions because
everything a hacker needs to get at
your data is right there in the code
or in Isolated Storage.
Encryption is good for raising the bar, but this would not really protect the credentials from a knowledegable hacker. Usability sometimes trumps security, but you should take this decision knowing that encryption will not solve the core issue in this case (and maybe let the user be aware of this risk).
A good explanation by Rob Tiffany of how to encrypt your data in isolated storage can be found here:
Don’t forget to Encrypt your Windows Phone 7 Data
I haven't tried out the code myself, so can't vouch for it's correctness (sorry Rob :-) - should serve as a good starting point though, I would imagine.
I also second Dennis' point about application-specific isolated storage giving you an additional/basic layer of protection in addition to encryption, as theoretically at least, other applications cannot access your applications isolated store.
You should use the ProtectedData class to store securely various bits of confidential information.
Learn more at How to: Encrypt Data in a Windows Phone Application