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...
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).
This is a Paw question. Is there a Paw encryption add-on that supports AES working in the commonly used modes and lengths?
I have a request that includes encrypted fields. These fields are AES encrypted. The key is 128 bits long. The encryption mode is CBC. The encryption is performed by the mobile app. The key is inside the mobile app.
At the moment, I capture the requests in Burp, Import them into Paw, and then I have the valid request.
I know the plaintext. I know the key. I know the algorithm. I know the Initialization Vector. There must be a better way.
I could not find anything on: https://paw.cloud/extensions/
There are two new DynamicValues that should allow you to do what you wish to do:
AES Decrypt
AES Encrypt
They are based on an npm port of the CryptoJS library and should expose most of the API for decryption/encryption in AES.
Here's a couple screenshot to show you what it looks like:
Since the DynamicValues are quite recent, there may be a few issues with them. Don't hesitate to report them.
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.
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