Is there a way to set the salt in pl/sql when using DBMS_CRYPTO?
My code looks like:
--PBEWithMD5AndTripleDES -> Origin Encryption algorithm
encryption_type PLS_INTEGER := SYS.DBMS_CRYPTO.DES3_CBC_PKCS5 + DBMS_CRYPTO.HASH_MD5;
saltInput RAW(2000); -- needed to parse value for decryption process
digestInput RAW(2000); -- needed to parse value for decryption process
password RAW(2000); -- Password (Raw) AL32UTF8 converted
rawOutput := SYS.DBMS_CRYPTO.DECRYPT
(
src => digestInput,
typ => encryption_type,
key => password
-- add salt here for the decryption like it was originally made
);
I need to add the salt which was randomly created when encrypting and attached to the front of the encrypted value.
I am able to get this salt, but I am not able to tell DBMS_CRYPTO to use the salt for it's encryption and decryption algorithm.
Related
I'm trying to make secure keeping users passwords in database. After quick research I decided use ed25519_dalek library.
Important notice:
I plan use this encryption in actix website.
For now steps are simple:
save password in variable,
generate keys,
save secret and public passwords in file(for now),
encrypt password,
save password to database(skipping for now),
I'm stack in third step: saving keys to file.
To be honest I can write passwords to file, but can't read it.
My code below:
use std::io;
use std::io::{BufRead, Write};
use rand::rngs::OsRng;
use ed25519_dalek::{Keypair, PublicKey, Signature, Signer, Verifier};
use ed25519_dalek::{PUBLIC_KEY_LENGTH, SECRET_KEY_LENGTH, KEYPAIR_LENGTH, SIGNATURE_LENGTH};
let mut csprng = OsRng{};
let keypair: Keypair = Keypair::generate(&mut csprng);
let password: &[u8] = b"testing_password123!##$%";
let signature: Signature = keypair.sign(password);
assert!(keypair.verify(&password, &signature).is_ok());
For this moment my code works well. I'm getting signature and looks like values password and signature are the same.
I'm trying to deserialize keys:
let public_key_bytes: [u8; PUBLIC_KEY_LENGTH] = keypair.public.to_bytes();
let secret_key_bytes: [u8; SECRET_KEY_LENGTH] = keypair.secret.to_bytes();
let keypair_bytes: [u8; KEYPAIR_LENGTH] = keypair.to_bytes();
let signature_bytes: [u8; SIGNATURE_LENGTH] = signature.to_bytes();
After this, I want to save secret key and public key to different files. But for simplify we want to save only secret key.
My steps below:
use std::fs::File;
use std::io::prelude::*;
use std::path::Path;
let filename = "keys.txt";
let path = Path::new(filename);
let display = path.display();
let mut file = match File::create(&path) {
Err(why) => panic!("Couldn't create {}: {}", display, why),
Ok(file) => file,
};
match file.write_all(&secret_key_bytes) {
Err(why) => panic!("couldn't write to {}: {}", display, why),
Ok(_) => println!("successfully wrote to {}", display),
};
In this step I can write bytes to a file. But... The key has type [u8;32]. Using cat command showing strange things(I understand why).
But I can't read this file. Bytes can't be read like this.
After this entry is time for my question:
How can I change type of secret key [u8;32] to String or str?
My idea is:
Change datatype to String or str and then save to file.
Or maybe I do something wrong or simply is it better way to do this?
I need little push in right way :)
It is unsafe to encrypt and store passwords in a database. Moreover you are planning to store both public and private keys in files. The program requires it to be kept in reach for authenticating, so it won't be hard for someone to find the files with public and private keys. Anyone who have access to those files can access users' passwords including you.
The workaround is to generate a hash from the password and store it in the database. Hashing is a one way process of generating a string from an input string such that the inverse operation is impossible. So,the hash of the user input and the hash in the database is matched to authorize the user. There are a bunch of hashing functions available in RUST including the SHA-2 family hashing functions.
It is still insecure if you are just hashing the passwords and saving them in the database since the hashes of most common passwords and almost all possible words are already available in datasets named hash dictionaries and by using that, anyone who have access to your database can find the password. This technique is called dictionary attack. To prevent it, you can make the input string larger by concatenating with some random characters (salt) with the user input and
store the hash and the salt in the database.
I am implementing a new password stored procedure into my companies current product. It is a ASP.NET application with MS SQL Server.
Before they used 3DES encryption off the same common seed to encrypt, and to check a users authentication they just decrypted the password using the same seed.
I am implementing a SHA256 hash, with a salt that can not be decrypted.
Firstly, I understand that every salt should be different per user, but I don't understand where this salt would be stored? If its stored in the database, doesn't this void its purpose?
My idea was creating a salt by taking the first 4 letters of the username, the first 3 letters of the first name, and the first 3 letters of the last name, and converting it into a md5 hash and then using that as the salt without storing in the database.
This sequence would be server side so that no hacker could know the sequence without the source code.
Is there any issues with what I am doing here?
Also is SHA256 acceptable or should I be looking at SHA512.
Thanks
"Is there any issues with what I am doing here?"
Yes, there is. Obscurity is not security. Just because the salt is hard to find out doesn't mean that it's very secure. Figuring out how you created the salt would be a piece of cake compared to forcing the hash.
There is no need to keep the salt secret, just create a random number for each user and store along with the password. The purpose of the salt is to elliminate the advantages of using rainbow tables to crack all the passwords in a table. The salt just have to be different for most users (preferably unique, but that's not crucial).
If you absolutely must implement this yourself (personally I'm a fan of MembershipReboot, then you should take a look at PBKDF2 for password storage.
Not only will it implement the salt properly, it also supports multiple iterations to help deter brute force attacks. You can find guidance for the number of iterations here.
Also worth noting, PBKDF2 is an acceptable NIST standard in case validation is a concern.
To answer your question about keeping the salt in the database, there's no need to keep it secret. The purpose of the salt is simply to prevent pre-computation of hashes, not obfuscate or 'encrypt' in any way.
Rainbow tables work by pre-computing passwords, and then when brute forcing, looking up the respective hash in the rainbow table. You can actually see how simple it is by googling MD5 hashes, and often in the search results you'll find the original input.
For example, if you google the string '5f4dcc3b5aa765d61d8327deb882cf99', you'll find it corresponds to 'password'.
By using a salt, the attacker must compute unique hashes for every possible password, instead of just a generalized list.
The salt is NOT supposed to be private. It is distributed along with the hash, usually prepended to it. The sole purpose of the salt is to make sure that if the same data is encrypted twice you never get the same output. By definition it has to be unique, but randomness or secrecy is not required.
You should also NOT create a random number per user. The salt needs to be different for every encryption, even for the same user. Just generate a random salt, use it to create your hash, prepend the salt to the hash, encode everything to base64, and store it. To verify the hash you decode to binary, extract the salt, use it to hash your input data and compare with the decoded hash.
Something that works well as a salt is a GUID. 128 bits, by definition unique, although not totally random, and available instantly without any additional code. Here is an example of an AES-256 encrypt and decrypt. Keep in mind in a real implementation you would want the plain text and key to be stored in SecureString objects...
Private blockSize = 128
Private keySize = 256
Private cipherMode = CipherMode.CBC
Protected Function AESEncryptStringToBase64(strPlainText As String, strKey As String) As String
Dim Algo As AesManaged = AesManaged.Create()
With Algo
.BlockSize = blockSize
.FeedbackSize = blockSize
.KeySize = keySize
.Mode = cipherMode
.IV = Guid.NewGuid().ToByteArray()
.Key = Encoding.ASCII.GetBytes(strKey)
End With
Using Encryptor As ICryptoTransform = Algo.CreateEncryptor()
Using MemStream As New MemoryStream
Using CryptStream As New CryptoStream(MemStream, Encryptor, CryptoStreamMode.Write)
Using Writer As New StreamWriter(CryptStream)
Writer.Write(strPlainText)
End Using
AESEncryptStringToBase64 = Convert.ToBase64String(Algo.IV.Concat(MemStream.ToArray()).ToArray())
End Using
End Using
End Using
End Function
Protected Function AESDecryptBase64ToString(strCipherText As String, strKey As String) As String
Dim arrSaltAndCipherText As Byte() = Convert.FromBase64String(strCipherText)
Dim Algo As AesManaged = AesManaged.Create()
With Algo
.BlockSize = blockSize
.FeedbackSize = blockSize
.KeySize = keySize
.Mode = cipherMode
.IV = arrSaltAndCipherText.Take(16).ToArray()
.Key = Encoding.ASCII.GetBytes(strKey)
End With
Using Decryptor As ICryptoTransform = Algo.CreateDecryptor()
Using MemStream As New MemoryStream(arrSaltAndCipherText.Skip(16).ToArray())
Using CryptStream As New CryptoStream(MemStream, Decryptor, CryptoStreamMode.Read)
Using Reader As New StreamReader(CryptStream)
AESDecryptBase64ToString = Reader.ReadToEnd()
End Using
End Using
End Using
End Using
End Function
i use this code for encrypt my data to blwofish but i dont know really to convert to blowfish or other encryption.
echo crypt('ab','$2a$09$anexamplestringforsalt$')."\n";
and i'm try bottom code but it's false
echo CRYPT_BLOWFISH('ab','$2a$09$anexamplestringforsalt$')."\n";
It is the crypt parameter string, that defines which algorithm is used:
$2a : This describes the algorithm (BCrypt) but should be 2y nowadays
$09 : This is the number of rounds and is usually 10 or higher
$anexamplestringforsalt : This should be a really random salt of a given alphabet
To generate a BCrypt hash, it is much safer to use the new password_hash() function though, there exists also a compatibility pack for earlier PHP versions.
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_BCRYPT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);
I have a client who is implementing ZNode which uses the aspnet_Membership table to store a password. This table contains an encrypted password, the password salt and is using the "PasswordFormat" of 2. From what I gather, "2" is a recoverable encrypted password.
The ColdFusion server is BlueDragon 9 Alpha. If you don't know BD, no worries, anything that ColdFusion supports "should" work and I have CF 10 to test it on as well.
If you know a better way to do this I'm all ears. I need to be able to create a user/password and store it in the ASP membership table via ColdFusion. In addition I need to be able to check the user/password for login.
When looking at the Web.config file, the ZnodeMembershipProvider is a "System.Web.Security.SqlMembershipProvider" type.
The machineKey entry looks like this: (took out the two key values)
<machineKey decryption="AES"
decryptionKey="[64 character string]"
validation="SHA1"
validationKey="[128 character string]"/>
If I try something like this:
Encrypt('myPassword', '[64 character string]', 'AES', 'Base64')
It says "Specified key is not a valid size for this algorithm."
I'm not very savy on encryption or .NET. Thanks in advance.
I believe that .NET Password tables use Triple-DES, not AES. Try this instead.
Encrypt('myPassword', '[64 character string]', '3DES', 'Base64')
This answer I wrote up, about DNN (Dot Net Nuke) authentication, should do the trick. (Assuming no differences between ACF and BD). Essentially there are few difference in how .NET and CF handle encryption. The primary differences are:
Encoding:
.NET uses UTF-16LE
CF always uses UTF-8. In ACF, this means you must use encryptBinary instead of encrypt. (I am not sure about OBD).
Key Format:
.NET uses hexadecimal
CF typically uses base64, so you may need to convert the keys first.
Encryption Mode:
.NET defaults to CBC mode (requires IV)
CF defaults to ECB (no IV required)
In case the other link dies, here is the full example. While it uses 3DES, the basic concept is the same for AES. Note: In Java, the larger key sizes (ie 192,256) are only available if the Sun Unlimited Strength Jurisdiction Policy Files are installed.
3DES Example:
// sample valus
plainPassword = "password12345";
base64Salt = "x7le6CBSEvsFeqklvLbMUw==";
hexDecryptKey = "303132333435363738393031323334353637383930313233";
// first extract the bytes of the salt and password
saltBytes = binaryDecode(base64Salt, "base64");
passBytes = charsetDecode(plainPassword, "UTF-16LE" );
// next combine the bytes. note, the returned arrays are immutable,
// so we cannot use the standard CF tricks to merge them
// NOTE: If BlueDragon does not include "org.apache.commons...."
// just loop through the arrays and merge them manually
ArrayUtils = createObject("java", "org.apache.commons.lang.ArrayUtils");
dataBytes = ArrayUtils.addAll( saltBytes, passBytes );
// convert DNN hex key to base64 for ColdFusion
base64Key = binaryEncode(binaryDecode( hexDecryptKey, "hex"), "base64");
// create an IV and intialize it with all zeroes
// block size: 16 => AES, 8=> DES or TripleDES
blockSize = 8;
iv = javacast("byte[]", listToArray(repeatString("0,", blocksize)));
// encrypt using CBC mode
bytes = encryptBinary(dataBytes, base64Key, "DESede/CBC/PKCS5Padding", iv);
// result: WBAnoV+7cLVI95LwVQhtysHb5/pjqVG35nP5Zdu7T/Cn94Sd8v1Vk9zpjQSFGSkv
WriteOutput("encrypted password="& binaryEncode( bytes, "base64" ));
i was reading this tutorial, and i encountered the following discussion about encryption. At the end there's written
In the last line, we’ve hashed the salt with the password, yielding an
encrypted password that is virtually
impossible to crack
But in my opinion an hacker who has both the encrypted_password and the salt could do the "rainbow" trick exactly as if we were using the salt.
So, where i'm wrong?
Thanks!
$ rails console
>> require 'digest'
>> def secure_hash(string)
>> Digest::SHA2.hexdigest(string)
>> end
=> nil
>> password = "secret"
=> "secret"
>> encrypted_password = secure_hash(password)
=> "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> submitted_password = "secret"
=> "secret"
>> encrypted_password == secure_hash(submitted_password)
=> true
Here we’ve defined a function called
secure_hash that uses a cryptographic
hash function called SHA2, part of the
SHA family of hash functions, which we
include into Ruby through the digest
library.7 It’s not important to know
exactly how these hash functions work;
for our purposes what’s important is
that they are one-way: there is no
computationally tractable way to
discover that
2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b
is the SHA2 hash of the string
"secret".
If you think about it, though, we
still have a problem: if an attacker
ever got hold of the hashed passwords,
he would still have a chance at
discovering the originals. For
example, he could guess that we used
SHA2, and so write a program to
compare a given hash to the hashed
values of potential passwords:
>> hash = "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> secure_hash("secede") == hash
=> false
>> secure_hash("second") == hash
=> false
>> secure_hash("secret") == hash
=> true
So our attacker has a match—bad news
for any users with password "secret".
This technique is known as a rainbow
attack.
To foil a potential rainbow attack, we
can use a salt, which is a different
unique string for each user.8 One
common way to (nearly) ensure
uniqueness is to hash the current time
(in UTC to be time zone–independent)
along with the password, so that two
users will have the same salt only if
they are created at exactly the same
time and have the same password. Let’s
see how this works using the
secure_hash function defined in the
console above:
>> Time.now.utc
=> Fri Jan 29 18:11:27 UTC 2010
>> password = "secret"
=> "secret"
>> salt = secure_hash("#{Time.now.utc}--#{password}")
=> "d1a3eb8c9aab32ec19cfda810d2ab351873b5dca4e16e7f57b3c1932113314c8"
>> encrypted_password = secure_hash("#{salt}--#{password}")
=> "69a98a49b7fd103058639be84fb88c19c998c8ad3639cfc5deb458018561c847"
In the last line, we’ve hashed the salt with the password, yielding an
encrypted password that is virtually
impossible to crack. (For clarity,
arguments to hashing functions are
often separated with --.)
Rainbow tables are expensive to compute. Without the salt, you can build a rainbow table once that can be used repeatedly, since the password "password" will always yield the same hash (md5=5f4dcc3b5aa765d61d8327deb882cf99, sha1=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8) and is thus easy to identify in a password database.
With a salt, you have to compute a rainbow table for each salt you encounter. A good-sized salt, say 32 bits (ideally, 128 or even more), means you have to compute a rainbow table for every password you want to crack, thus largely defeating its purpose.
Salt is to stop someone from pre-computing a "reverse" lookup table that allows an attacker to quickly find a password that results in the target hash. Creating one of these tables is as much work, computationally, as brute-forcing the target password space, so it's only worthwhile if you can use the table on many targets.
Salt prevents this; the attacker would need to account for the salt when they generated the table, so the table would be good for only a single target, and the attacker is back to brute force.
Yes, you are right, if somebody had knowledge of your algorithm and the salt, he could generate a rainbow table. However, generating a rainbow table takes a long time the more characters are allowed.
So for example, if you have an password consisting of 10 characters, which all are numbers, you have 10^10 possibilites. If you allow lower and upper case alphabetical chars, this goes up to 62^10 possibilites, a mere 8.39 * 10^17 permutations; and that's only for 10 character passwords, you also have to take into account any length below that and above, depending on the length of password you allow.
It takes a long time generate such a table, while rainbow tables for the algorithm itself might be readily available, the salt modifies the algorithm to make it your own, and the possibility for a table existing for that is very low.
If you use salt (even if it is public but uniqueto a site) you will get a protection from hash-dictionaries, where often used passwords are already hashed.
If your salt is secure then they can not brute-force it using supercomputers. They have to check every possible password with your server (which let's hope has some form of bruteforce-protection).