I am using this tutorial to encrpyt and decrpyt passwords that are saved to sql database.
Problem is the RNGCryptoServiceProvider is not supported on the platform i'm using therefore I changed it to SHA1CryptoServiceProvider. How do I get round the GetNonZeroBytes?
RNGCryptoServiceProvider is a cryptographically secure random number generator. SHA1CryptoServiceProvider implements the SHA-1 cryptographic hash function. Those are completely different things; you can't substitute one for the other.
What kind of platform are you on that doesn't have RNGCryptoServiceProvider?
Related
We have a project with a PWA where we want to implement client sided encryption. We wanted to use Webauthn as a second-factor in combination with passwords. In the background we use a randomly generated key to encrypt/decrypt the database, which is stored symmetrically encrypted with the password on the server. However I am struggling to find a good way to add encryption to this key with webauthn. My tries so far:
Using raw JS samples from https://webauthn.guide , however I cannot find a part which is always the same and could be used for symmetric encryption/decryption, even the public key changes when logging in with the same USB token multiple times (???)
Using fido2-lib from npm: I couldn't get the sample to work, since the sample is not well documented and pretty long
Using server-sided authentication like spring webauthn, however I do not want the server to know anything about the client.
Any suggestions how I could implement an encryption with webauthn?
The protocol as it stands does not provide generic public key crypto services as far as I am aware. The best you can do is prove that a user is in possession of the private key related to the public key you hold.
You can learn from the following github repo ,it has many Webauthn out of the box examples (see the tech it supports inside)
Here are some samples I found at github https://github.com/OwnID/samples
In addition,I read about FIDO ,Webauthn and passkeys at passkeys.com
Everything about this cool tech is there
Years after this question, the hmac-secret extension has arrived.
This extension binds a secret to a Webauthn credential. This secret can be used to decrypt or encrypt data on client side.
Another approach could be the use of the largeBlob to store a secret generated during the creation ceremony.
Note that the availability of those extensions depends on the authenticator that is used and may fail.
I have an .Net Application and i want to this application which has some features. Depending client's domain and what features he wants i want to provide him a string which he will store it a file and will be accessible from the application.
I will create a second application which will get as parameters the domain and the features and it will produce the string.
Is there any way to encrypt this string with a key and my application (the first one mentioned) to decrypt it?
I have in mind something like private/public key but reversing the logic. I mean, to encrypt the string from my second application wit the private key and the first application to decrypt it with the public key.
The purpose is the customer to not be able to change the string so that to change the available features.
PS i have an idea to use digital signature, but i dont know if i can have the public/private keys stored at xmlstrings. I think i have seen it somewhere (exporting/importing) but i am not sure
Yes, digital signatures are the correct tool to use for this.
Storing the keys is a minor implementation detail. Typically, such keys are natively represented as binary strings, possibly in ASN.1 or a similar encoding. If you need to store the keys in some format that cannot handle arbitrary binary data, you can always e.g. base64-encode them first.
What is the most secure hash algorithm to use in ColdFusion 9 (non-Enterprise)?
According to the CF documentation, these are the options:
MD5: (default) Generates a 32-character, hexadecimal string, using the
MD5 algorithm (The algorithm used in ColdFusion MX and prior
releases).
SHA: Generates a 40-character string using the Secure Hash Standard
SHA-1 algorithm specified by Nation Institute of Standards and
Technology (NIST) FIPS-180-2.
SHA-256: Generates a 44-character string using the SHA-256 algorithm
specified by FIPS-180-2.
SHA-384: Generates a 64-character string using the SHA-384 algorithm
specified by FIPS-180-2.
SHA-512: Generates an 128-character string using the SHA-1 algorithm
specified by FIPS-180-2.
But in this article, it says not to use MD5 or SHA-1
I am also a little skeptical about the cf documentation. It says encoding "SHA-512" uses SHA-1, but the description of "SHA-512" for the Enterprise version is "The 512-bit secure hash algorithm defined by FIPS 180-2 and FIPS 198." And the output of SHA-512 is larger than SHA-384. Sorry, I am having a hard time getting my head around all these different encoding principles.
Hashes are not secure by themselves, anything that can be hashed can be broken. So in the security world you might think, ok I need to run the hash multiple times to obscure it more, but that doesn't secure the information, it just means someone has to repeat that same process and iterate over the hash multiple times. If they know the hash algorithm you used and assume they do, it's not secure. Sha-256 should be good enough for hashing information unless you are trying to secure the information. Hashes should never ever be used by themselves to secure information. Just because it isn't human readable does not make it secure.
If you want to secure something use coldfusion a encrypt functions and make sure you use a decent algorithm, like AES because the default in coldfusion is not secure. Then you need to use some entropic data from the information you're securing to ensure you have a unique encryption key that would be hard for someone to guess or find. Do not hard code a single key in your code, this will make it easy for someone to find and utilize a pattern in all of your encryptions.
Use something like bcrypt or scyrpt for storing passwords. I know they are more work to put into use and require java integration in coldfusion but they are much more secure ways of storing information. Remember that even with bcrypt or scrypt the information can be compromised given enough time and someone willing to put the effort into decrypting it. Be paranoid when securing information.
Istead of using FormsAuthentication.Encrypt / FormsAuthentication.Decrypt, is it possible to use an existing RSA container in the machine key store to do the encryption/decryption of the ticket.
The reason is that the ASP.Net application I'm developing is meant to be used in multiple load balanced servers. Hence I need to copy the machine key onto all web.config files in all the machines. Since we are already using Asymmetric Encryption (RSA) for another purpose, we have automated installing a common RSA key container in all the servers via a bat file and key container xml. Since this mechanism is in place I want to use the same RSA key container to encrypt/decrypt the forms auth ticket too.
Is this possible? If so how do I override the existing behaviour to achieve this.
If its possible then do you see any disadvantages of using RSA instead of the standard encryption?
Yes, but it would require some work.
You will need to override/replace the standard authentication module that ships with .NET and replicate all the existing functionality with the exception of calls to the RSA Encrypt/Decrypt methods you want to use instead.
See http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.encrypt.aspx
You will also need to edit all the standard builtin login pages if you are using those.
As a template, inspect the source for the FormsAuthenticationTicket and you will see how the string is constructed that contains parameters such as UserID, Expiry Date etc, and then pass that string into the Encrypt method, which in turn is then used as the cookie value.
Your new auth module will then have to reverse that encryption and validate the user as before.
It's a fair amount of work for relatively little gain, depends on how badly you want to use RSA over the standard encryption methods used (they already offer some powerful encruyption methods right out the box see http://www.sourcetree.net/sourcetree/Development/Aspnet%20Examples/GenerateMachineKeyForWebConfig.aspx)
I have made a small program that will allow me to send licenses in encrypted form to users.
At the moment I have
An RSA private key that encrypts my AES key
A single AES/CBC key that encrypts the data
An RSA public key
Both the AES and public key are hard coded onto the device.
How should I deal with the IV when a license is requested, should I create a static one on the device or send a new one with every new license I create?
If I understand what you are trying to do then, like most licensing schemes, it is basically a DRM scheme. I'll only address the cryptography problem, but there is also of course the problem of playing hide-and-seek from the hackers. You should know that no DRM scheme offers any measurable security (unless perhaps security hardware is involved) in the cryptographic sense, but they are still common and some developers are comfortable with the logic behind them.
What you want to do is generate your license data and include some information that prevents a user from simply copying a valid license file from a legitimate user. Examples might be mac address, phone number, etc. Then you sign this data. The license then consists of the unencrypted license and the signature bytes. On the user side, your installation software will verify the signature using the hard-coded public key, and perform any other checks (mac address matches, phone number matches, etc).
This would be the core of your scheme, and is enough for most developers. You can take this core and further obfuscate it using ad-hoc including encryption, splitting, etc., depending on how far you want to go with the hide-and-seek game.
EDIT:
If I may make a suggestion, I think the book Beginning Cryptography With Java would be a wise investment. It includes examples that using the Bouncycastle library. You can donwload the examples for free from the same website.
Isn't this proposal totally silly?
You should encrypt with RSA public keys not with a private key. If you encrypt with a private key as you propose then everyone with access to the public key will learn the AES key and will be able to decrypt or forge anything. Of course for the same reason you should also not use the same AES key for distinct receivers.
And to answer the question, you should use a new random IV for each AES/CBC encryption.