# Tag Info

## Hot answers tagged passwords

110

In short, it is more than a belief: there is strong evidence that humans are not good entropy sources. There is a test for this Man vs. Machine. Or, why Man is not a Particularly Good Source of Entropy. Try to win! So we don't rely on whether generating a random number from the mind or random keyboard typings and mouse movements that seem like a monkey ...

74

"lucky" is not a property of the attacker. There's no "lucky" attacker nor "normal" attacker. They both have the same probability (low, very low) to guess the key. You can decrease the probability at will by increasing the length of the key (i.e. the no. of bits). You cannot really argue "what if the attacker is lucky" because "being lucky" is a posteriori ...

42

Note: This answer assumes that by "lucky" OP meant "able to remove X% of valid answers", because I believe that was intent. Of course you can't measure luck ;) And if he is very lucky, say 90% chance, that means that 1 bit is actually only 0.1 bit.So in face of a very lucky opponent, a 128 bit password has only 12.8 bit strength. Well, let's validate ...

31

For me, the fraud-related applications of Benford's Law come to mind. When people make up data they tend to create overly uniform data, even when it's not appropriate. There's a definite psychology going on that may cause people to be less random than they are intending to be (Wikipedia links to a paper claiming humans are in fact bad at this). Or perhaps ...

27

If we take two password strings of different length and attempt to bruteforce match them, it is obvious that the longer one will take longer to crack on average. Actually, that might be obvious to you, but it's not true. A brute force search is one where an attacker has a long list of passwords, and tries them in succession. Now, if the attacker is at all ...

25

So if at each bit he has a 50% chance, that means that 1 bit is actually only half bit. And if he is very lucky, say 90% chance, that means that 1 bit is actually only 0.1 bit.So in face of a very lucky opponent, a 128 bit password has only 12.8 bit strength. You're miscomputing how "luck" affects the number of bits. For a 50% chance, that does ...

24

I'm wondering what the recommended number of iterations would be? Unlike bcrypt or traditional crypt, argon2 does not have a single iteration count, but three parameters affecting the computational cost: Number of iterations $t$, affecting the time cost. Size of memory used $m$, affecting the memory cost. Number of threads $h$, affecting the degree of ...

24

