# Tag Info

2

So your idea is to effectively turn the password authentication into a key-based authentication by deriving the machine passwords from a single random key stored elsewhere. Assuming key storage is secure (probably encrypted with a strong password), this is sound. It would be better to just use the asymmetric key-based authentication built into most remote ...

1

No it isn't a good way of salting and it isn't the standard way either. There is no reason or benefit to store the salt before it is used. The point of salt is just to prevent parallel and precomputation attacks. Storing it ahead of time means in an undetected compromise the attacker would learn of 'future salts' which undermine the precomputation ...

1

Assuming you're actually asking wether there is a difference for TLS in between a (high-entropy) pre-shared key (PSK) and a (low-entropy) pre-shared password, the short answer is: No. The long answer, however is a bit more complicated. By itself the TLS-PSK ciphersuites don't differentiate between different degrees of entropy. However there are a few ...

5

As Gerald Davis explained in the other answer, there are about 6 million possible passwords, which is way too few. However, there's an additional weakness: since the password and salt are combined with XOR rather than concatenation, it is sufficient to generate a table for all hash values. If you know the $x$ for which $H(x) = h$, you know that the password ...

6

Possible password search space = $36^5$ = 6.05 million possible combinations or ~$2^{26}$. If the passwords were randomly generated it would be 26 bits of entropy which isn't just weak it is pointless. To put that into perspective the throughput on modern GPUs is on the order 1 billion SHA-256 hashes per second. So the exhaustive search time to break an ...

1

KDFs like PBKDF2 are a work multiplier but they can't get blood from a stone. A PBKDF2 using 10,000 rounds "slows" the attacker down by requiring each "guess" to take 10,000 hashes instead of 1. The problem is that passwords like the ones you described are so weak a 10,000x increase in cracking time is like going from 1 ms to 10 seconds. It really isn't ...

4

Would this help preventing brute force attacks? It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000. Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely ...

2

When you change your password you are required enter your both old password and new password in clear text, so they can be compared against each other for similarities. Once this test passes, you encrypt the old password and check it against its stored hash etc.

2

Essentially, instead of checking against a (salted) hash of a password, you suggest using the hash (since you can choose hashing = keygen) as a key to encrypt a kind of test value. The main question is whether this adds or reduces security. If you store the hash/key directly, the chance of a randomly chosen password hashing to the same value is $2^{-n}$, ...

0

Your proposal is not good. First, the checking procedure is wrong: Checking password validity: calculating test_hash=cipher(test_password+salt) for a given test_key=keygen(test_password+salt) check if test_hash consisting only symbols/bytes of predefined dictionary (...) I guess you meant: calculating test_phrase=decipher(hash) with ...

1

Regarding your comment "Would the database need to be compromised for a dictionary attack to be useful?" The answer is no. A dictionary attack would require a username/email (which might either be known or could come from a small dictionary) and then trying words from the dictionary. This is attempting to get in via your normal logic prompt logic. A simple ...

0

I think the idea is good - it is pretty much what Lastpass does (see below). But as with anything to do with cryptography every detail matters. If you're using email for the client salt it seems like a good idea to run the email through PBKDF2 first to ensure sufficient entropy. encryption_key = PBKDF2(HMAC-SHA256, password, client-salt, rounds) // decrypts ...

0

Just to make sure I'm on the same page about the details: So, there's a master key, presumably randomly generated in the client, never shown to the server, call it $k_m$. Then there's an encryption key, derived from a user passphrase and a (random) salt: $$k_e = \operatorname{PBKDF2}(p, s)$$ There's also an authentication key, derived from the same ...

1

This is far from secure, assuming a passphrase that a human can remember. The main thing you have to note is that an offline brute force attack on the password can be carried out. This is because the server can guess the password and follow the same procedure and see if decryption works. It is possible to buy a machine that computes billions of hashes a ...

2

The easiest passwords to guess will always be vulnerable to guessing attacks. If you're intending to identify easy passwords, you should tell your user not to use those passwords.

11

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. ...

7

The best practice for protecting passwords is to first concatenate (public) random salt and then iteratively hash. This prevents constructing a static dictionary like you mention, and also prevents Hellman time-space tradeoffs (and extensions like Rainbow tables).

2

This approach would constitute security through obscurity, which is not recommended to be relied upon. Enhancing security by design would be advisable. In this particular case a stricter password policy that requires stronger passwords and possibly making users change password regularly. Multi-factor authentication would typically enhance security even ...

2

No, in general you cannot. WinRAR uses AES (128 or 256 depending on version) for encryption, which does not allow key recovery even with know plaintext and ciphertext. It also uses key stretching to derive the encryption key from a password. The algorithm used is PBKDF2 with a version dependent iteration count. So a key-guessing attack is only possible for ...

Top 50 recent answers are included