Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Any salt at all will obviously help when salting and hashing a user's password. Are there any best practices for how long the salt should be? I'll be storing the salt in my user table, so I would like the best tradeoff between storage size and security. Is a random 10 character salt enough? Or do I need something longer?
Most of these answers are a bit misguided and demonstrate a confusion between salts and cryptographic keys. The purpose of including salts is to modify the function used to hash each user's password so that each stored password hash will have to be attacked individually. The only security requirement is that they are unique per user, there is no benefit in them being unpredictable or difficult to guess.
Salts only need to be long enough so that each user's salt will be unique. Random 64-bit salts are very unlikely to ever repeat even with a billion registered users, so this should be fine. A singly repeated salt is a relatively minor security concern, it allows an attacker to search two accounts at once but in the aggregate won't speed up the search much on the whole database. Even 32-bit salts are acceptable for most purposes, it will in the worst case speed an attacker's search by about 58%. The cost of increasing salts beyond 64 bits isn't high but there is no security reason to do so.
There is some benefit to also using a site-wide salt on top of the per-user salt, this will prevent possible collisions with password hashes stored at other sites, and prevent the use of general-purpose rainbow tables, although even 32 bits of salt is enough to make rainbow tables an impractical attack.
Even simpler-and developers always overlook this-if you have unique user IDs or login names, those serve perfectly fine as a salt. If you do this, you should add a site-wide salt to ensure you don't overlap with users of another system who had the same bright idea.
Currently accepted standards for hashing passwords create a new 16 character long salt for every password and store the salt with the password hash.
Of course proper cryptographic care to create really random salt should be taken.
Edit: My below answer answers the question as asked, but the "real" answer is: just use bcrypt, scrypt, or Argon2. If you're asking questions like this, you're almost certainly using tools at too low a level.
Honestly, there's no defensible reason not to have the salt be the same exact length as the hashed password. If you're using SHA-256, then you have a 256-bit hash. There's no reason not to use a 256-bit salt.
More than 256 bits won't net you any improvement in security, mathematically. But going with a shorter salt may always end up with a situation where a rainbow table catches up to your salt length -- especially with shorter salts.
Wikipedia:
The SHA2-crypt and bcrypt methods—used in Linux, BSD Unixes, and
Solaris—have salts of 128 bits. These larger salt values make
precomputation attacks for almost any length of password infeasible
against these systems for the foreseeable future.
128-bit (16-byte) salt will be enough. You can represent it as a sequence of 128 / 4 = 32 hexadecimal digits.
One answer might be to use as size of salt the value that the hash you are going to use provides in term of security.
E.g. If you are going to use SHA-512 use 256 bit salt since the security provided by SHA-512 is 256 bit.
Related
This question already has answers here:
Is it possible to decrypt MD5 hashes?
(24 answers)
Closed 5 years ago.
ร encodes into 0f93821e0fbc6d3736da7df2c73024aa
I was wondering if it's possible to decode the hash back into the unicode form. If so, how can I approach this or how can I perform this.
Any help is appreciated, thanks.
m5d is a hashing algorithm, that is by nature monodirectional.
You just can't "decode" it.
The only option you have is bruteforcing.
The whole point of a hash is to present a fixed-length output for arbitrary input with the property that the same input results in the same output. Cryptographic hash functions like MD5, or SHA-1 are even designed so they cannot be reversed easily. Thus, no, you cannot do that.
Also, just as a thought exercise that shows that in the general case it just cannot work: MD5 is 128 bits long, so how could you possibly recover input that's larger than that? There are an infinite number of strings turning into the same digest, so while you could find a string that has the same hash, you're not guaranteed to find the one you started with.
Whites11 has mentioned brute-forcing, however take into account this is not 'Decoding' the hash. This is simply hashing common inputs and comparing the 2 hashes to see if they match, unless you have a set of common inputs that may actually match the hash its very unlikely you will get anywhere with it.
Hashes are intentionally mono-directional, I can't think of why you would need to either you may need to rethink the logic of whatever project you're doing.
To summarize, you can't decode a hash, this is intentional and that's why hashing algorithms exist. And brute-forcing is hashing common inputs to see if they match your hash. It's commonly used for password cracking etc. Done with common password data sets. So may not be useful in your case.
http://www.md5online.org is a good example of bruteforcing, it is a database of previously bruteforce/tested hashes and their unicode inputs. You can try hashing a basic word like "password" and throwing it in there, it should show the original unicode input if it's a known hash!
Here are 2 excellent informative videos that cover hashing algorithms and brute-forcing hashes:
https://www.youtube.com/watch?v=b4b8ktEV4Bg
https://www.youtube.com/watch?v=7U-RbOKanYs
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
Is Serpent-256 better than Rijndael-256 in terms of security? (speed doesn't matter)
Would Serpent encryption combined with SHA-512 be enough to safeguard sensitive data?
And to what extent? (SECRET, TOP SECRET, CLASSIFIED etc.)
Moreover, Rijndael has a max of 16 rounds. Serpent has 32 rounds, so it must be more secure.
As I've read that the Rijndael cipher is cryptographically broken, why isn't Serpent
adopted more widely? Would it be that slow if implemented on hardware?
Any other technical specifications about Serpent that you can link me to, I would be very grateful.
Thank you.
The number of rounds, by itself, doesn't determine the security of a cipher. You need to take the round function into account before the number of rounds means anything.
Nonetheless, I'd agree that there's a pretty decent chance that Serpent is more secure than AES. There are attacks currently known against AES that reduce the complexity by a factor of approximately 4 compared to a pure brute-force attack.
Cryptographers count that as a successful attack--but from a practical viewpoint, it's of precisely zero consequence. Even if you restrict yourself to AES-128, it's basically reducing complexity from 16 times the estimated life of the universe to only 4 times the estimated life of the universe (I'm sort of making up numbers here, but you get the general idea). With AES-256, the number is so much larger the factor of four shrinks to a new level of utterly meaningless insignificance.
Until/unless a dramatically better attack is found, real security is completely unaffected. In essentially every case, the problems you need to deal with and worry about are in how the cipher is used, how keys are generated, stored, and exchanged, etc. Changing from AES to Serpent (or Mars, Twofish, etc.) is extremely unlikely to improve your security (or anybody else's).
I should probably add: I'm probably as strong an advocate as anybody of having more cipher algorithms available and standardized. If you do a little looking, you can find where I'm cited in the papers submitted to NIST during AES standardization on that subject, giving use cases where including more than one algorithm in the standard would have been useful. Nonetheless, I have to admit that no (publicly known) current attack even comes close to giving a real reason to choose a different cipher algorithm.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading up on file encryption lately, and In many places I've seen warnings that encrypted files are susceptible to decryption by people so inclined regardless of encryption algorithm strength.
However, I can't get my head around how someone would go about attempting to decrypt an encrypted file.
For example, lets say you've got an encrypted file and you'd like to know it's contents. You have no idea what the key used to encrypt the file is, nor the encryption algorithm used. What do you do? (Assume for this example that the encryption algorithm is a symmetric-key algorithm such as AES-256, I.E. a file encrypted with key which requires said key to decrypt it).
Additionally, how would your approach change if you knew the encryption algorithm used? (Assume in this case that the encryption algorithm used is AES-256, with a random key + salt).
There's two ways to answer this question, in the literal sense of how a perfect crypto system is attacked, and how real world systems are attacked. One of the biggest problems you'll find as you begin to learn more about cryptography is that selecting algorithms is the easy part. It's how you manage those keys that becomes impossibly difficult.
The way in which you attack the basic primitives depends on the type of algorithm. In the case of data encrypted by symmetric ciphers like AES you use Brute force attacks. That is, you effectively try every key possible, until you find the right one. Unfortunately, barring changes in the laws of physics trying every possible 256-bit key can't be done. From Wikipedia: "A device that could check a billion billion (10^18) AES keys per second would in theory require about 3×10^51 years to exhaust the 256-bit key space"
The problem with your question about coming across a seemingly encrypted file, with no knowledge of the methods used, is that it's a bit of a hard problem known as a Distinguishing Attack. One of the requirements of all modern algorithms is that their output should be indistinguishable from random data. If I encrypt something under both AES and Twofish, and then give you some random data, absent any other information like headers, there's no way for you to tell them apart. That being said....
You asked how knowledge of the algorithm changes the approach. One assumption cryptographers usually make is that knowledge of the algorithm shouldn't affect security at all, it should all depend on the secret key. Usually whatever protocol you're working with will tell you the algorithm specifications. If this wasn't public, interoprobility would be a nightmare. Cipher Suites, for example, are sets of algorithms that protocols like SSL support. NIST FIPS and the NSA Suite B are algorithms that have been standardized by the Federal Government, that most everyone follows.
In practice though, most crypto-systems have much larger problems.
Bad random number generation: Cryptography requires very good, unpredictable random number generators. Bad random number generators can completely collapse security, as in the case of Netscape's SSL implementation. You also have examples like the Debian RNG bug, where a developer changed code to satisfy a memory leak warning, which ultimately led to Debian generating the same certificate keys for every system.
Timing Attacks: Certain operations take longer to execute on a computer than others. Sometimes, attackers can observe this latency and deduce secret values. This has been demonstrated by remotely recovering a server's private key over a local network.
Attacks against the host: One way to attack a cryptosystem is to attack the host. By cooling memory, its contents can be preserved and inspected in a machine you control.
Rubber hose cryptanalysis: Maybe one of the easiest attacks, you threaten the party with physical harm or incarceration unless they reveal the key. There has been a lot of interesting case law on whether or not courts can force you to reveal crypto keys.
AES256 is effectively unbreakable.
From http://www.wilderssecurity.com/showthread.php?t=212324:
I don't think there's any credible speculation that any agency can
break a properly implemented AES. There are no known cryptanalytic
attacks, and actually bruteforcing AES-256 is probably beyond human
capabilities within any of our lifetimes. Let's assume that 56 bit DES
can be bruteforced in 1 sec, which is a ridiculous assumption to begin
with. Then AES-256 would take 2^200 seconds, which is 5 x 10^52 years.
So, you can see that without any known weakness in AES, it would be a
total impossibility within any of our lifetimes, even with quantum
computing. Our sun will explode, approximately 5 billion years from
now, before we obtain enough computing power to bruteforce AES-256
without a known weakness. IF a weakness in AES is never found, there
is absolutely no reason to ever look for another cipher besides AES.
It will suffice for as long as humans occupy the planet.
With basic Brute force attack for example. You ask a software to try every single combination between 1 character to 15 character with a-z A-Z 0-9 and wait.
The software will start with 0 to 10... then 0a, 0b, 0c until it finds the password. Wikipedia will give you more detail.
I partially agree with Andrew and partially with Jeremy.
In the case, if encryption key is generated correctly (random generated or based on complex password, good key derivation function and random salt) then AES256 is effectively unbreakable (as Andrew said)
On other hand, if a key isn't correctly generated. As example, just straight hash of 4 digit's PIN password, brute force could be very efficient.
Regarding "You have no idea what the key used to encrypt the file is, nor the encryption algorithm used. "
In most case, encrypted files has a header or a footer which specify something (an application used to encrypt a file, encryption algorithm or something else).
You can try to figure out algorithm by padding (as example 3DES has padding and AES has different padding)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I think I'm missing something fundamental about password based data encryption.
A tool that cracks password hash based login authentication knows it's found the correct password (or an alternate password that still matches the hash) when it successfully logs in. But how does a tool that cracks file or stream based encryption using a password as the source for a key know when it's successful? It seems to me that different attempted passwords would turn an encrypted source stream into a different set of destination bytes, with a particular password generating the 'correct' set of bytes. I don't understand how a cracking tool would recognize that it had the correct unencrypted set of bytes, stop trying and report 'Cracked!'.
Most of the time the plain text uses a known pattern. If it would be fully randomized then the attacker cannot distinguish between success and failure. It could be that a set of keys may be returned, of which only one is correct. That said, most plain text contains enough information (like a longer piece of English text) to distinguish a correct key from the wrong one.
Furthermore, the encryption mode may leak enough information to distinguish between the plain text and random text. Block cipher modes - such as ECB and CBC - in particular may use some kind of plain text padding. This padding is added before block encryption, and generally contains identifiable information. Take a look at the PKCS#5/7 padding mode for instance.
Note that encryption algorithms themselves are required to even withstand known plain text attacks, so finding the key should be impossible even if you already know what the decrypted text looks like. However, using passwords weakens the amount of valid keys for modern cryptographic ciphers, so the strength of the password is of utmost importance.
I am developing a large application and i need encryption when a data is traveling between two machines in different continents. I have never worked on encryption. I want a simple encryption which can be handled in PHP / Ruby / Python without any dependencies.
So i decided to use HMAC SHA1.
$pad=hash_hmac("sha1","The quick brown....","mykey");
This is what i found out after some research on the internet.
How hard it is to decrypt it if someone doesn't know the key? Also, any alternatives to this?
UPDATE - thanks for all the responses. Problem solved.
It's impossible to decrypt it, even if you know the key. HMAC SHA1 is a keyed hash algorithm, not encryption.
A hash is a cryptographic one-way function that always generates a value of the same length (I think SHA1 is 128-bits) regardless of the length of the input. The point of a hash is that, given the output value, it's computationally infeasible to find an input value to produce that output. A keyed hash is used to prevent rainbow table attacks. Even if you know the key you can't reverse the hash process.
For encryption you want to look at AES.
SHA1 is a one-way-hash function, by definition it is not decryptable by anyone. The question becomes if you have a plaintext T that hashes to H. How hard is it to find another T which also hashes to H.
According to Wikipedia, for SHA1, the best known brute force attack would take 2^51 evlautions to find a plain text that matches.
If you need actual encryption where you can reverse the process, you should take a look at AES256.
See:
http://en.wikipedia.org/wiki/Cryptographic_hash_function
For a general discussion on this.
Like Andrew said SHA1 is an hash algorithm and cannot be used for encryption (since you cannot get back the original value). The digest it produce can be used to validate the integrity of the data.
An HMAC is a construct above an hash algorithm that accept a key. However it's not for meant for encryption (again it can't be decrypted) but it allows you to sign the data, i.e. with the same key you'll be able to ensure the data was not tampered with during it's transfer.
Foe encryption you should look at using AES or, if applicable to your application, HTTPS (which will deal with more issues than you want to know about ;-)
SHA-1 , MD-5 are all one way Hashing algorithms.
They just generate a lengthy string. Each and every string when subjected to these functions will yield you a lengthy string which cannot be retained back.
They are far from encryptions.
If you are looking for encryption algorithms , go for AES (Advanced Encryption Standard) , DES (Data Encryption Standard) Algorithms.
As I say, this is a hash, so not an encryption/decryption problem. If you want to implement a straightforward encryption algorithm, I would recommend looking into XOR encryption. If the key is long enough (longer than the message) and your key sharing policy is suitably secure, this is a one time pad; otherwise, it can potentially be broken using statistical analysis.