Let's say that a user has 2 keys listed in the gpg key ring (i.e., 2 keys with the same Email address). How does one set which key of the 2 to use? The only input that I have is the email, and it is the same for the 2 keys.Thanks
Assuming you're trying to encrypt to one of the keys, you can specify the recipient using the fingerprint or long key ID, for example
gpg --recipient A999B7498D1A8DC473E53C92309F635DAD1B5517 --armor --encrypt
Related
EDIT- The server currently hashes the incoming cleartext user password and compares that with the hash that is stored in the server. My problem is that my application is sending the password already hashed, so when the server tries to hash it again, it obviously doesn't match the cleartext password's hash stored with the server.
An example-
Let's assume the password to be abc and the hash to be
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
Normally the LDAP server receives abc as password, computes the hash
and compares it with what it has stored and it is matched.
My Case: Instead of sending abc, I'm now sending it's hashed form
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Now the server hashes this which results in
b6291ce396cb2fd46f4a5410b4f9a739ae89e182fc0bd0fc7f8d064e5bfe35e9, obviously different from the actual hash of abc and the source of my
problem.
I need to hash and salt user entered passwords and store it in the database. I also need to validate the hashed & salted password when a user login to the site.
I read from the following adobe blog by David Byers:
https://coldfusion.adobe.com/2020/04/best-practices-secure-password-storage-coldfusion/
This blog explains and gives sample codes on how to hash and add salt to user password with screen shots.
My First question is:
Do I need to create two columns in my database table to store the hashed password and the salt just like how he explained in this blog?
If yes,
than my second question is:
How do I validate user password that's been hashed and salted? If the values of hashed and salted password are separated in two columns like that do I have to concatenate the two strings when validating?
My last question is:
How to authenticate/validate user password when the password is hashed and salted? is there any codes example I can see? Thank you
I'm trying to understand how spring security can match the raw password entered by user with the encoded password in the database in the case of random password salting by BCryptPasswordEncoder.
My questions: AFSK bcrypt(random salt + password) = random encoded password, so since bcrypt is a one-way hashing function and the encoded password is fixed in the database, I guess spring security will somehow get the salt while encoding password and before check matches using BCryptPasswordEncoder：boolean matches(java.lang.CharSequence rawPassword, java.lang.String encodedPassword), right?
If so, where the salt is stored, in the database or somewhere else?
If salt is in the database, how to defend against cracking if the database is exposed?
The salt is stored in the same column as the hashed password. Salts are not considered to be secret. Since each is unique it prevents pre-calculating rainbow tables.
If you want higher security, consider peppering (password stays in application and HMACs the salted hashes)
I have 2 database tables consisting of 2 different user types.
Users and Players.
Players is with user data from in-game plugin where passwords are BCrypted.
Users one is empty and is intended to store the user info from the Players table.
I am comparing the usernames and passwords.
The problem is that from the user input in the website get plain text password, and from the other table the passwords are already bcrypted and the Laravel bcrypt does not match the bcrypted cipher from Players table.
What are my options to compare the passwords in order to confirm that this is the user trying to log in.
In-game plugin cipher:
$2a$10$lpVYpSJ4O6Mt03eItJeipOWR8LGHP8dgk4a09.e6BFKVoYNAgjz86
Laravel plain text bcrypted:
$2y$10$yZoq3xBsfow49pL6UyGD2.5NKlmHOmfnCFc9JD5ZjDz3pf5K1XMhG
Both passwords are the same.
Try using Hash::check() function to compare plain password and hashed password.
if (Hash::check('plain-text', $hashedPassword)) {
// The passwords match...
}
I found a solution, by using a library which helped me integrate the plugin on my website.
On top of that I had to do some minor configurations in the config file of the plugin. Changing the encryption method, so it matches the one in my Laravel application (BCrypt).
Later on I found out that I don't need to decrypt the password but just compare the hashes.
I'm trying to migrate the data in magento to another database in which I store the passwords with a normal md5 hash, the problem when exporting the password in Magento is that using
$passHash = $user->getPasswordHash();
Returns the password with salted md5 encryption.
Is there a way to obtain the unsalted md5 hash?
No, you'll never be able to reverse the hash. There is a theoretical possibility using some kind of md5 reversing rainbow table (http://en.wikipedia.org/wiki/Rainbow_table) but not really a stable way to do it.
Maybe an option could be if in the new system you could use the same salt as in Magento, or maybe ask your customers to enter a new password?