Hot answers tagged hash
45
You have a fundamental misconception of how rainbow tables work.
A rainbow table or a hash table is built by an attacker prior to an attack. Say I build a hash table containing all the hashes of strings below 7 characters for MD5. If I compromise your database and obtain list of hashes, all I have to do is lookup the hash on the table to obtain your ...
28
A rainbow table is an optimization for reversing hashes by brute force. It works by a trade-off: you do a lot of precomputation to build a huge data structure, and you can then crack many hashes quickly.
A rainbow table only helps the crack hashes in the search space that it covers. Concretely, rainbow tables are built for plaintexts made of printable ...
14
You are fundamentally correct that it is just making the password longer but there are some additional things that it does add. Also the average password is not that long or secure and adding length "for free" is rarely bad. The salt makes it so that an attacker can't hash "password" once and then look for every user that has a password of "password".
...
8
A unique salt solves one problem -- every account can't be attacked simultaneously in one giant brute-force attempt.
Let's say you tried building a rainbow table of all printable ASCII passwords that were 8 characters long1. That's 968 ~ 7.2 million billion (7.2 x 1015) possibilities. If you had a GPU that generates passwords at a billion per second, that ...
6
Execution time in bcrypt does not depend on the input size; internally, the input string is padded into a fixed-length sequence of bytes, and that sequence is then used throughout the algorithm.
It would be a problem if execution time depended on input size, because the "cost factor" parameter is adjusted to make the execution time as high as is tolerable. ...
6
Rfc2898DeriveBytes implements PBKDF2: a function which turns a password (with a salt) into an arbitrary-length sequence of bytes. PBKDF2 is often used for password hashing (i.e. to compute and store a value which is sufficient to verify a password) because it has the needed characteristics for password hashing functions: a salt and configurable slowness.
...
5
Nope because you run it in memory not from the hard drive.
The only form of hash cracking I know so far which uses a hard drive, are table lookups like Rainbowtables. Even in that case the benefit of an SSD is limited since it's read in sequentially. SSDs are good for random reads and writes.
5
A salt is a cryptographically-secure random non-repeating value, added to the password before hashing it, rendering rainbow tables useless and making it impossible to attack more than one password by attacking one hash.
An initialization vector (IV) is a cryptographically-secure random non-repeating value added as the initial state to a block cipher ...
5
The method you describe is indeed a classic algorithm for one-time passwords, but it has some drawbacks:
It is good only for N passwords, where N must be chosen at initialization time.
The client must invoke the hash function R times, where R is the number of remaining passwords in the chain, i.e. initially R = N. This limits the size of N, otherwise the ...
5
Though SHA-256 nominally offers a 256-bit output, no weakness about it is known when the output is truncated to 128 bits, except, of course, weaknesses inherent to the shorter output length; e.g. collision resistance drops from the infeasible 2128 to the possible (but hard) 264.
This is not a generic property of hash functions(*), but it is somewhat ...
5
Proper cryptographic hash functions are all-or-nothing: you either get the exact correct input, to the last bit, or you get nothing. No patterns, no partial solving, no Mastermind-like cracking. That's why it is called brute force: there is no finesse whatsoever in password cracking.
Being able to solve passwords "partially" only happens in Hollywood ...
5
The "1000" factors cancel out. By making collisions much probable so that each password has on average 999 brother passwords which equally grant access to site A, you make entering site A 1000 times easier. Due to the vast choice of possible passwords, that "easy-site-A" password has only 1/1000 probability of being good for site B (where the user reused his ...
4
The relevant principle here is the birthday attack. It roughly states that for a 2n algorithm, your probably of a random collision is between any two items is 50% once you generate 2(n/2) outputs.
When looking at a hashing algorithm, the naive consideration of the algorithm is that the odds are bassed only on the last iteration. In this way, a 128 bit ...
4
The SHA2 family is not a good choice for password storage. It is significantly better than md5, but really you should be using bcrypt (or scrypt!).
RNGCryptoServiceProvider is a good source of entropy. Ideally a salt is not base 64, but base 256, as in an entire byte. To understand this better, you need to know how rainbow tables are generated. The ...
3
It depends. If you're using a proper KDF such as PBKDF2 or bcrypt, then there's no benefit whatsoever.
If you're using a simple cryptographic hash function that suffers from length extension attacks (e.g. MD5 or SHA-1) then it may help reduce your susceptibility to such issues. However, at that point, you've got bigger problems.
3
Rainbow tables are precomputed hash tables which are used to crack the passwords in a relatively quicker time because looking up a table is much faster than calculating a hash.
if one can find the hashed passwords one should be able to find the corresponding salts
The salt known to the attacker will not create a big problem if the attacker is trying to ...
3
The point of a salt is that it is unique, so that an attacker who wants to crack multiple hashes has to do all the work afresh for each hash. If you include a characteristic that is derived from the password, it doesn't help the salt. It doesn't hurt, either, but it doesn't strengthen the salt in any way.
In effect, by taking hash(password+length+salt) ...
3
You can speed it up, but not with an SSD or a hard drive.
The fastest calculations today are done with video cards and GPU programming. So if you get a cheap video card and run Cuda or OpenCL you can get quite a lot of performance.
That being said GPU processing vs regular processing have similar limitations when using scrypt because the most efficient way ...
3
In this example, the server code looks like this:
Incoming value is "X|Y" -> split between "X" and "Y"
Compute id = Un-Base64(X)
Compute h = SHA-1(secret_key + id)
If the hexadecimal value of h is not equal to Y, then deny access
id is "user|role" with "role" being either 0 or 1; so, if id ends with "|0",
grant administrator access.
secret_key, of ...
3
For John the Ripper, @dr jimbob gave you the information: see the benchmarks page and use the --test command-line flag to make your own measures.
For rcracki-mt, the situation is a bit different. This uses a rainbow table which is a specific kind of look-up table containing, in a size-optimized structure, a lot of precomputed password hashes. Thus, the ...
2
Basic rules:
Code with "admin privileges" can do everything it wishes with your machine. You cannot protect against it. At best, the malicious code will have to wait for the next time you type your password, at which point it will plunder your private key (and all your secrets).
The same "admin exploit" will modify your icon overlays so as to hide any ...
2
Remember combination locks?
With combination locks, assuming they don't suffer a major design flaw and the attacker doesn't posses x-ray vision, is impossible to determine if the tried combination is a partial match to the preset unlock combination. The other lock rings that aren't in their unlocked position will prevent you to unlock all of it, but you ...
2
What you're describing sounds vaguely similar in it's aims to the one-time password scheme, HOTP.
However, after many thousands of logins, my login attempt under your scheme consumes more CPU time than the first login I attempted. With HOTP, the time to attempt login is constant.
It is also the case with this scheme that I cannot protect the secret on the ...
2
A salt has absolutely no benefit for encryption. If anything, it could (though it shouldn't) make the encryption less secure. If it turns out that a known plaintext attack is found (an attack that allows information to be gained from a cypher text about the key by knowing part of the plain text) then having a public value encrypted would make every message ...
1
The output of a good hash should be unrelated to the input, thus no additional randomness should be achieved by factoring in the length. The point of the salt isn't to make the hash more unique so much as it is to prevent the possibility of precalculating tables. Since the length of a password being guessed is known, it doesn't add any protection against ...
1
I don't see any advantage at all (though no disadvantages either). The purpose of salting is to thwart precomputed hash tables/rainbow tables, forcing the attacker to brute force your hashes instead. If you add an easily computable property of the password in the hashing process, the attacker will just have to do the same as well (for each guessing attempt), ...
1
There are a couple of factors involved in salting, and you're missing (at least) one of those.
They make rainbow tables useless. If someone looks in your password database and sees that a password is "5f4dcc3b5aa765d61d8327deb882cf99," they don't even need to build a "rainbow table," they can just google for that value and google will tell them that it's ...
1
Firstly, why are you implementing low-level crypto code for a web page? You'd think this is a solved problem: you use a framework which uses libraries.
Secondly, the hash protect the passwords in case that the hashes leak out. Your site does not provide access to the password database, so this situation should ideally not even arise. The salts help to ...
1
Firstly, the system is complicated and brings up other issues: Does the user have to remember how many times he logged in? If not, who does? Not his browser, he should be able to log in from anywhere.
Secondly, any form of client side encryption in HTTP connections is useless. A man in the middle can easily modify the javascript, remove the hashing ...
1
Not really. This does protect you from client side brute forcing, but opens you up to DoS-like attacks.
The flaw here is that when someone is attempting to brute force a password, the CPU power they use is yours, not theirs. Which means that your system can be brought down on its knees much faster by a distributed brute force attack. Especially since ...
Only top voted, non community-wiki answers of a minimum length are eligible
