I am currently following Amazon's documentation to sign S3 URL's for download. Using hmac-sha1 is good but I want something more secure since there are inherent flaws as of 2010. Also, it is good marketing too to use strong encryption. I KNOW that others are using 256-bit encryption when signing their URLs. I too would like to use sha256 or sha512, but it seems like Amazon's docs don't tell you how this is possible. They only reference hmac-sha1 (which I'm currently using w/ succcess).
Signature = URL-Encode( Base64( HMAC-SHA1( YourSecretAccessKeyID, UTF-8-Encoding-Of( StringToSign ) ) ) );
How would I go about using something more secure?
Thanks
There are inherent flaws to sha-1 but they don't carry over to hmac-sha-1, so there's no need to worry.
That being said, I actually did find the documentation you were looking for here.
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 a Java application (an ESB - Enterprise Service Bus) which deals with customer sensitive data and have a requirement of supporting Data encryption at rest in order to prevent data abuse.
The application stores customer data for processing on the file system and application interacts with it through java.io.File API. So basically, I need to encrypt the file before it is persisted on the file system by the application and then decrypt it before application reads it so that it can be parsed and processed.
Are there any good frameworks or libraries that can help me implement Data encryption at rest? I am planning to use PGP encryption/decryption for implementing Data encryption at rest.
I am looking for best and recommended approach for implementing Data encryption at rest within my Java application and any help shall be appreciated.
Why on Earth would you think pgp is the right tool for this? Seems to me that you only need a symmetric key solution, so pgp feels like the wrong answer.
Cryptography in Java is a minefield. Easy to do things wrong, hard to do things right.
Having said that, you have a better chance to not screwing up if you use BouncyCastle rather than something else. They have example code that shows you how to do various operations.
For encrypting data at rest, I recommend you use AES in either CBC mode or CTR mode. If using CBC mode, make sure you choose your IV in a cryptographic secure way (unpredictable). Also, never re-use an IV for any mode of operation.
You should also consider whether you need message integrity. General guidance about symmetric encryption here.
Even though people often get crypto wrong, the bigger problem is key management. That's a whole new can of worms (and don't be fooled into thinking pgp provides a solution to this: all it does is shifts the problem to somewhere else).
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.)
Ok after a LOT of researching, I've settled on using bcrypt (feel free to comment) to hash and store passwords in my phonegap app.
A few days ago I stumbled upon Bcrypt.net and it seems 'good enough' to me (again, feel free to comment). So, my question is what other alternative implementations of bcrypt are available in C#? Are there any SERIOUS flaws in the implementation of Bcrypt.net?
My security model is basically going to look like this:
User enters his pin/password/passphrase on the client
This is sent to my .net app over secure SSL (so basically send in plaintext from the client)
Use a library like bcrypt.net to hash the password and do the storage/comparison
Is there anything else that I really need to consider here?
Any help will be greatly appreciated.
Glad to see somebody here who did some research.
I haven't seen any good reasons why you should not use bcrypt. In general, using either bcrypt, PBKDF2 or scrypt on the server to provide a good layer of security.
As always, the devil is in the details. You certainly require SSL, if possible TLS 1.2 using AES encryption. If you cannot do this, make sure you don't allow much else than username/password + necessary HTML in your connection.
You should make a decision on the character encoding of the password. I would advice UTF-8, possibly narrowed down to printable ASCII characters. Either document the character encoding used or store it somewhere in the configuration.
Try to store all input parameters to bcrypt together with the "hashed" password. Certainly don't forget the iteration count. This makes it easier to upgrade to higher iteration count when the user enters his/her password later on. You need to generate a secure random salt of 8-16 bytes to store with the password.
In addition, you may want to apply an additional KBKDF (key based key derivation scheme) to the output of any of above PBKDF's. This makes it possible to use the output of bcyrpt for additional keys etc. KBKDF's work on data with enough entropy, so generally they take little time (e.g. use a NIST SP 800-108 compatible counter mode KDF). I guess this should be considered "expert mode".
The major reasons for doing password hashing are:
a. Password plaintexts are not transmitted over the wire (primary).
b. Password plaintexts are never persisted on server (secondary)
So with your setup - you're not doing a. and instead relying on the SSL. I think you should still hash on client side if possible. Leaves you more margin for future changes and in general, passwords deserve higher security / protection than your content data.
Also, i don't know what kind of server apps / extensibility you may support, so again insulating the password(s) from code might still remain an additional issue.
As far as the actual algo / util for doing the hash - i don't have the security expertise :)
You're good with bcrypt.
Great research from a cracker: https://crackstation.net/hashing-security.htm#faq
Additional verification from sophos: http://www.sophos.com/en-us/medialibrary/PDFs/other/sophossecuritythreatreport2013.pdf
bcrypt is also part of the c# libs:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa375383(v=vs.85).aspx
i just wanna ask what does the openfire use to encrypt passowrd? md5? or wat? =)
Blowfish
Openfire supports multiple storage types so it actually supports a couple hashing algorithms. It depends on the storage type and configuration in openfire.xml
Usually found in: /opt/openfire/config/openfire.xml
Looks something like <passwordType>sha1</passwordType>
Your question is a bit ambiguous though. As it could also mean the format the password is sent over XMPP from the client. This depends on the authentication protocol used and will be defined in the XMPP specs...