If a computer is doing the selection of PIN numbers, then you would be very lucky indeed to guess a PIN in three times. The entropy - assuming that all numbers are valid - is of course $\log_2{10^8} \approx 26.57$ bits. The chances of guessing the PIN correctly in 3 tries is 1 - \frac{x-1}{x} \cdot \frac{x - 2}{x-1} \cdot \frac{x-3}{x-2} = 1 - \frac{x-3}{...

23

If the attacker had already begun creating a rainbow table or is engaged in some other attack which requires knowledge of the salt, then a password change with a salt change will require the attacker to start from scratch. Always assume the attacker has before and after copies of the password hash and salt. If the salt is not changed, any work the attacker ...

23

I don't get nearly the amount of entropy stated in the comic. Interestingly enough the reasoning for the entropy rating are actually justified in the comic by the little boxes which each represent 1 bit of uncertainty. This means for Tr0ub4dor&3 It's estimatated that the word itself "Troubador" comes up in dictionaries which contain about $2^{16}$ ...

22

SHA-1 in itself was never safe for password hashing. The hash algorithm itself doesn't have a work factor parameter nor does it have a salt as input. These are requirements for run-of-the-mill passwords that do not have as much security as a good symmetric key. For this reason password hash algorithms have been invented, also known as password based key ...

21

I fail to see why one would want to use classical or pencil and paper tools for derivation. For anyone attacking your technique it will make no difference. An attacker with a modern computer will only brute force the part you memorized. Any key stretching done on pencil and paper will be a minor nuisance at best; anything done on paper will add no time at ...

20

A key is derived from the password using a Password Based Key Derivation Function, in this case PBKDF2: Key = PBKDF2(HMAC−SHA1, passphrase, ssid, 4096, 256) PBKDF2 in turn is described by PKCS#5. These RSA cryptographic standards in turn are made available through RFC's nowadays, in this case RFC 2898: PKCS #5: Password-Based Cryptography Specification ...

19

There's a 2013 article in Ars Technica that refutes the notion that long passwords are necessarily hard to crack. It details how security researchers Kevin Young and Josh Dustin turned to text from Wikipedia and Project Gutenberg as a seed to come up with longer and longer phrases to try in their password crackers, and managed to crack some impressively ...

18

The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key". In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily ...

18

This is called Client-Independent Update, according to the Catena paper. It is desirable to be able to compute a new password hash (with some higher security parameter) from the old one (with the old and weaker security parameter), without having to involve user interaction, i.e., without having to know the password. We call this feature a client-...

18

Why would a dice rolled be "more random" than simply coming up with a sequence in your head, and then changing some of them? Humans have too many biases regarding what a random sequence is. If you ask humans to generate a random sequence, they will probably pay attention not to use the same character in a row, i.e., aa or bb, as they think that ab ...

18

You should not be hashing it before passing to bcrypt, which is designed to do the hashing and key-stretching work itself. It's choking on the hash result because it's expecting a redundant, mushy, ASCII (or UTF-8), not-rigorous, user-entered string. Generally speaking, hashing things that might be untrustworthy is good to avoid various numeric ...

17

Can you help me understand what a cryptographic “salt” is? In the context of password creation, a "salt" is data (random or otherwise) added to a hash function in order to make the hashed output of a password harder to crack. When might I need to use it? Always. Why should or should I not use it? You should always use a salt value with your hash ...

17

There are a number of considerations here, I'll try to lay them out one at a time for ease of following: What must the site do with the data? Oftentimes, we ask web sites to do things on our behalf when we are not actually visiting them. For example, I may want crypto.SE to email me when there are responses to this post. The site could not do that ...

16

Though quantum computers fit the requirements, I'm not sure they are the best option. A general purpose quantum computer capable of attacking modern encryption (RSA, AES) would have serious ramifications on society. It's not only applicable to this one cipher you are breaking. Does it have to be the superior computing resources which gives the good guys the ...

15

Multiple hashing, in itself, is not a bad idea. What's bad is trying to design your own non-standard password hashing scheme, without understanding what features such a scheme needs in order to be secure. In fact, hashing the password many times can be a very good idea, as long as you do it sufficiently many times. This is one way to slow down the hashing ...

15

There is no timing attack possible on MD5 as practically implemented on most platforms. That's because MD5 uses only 32-bit addition, 32-bit bitwise boolean operators, and constant rotations/shifts, which exhibit no data-dependent timing for any reasonable implementation, even written without consideration for resistance to timing attacks. There is however ...

15

I'm not sure what you're trying to understand and if the other answers cover it, so I'm trying a different approach and interpret your question like this: What if an attacker guesses the right sequence of 128 bits on her first try by pure chance? That's certainly possible but so unlikely that we don't normally consider that possibility. If you want to ...

15

Randomness is a measurable, statistical property of a set of values. It doesn't mean the same as "hard for a human to guess." Your sample string is hard for a human to guess, but it isn't very random. There is a tool called "ent" for most Unix systems that can quantify the randomness, by some measures, of a file. Available here: https://...

14

They are both equal. Passphrase security is based on the amount of entropy that the passphrase contains. In your case, both of your pieces of data are only different in the encoding. The actual entropy that they contain is the same. You are generating a secret that is (assuming that the random source is really random) 16 bytes long. So it has 128 bits of ...

14

People are not that bad, but we're slow. See How were one-time pads and keys historically generated? In summary, MB's of 100% secure key material were generated for one time pads by people simply key smashing on type writers. Sufficient to win three world wars. It's just that a human's entropy rate is a little lower than a laser phase based TRNG. ...

13

I know that humans would find it impossible to maintain a 128 bit password -- however, I wonder if there is some technical reason why a 52 bit password would not be as weak as a 52-bit encryption key for that matter. First, I would argue that 128 bits is not impossible to remember. My current password manager master password is almost 100 bits (6 words from ...

12

Short answer: don't. Use a password hash like PBKDF2, scrypt or bcrypt. Also, if at all possible, use a library that takes care of the low level stuff like password database for you. E.g. passlib might work if you use Python. I'm sorry if that sounds blunt, but that's how it is. To answer your actual questions: There is just only one thing which bothers ...

12

Using several different encryption algorithms, and not disclosing which is used in each particular case would require password verification to try all possible algorithms. Feasible only when using just a few algorithms. Truecrypt does this, for example. This could strengthen security, when implemented properly - but it is much more difficult to implement. ...

Only top voted, non community-wiki answers of a minimum length are eligible