I was thinking some time if I should post that question here or at crypto.stackexchange.com. I think the question is more related to implementation than to theory, so here we go:
I have decided to use scrypt as the password hashing method for my future backends. Some of my backends are written in Perl, so I plan to use Crypt::ScryptKDF.
It is quite clear how to use it, but one question is left: scrypt is (to my best knowledge) more a key derivation function than a hashing function. So how is the hashing actually done?
Does it just encrypt the (salted) input string (e.g. a password) with the key which it has derived from the same (salted) input string (password), or is there more to it?
Related
For reference I only know python so that's what I've been working with.
I've recently been looking into making my own hashing algorithm to further my understanding on how they work, I'm not looking into creating the most cryptographically secure hashing algorithm, just something that is a bit more secure than validating passwds in plain-text.(in other words I don't care if this algorithm has copious amounts of collisions.
From what I understand about hash functions is that they use ???? to obfuscate the input password. Where I'm getting caught up is how the function takes a user input, like "password1" and translates that into numbers the system can work with, then, what exact methods do they use to obfuscate them?
Apologies if this is a stupid question but I cant find any material on this that isn't way beyond my understanding or basic enough where they gloss over what happens inside the hash algorithm.
I'm following some python book and the author provides an example of using crypt to produce a hashed password. Using the salt+password; and later he mentioned that the same could be done for sha512 using hashlib library. So I tried to use
hashlib.sha512(password+salt).hexdigest()
to see if I could come up with my same password in the /etc/shadow file, but I'm not getting anything remotely similar. I'm using the salt that shows as part of my password hash. Am I doing it correctly, or that salt needs to be in ascii form? Also does the salt goes first and then the password like hashlib.sha512(salt+password).hexdigest()? the rest of my code is pretty simple. It is that part about finding the salt, and hashing it properly. nagios:$6$P9zn0KwR$tgfvvFWJJ5FKmoXiP5rXWOjwoEBOEoAuBi3EphRbJqqjWYvhEM2wa67L9XgQ7W591FxUNklkDIQsk4kij uhE50:16632:0:99999:7:::
for example the salt I'm using is "P9zn0KwR" is this correct or I need to find the clear text for that salt... thanks
Using hash algorithms like MD5 or SHA-* is an unsecure way to store passwords, because they are ways too fast and therefore can be brute-forced too easily.
Have a look at the Phyton docs, the part about key stretching. It seems that they implemented the PBKDF2 for passwords which is recommended. The passlib seems to be a good choice too, they support the BCrypt algorithm.
Since SHA-3 seems to be an already known function (Keccak as the finalist of NIST hash function competition) I have several questions related to this topic:
NIST site says that NIST is closed due to a lapse in government funding. Is there any chance that SHA-3 will ever be finally accepted?
BouncyCastle library has an implementation of SHA-3 which digest results are the same as examples posted in wikipedia article (I tested this). Since the final standard is not approved, can this be trusted? Wikipedia says this is likely to be changed but how can it change as the final algorithm does not seem to be a subject to change (or else it would be another algorithm).
Here someone noted that usage of PBKDF2 with SHA-3 for key strengthening and password hashing should be avoided. But I cannot understand why? (how can it give attacker an advantage if the algorithm is not fast?)
I could not find test vectors anywhere to test my implementation of PBKDF2-HMAC-SHA3 in scala based on BouncyCastle java api. I can post my test spec with some results. But first can anybody post any/spec test vectors?
Here is my implementation in scala:
package my.crypto
import org.bouncycastle.crypto.digests.SHA3Digest
import org.bouncycastle.crypto.generators.PKCS5S2ParametersGenerator
import org.bouncycastle.crypto.PBEParametersGenerator
import org.bouncycastle.crypto.params.KeyParameter
object PBKDF2WithHmacSHA3 {
def apply(password: String, salt: Array[Byte], iterations: Int = 65536, keyLen: Int = 256): Array[Byte] = {
val generator = new PKCS5S2ParametersGenerator(new SHA3Digest(256))
generator.init(
PBEParametersGenerator.PKCS5PasswordToUTF8Bytes(password.toCharArray),
salt,
iterations
)
val key = generator.generateDerivedMacParameters(keyLen).asInstanceOf[KeyParameter]
key.getKey
}
}
One questionable thing for me is new SHA3Digest(256), the 256 bit length in the constructor, should it be same as provided key length or some fixed one as I did? I decided to use a fixed length because only some fixed values can be used and object API user can provide any value as key length parameter, but most of uncommon ones would result in exception thrown from inside SHA3Digest constructor. Also the default value seem to be 288 (when no key length is provided) which looks strange.
Thanks in advance!
Shutdown is temporary. SHA-3 will most likely be standardized at some point in 2014.
No, those values are probably for Final Round Keccak, not for SHA-3. There is no SHA-3 spec yet and it's quite likely that SHA-3 will be tweaked before standardization.
=> it's impossible to implement SHA-3 now, you can only implement Keccak.
Password hashes should be as expensive as possible for the attacker. The attacker uses different hardware from the defender, at minimum a GPU, but possible even custom chips.
The defender has a limited time budged for a hash (e.g. 100ms) and wants a function that's as expensive as possible for the attacker given that constraint. This means that custom hardware shouldn't gain a big advantage over a standard computer. So it's preferable to use a software friendly hash, but Keccak is relatively hardware friendly.
SHA-1 and SHA-2 are decent in hardware as well, so in practice the difference is small compared to the advantage other password hashes have over PBKDF2-HMAC-SHA-x. If you care about security instead of standard conformance, I recommend scrypt.
Let me describe the scenario:
I know the hashed string, and the $salt, but not the $pass. md5 format is:
md5($salt.$pass)
example value = ae10f955a7164ba6905919e7798284ca
here $salt = q)SDs
$pass is unknown.
Now, is there anyway to get md5($pass)?
Short of brute force techniques, no. However brute force is a valid approach. Depending on the scope of this problem, you have a few options:
Write a small program to compute MD5 hashes of md5(salt + random string).
Use an existing cracking tool like John the ripper.
Build a rainbow table using the salt, and then use that to find the appropriate password.
A tool like John the Ripper may be the easiest place to start.
While it is possible to recreate the password using a variety of methods, it's really not the purpose of the hash. The hash is supposed to encode the string in question in an irreversible way, so people who somehow get a hold of the hash cannot just reverse the encryption and have the password in their hands.
So no, it really isn't possible...at least not in any easy way.
I have a NSString like #"123456". I want to convert this string into byte array and then I want to shift some bytes using some arithmetic operations. Then I want to apply SHA256Hash on that and finally want to encrypt a string using the final result. I have tried many approaches but still got no success. I am very confused in this.If someone wants to look at code i'll post the code.
Edit:
My actual goal is to encrypt an string using AES256 encryption algorithm. And I want to generate my own key and I want to pass my own IV.
I assume you're trying achieve some kind of security. On the other hand it does not look like you're very familiar with the tools and methods you're using. This is a bad start.
Security is a very difficult thing to do—even for experienced developers. Maybe there's a way to reuse some existing implementation for your security needs.
My advice would be not to reinvent things, especially when they are as hard and as crucial as security.