I have a key to be decrypted shown here dc6f0dbebfc5747330deeedfbd8475568a740d0a. The following key has salt value prefixed before the key. The salt value is 80808080. How can i decrypt this.
Hashes are not meant to be broken but you can use a tool like this to crack it (If you're lucky). This hash is for the string 'azerty'
Hashes are not decrypted. In their regular usage as password hashes, you can validate an entered password using the hash but you can't find the password given the hash, because the hash function isn't reversible. The exception is brute force password cracking which works for sufficiently simple passwords only.
Related
I'm using the default identity stuff provided by ASP.NET 4.5 MVC and Entity Framework. I can create users with passwords and the hashed password shows up in the database. I'm trying to figure out if that hash is generated using the no-longer-trusted SHA1 algorithm or the SHA2 algorithm (be it SHA256, SHA512, etc).
Articles which seem to say it defaults to SHA256:
https://www.asp.net/whitepapers/aspnet4/breaking-changes#0.1__Toc256770148
http://kosmisch.net/Blog/DotNetEssential/Archive/2015/2/1/aspnet-membership-default-password-hash-algorithms-in-net-4x-and-previous-versions.html
Articles which seem to say it defaults to SHA1:
https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing
https://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx
When I follow the chain down, I end up inside the PasswordHasher.cs class -> HashPassword() -> Crypto.HashPassword() which I can see is using Rfc2898DeriveBytes which then has a bunch of stuff about HMACSHA1.
So are my passwords getting hashed by SHA256 or SHA1? Easy way to default to SHA256?
If it helps, here is a dummy password taken from my local environment:
AIPfkvy5v59jmVZdPpU9QfUMoToCQ+Rp3dBT7m9RwMKZai5/61REkN/0InCtxKPUOQ==
So it looks like the answer is neither exactly:
From the comments in the ASP.Net Identity Source Code
Version 0:
PBKDF2 with HMAC-SHA1, 128-bit salt, 256-bit subkey, 1000 iterations.
See also: SDL crypto guidelines v5.1, Part III)
Format: { 0x00, salt, subkey }
Ultimately the hashing algorithim is SHA1, but it is not a simple SHA1 hash of the password, or even a SHA1 + salt hash.
It is worth pointing out that SHA1 is considered "broken" for digital signatures due to a mathematical attack, reducing the computational effort of generating a collision to just-about feasible levels.
This does not apply to hashed passwords.
Links for further reading.
Is SHA-1 secure for password storage?
https://www.schneier.com/blog/archives/2005/02/sha1_broken.html
https://en.wikipedia.org/wiki/PBKDF2
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Rfc2898DeriveBytes and HMACSHA1
I'm building an application in which a password is used on the client side to encrypt a private key of a elliptic curve key pair. Then the password is bcrypted and sent to the server (along with the encrypted private key) and the public key.
Originally, I was using pbkdf2 to hash the password before encrypting the private key, but since I'm also bcrypting the password, could I use the bcrypted one instead?
According to https://medium.com/#mpreziuso/password-hashing-pbkdf2-scrypt-bcrypt-1ef4bb9c19b3#.sj4jcbynx the answer is not only yes, but bcrypt is even better as it's more GPU-ASIC resilient. Anything I'm missing?
You should not be using the bcrypt hash output as an encryption key; it is not meant to be key material:
BCrypt is not a key-derivation function
BCrypt it is a password storage function
You have an elliptic curve private key that you want to encrypt using a user's password. Of course you don't want to use the password directly - you want to use the password to derive an encryption key. For that you can use:
PBKDF2
scrypt
These are both key-derivation functions (e.g. password-based key derivation function). Their purpose is to generate an encryption key given a password. They are designed to be "hard".
You feed both these algorithms:
a password
cost parameters
salt
desired number of bytes (e.g. 32 ==> 32 bytes ==> 256 bits)
and it returns you a 256-bit key you can use as an encryption key to AES-256.
You then want to backup the user's key
I gather that you then want to:
store the encrypted elliptic curve private key on your server
store a hash of their password on your server
And your question was: since you already ran their password through "a hashing funtion" can't you just use that hash as their stored password?
No! That hash is also the encryption key protecting their private key. You don't want that private key transmitted anywhere. You don't want it existing anywhere. That 32-byte encryption key should be wiped from memory as soon as you're done with it.
What you should do, if you also wish to store a hash of the user's password is use an algorithm that is typically used for password storage:
pbkdf2 (a key-derivation function abused into password storage)
bcrypt (better than pbkdf2)
scrypt (a key-derivation function abused into password storage; better than bcrypt)
argon2 (better than scrypt)
Update: Argon2/Argon2i/Argon2d/Argon2id is weaker than bcrypt for password authentication (read more)
You should separately run the user's password through one of these password storage algorithms. If you have access to bcrypt; use that over pbkdf2. If you have scrypt, use that for both:
derivation of an encryption key
hashing of the password
The security of your system comes from (in addition to the secrecy of the password), the computational distance between the user's password and the encryption key protecting their private key:
"hunter2" --PBKDF2--> Key material
"hunter2" ---------bcrypt-------> Key material
"hunter2" ----------------scrypt----------> Key material
You want as much distance between the password and the key.
Not-recommended cheat
If you're really desperate to save CPU cycles (and avoid computing scrypt twice), you technically could take:
Key Material ---SHA2---> "hashed password"
And call the hash of the encryption key your "hashed password" and store that. Computation of a single SHA2 is negligible. This is acceptable because the only way an attacker can use this is by trying to guess every possible 256-bit encryption key - which is the problem they can't solve in the first place. There's no way to bruteforce a 256-bit key. And if they were to try to brute-force it, the extra hashed version doesn't help them, as they could just test their attempt by trying to decrypt the private key.
But it's much less desirable because you're storing (a transformed) version of the encryption key. You want that key (and any transformed versions of it) stored as little as possible.
To sum up
generate EC key pair
encryptionKey = scryptDeriveBytes(password, salt, cost, 32)
encryptedPrivateKey = AES256(privateKey, encryptionKey)
passwordHash = scryptHashPassword(password, salt, cost)
and upload
encryptedPrivateKey
passwordhash
I am trying to decrypt a set of files with GnuPG, for which I already have the username and password. However, I cannot seem to be able to do so, even though I have generated a new key with the given credentials. When trying to run
gpg --output result.sc --decrypt myFile.sc.xz.gpg
I get:
gpg: encrypted with RSA key, ID 3662FD5E
gpg: decryption failed: No secret key
I am wondering, which are the steps in decrypting with GnuPG? I followed the instructions here http://linoxide.com/security/gpg-comand-linux-how-to-encrypt-and-decrypt-file/, but still did not get it to work. I have no other key given except for these credentials.
You're missing the private key with 3662FD5E.
I have no other key given except for these credentials.
Without this key, you cannot decrypt the file. The password you have might protect the private key, but without the private key, there's definitely no way to decrypt the file (unless in future, a way is found to crack the encryption, but as of now, pretty much all relevant and actually used algorithms in OpenPGP are believed to be secure).
even though I have generated a new key with the given credentials
Keys are generated from random numbers, you cannot generate the same key again, also when using the same user ID and password.
A client program (over which I have no control) is authenticating by sending me a password, hashed as SHA1(password).
I'm reluctant to store the password hashed using only SHA1 in my database, so I'm proposing to store passwords in the database hashed as SHA256(SHA1(password)) (where the password is hashed over multiple iterations using PBKDF-2 or something similar).
My question is: is there anything insecure about the inner-most hash using SHA1 in this scenario? I realise that the probability of collisions will be increased, but since this is just for storing passwords in the database I don't think I need to be concerned about that. Is there anything else that I'm missing?
Consider adding a salt which is unique-per-row before doing the final encryption. Example:
Lets say that you receive W6ph5Mm5Pz8GgiULbPgzG37mj9g= (a SHA1'd encryption of "password"). That is associated with a User, who should have a unique key, such as a UserID and/or UserName.
My suggestion - to avoid collision - would be to do a conversion of the Bytes to a Base64String (in C# this would be Convert.ToBase64String( byteVariable ) - then concatenate onto the string the user's unique-ID (making the new string something like:
W6ph5Mm5Pz8GgiULbPgzG37mj9g=+103 (where I added +103 to reflect the user's ID) - then apply your SHA256 algorithm. This will produce: mNXRjWsKJ7V+BHbAuwJJ7neGT+V1IrLQSQXmb4Vv1X8= - which you can store in your database. A SHA256 hash - which eliminates the collisions from the less-safe SHA1 algorithm.
And - since you are using 1-way encryption - when you go to check whether the password is valid in the future, you simply append the user's ID again before checking.
If the client always sends you the same password, simply SHA1 hashed, then the SHA1 hash output is the password, to all intents and purposes. Treat it and store it the same way you would any other password, such as by using PBKDF2, SCrypt, or BCrypt.
I have asked a similar question in post Encrypting a file with RSA in Python , but this question has a different connotation.
I am encrypting a file with AES, using RSA to encrypt the AES password.
The only difference is that i really DON'T want to store the AES password. The user must give both the path to his RSA key, and the password.
So what do you think about this scheme?
path_to_RSA_key = ... # Given by the user
pwd = ... # This will be used to encrypt the file. Also given by user.
rsa_enc = RSA.importKey(path_to_RSA_key)
# Encrypt the Password with RSA, keep the last 32 characters
rsa_pwd = rsa_enc.encrypt(pwd)[-32:]
# Aes, with the encrypted password
aes_enc = AES.new(rsa_pwd, AES.MODE_CBC)
# Encrypt the file with AES...
# Store only the encrypted file
# Don't store the password in any way, don't store the path to RSA key
The alternative would be the classic scheme, when you generate a random password, encrypt the file with AES using the random pass, encrypt the random pwd with RSA and store only the encrypted results.
If you really need to know why i need this, it's a project of mine, http://code.google.com/p/scrambled-egg
What do you think about the scheme ? Thank you in advance !
There seems to be some confusion. You mention that you don't want to store the 'password', but you're working with RSA and not a symmetric algorithm. The term 'password' strongly implies a shared secret as used in symmetric encryption, and it appears that you're trying really hard to fit RSA into the mould you've created.
The issue I see is that this functionality may not fit into your planned use very well. Your plan seems focused on symmetric ciphers. Further, using asymmetric keys this way may be a problem. I think asymmetric encryption is used to encrypt nonces for a reason; it may not be robust to attacks that can be waged against a scheme like the one you propose.
Asymmetric keys are often used as follows:
Generate a purely random 32-'character' key and call it "nonce".
Encrypt the message with the "nonce" and call it ciphertext.
Encrypt the "nonce" with your asymmetric key (presumably the public key, but you should specify).
The result consists of the ciphertext and the asymmetrically encrypted "nonce".
Decrypting requires only the paired opposite of the asymmetric key used to encrypt.
If you're hardcore, you could encrypt (using AES + a password or similar) the public or private key that can be used to decrypt the nonce and send it along for a ride too. Sadly that isn't really increasing security over AES+password, and you are increasing the bloat in your message by a lot.