How does password encryption protect against man in the middle attack?

339 views

So say Eve wants to steal my email account, but I know that so I encrypt my password before sending it in a way that only I and the email provider knows how to decrypt. What prevents Eve from just copying all the bytes I send and send them as they are to login?

In: 18

6 Answers

Anonymous 0 Comments

You’re right – this is called a [replay attack](https://en.wikipedia.org/wiki/Replay_attack) and there are ways to protect against it.

One way is to add a random factor. The server sends you a random string, and you add it to the password before encrypting (or simply hashing). The next time Eve tries to login with your username, the server will send her a different random string, so she can’t just use the same bytes that you sent.

Anonymous 0 Comments

So… when encrypting, there’s other things going on to address exactly what you’re worried about. One is what’s called chaining. It adds the previous text into the next encrypted block, so you have to successfully decrypt the previous piece to decrypt the next piece. Then you start the process off by sending a random number that’s just there to fix this problem. Since you have to unwrap the previous random number to get the chaining correct, it prevents that problem.

You’re correct about that being a problem, and it’s a huge problem. Any crypto system you build needs to change constantly so you don’t detect patterns in the codes.

Anonymous 0 Comments

Diffie Hellman key exchange is very clear that you could. But you need to do a lot of calculations to do so. It just gets too expensive.

Textbook are using colour mixing as an example. It is easy to mix colours, but very hard to unmix them.

Anonymous 0 Comments

Nothing prevents it. That’s why you shouldn’t do that.

Passwords should instead be transmitted over a secured channel (such as TLS) to prevent MitM, and then compared to a stored hash using a secure password-hashing algorithm.

TLS involves per-session keys and a stream cypher, so simply repeating the same encrypted bytes doesn’t work.

Anonymous 0 Comments

I know OP didn’t mention hashing in particular but since the post is about “password encryption” and the only thing that makes passwords any different in this regard is hashing I’ll start there.
Password hashing should actually be done server side instead of client side because anything client side can be compromised since you don’t control the machine, and it’s very important that the password being stored is the hashed value so that if anyone looks in the database or whatever is storing password hashes they don’t know the password values that generated those hashes.

This means password hashing can not protect against man in the middle attacks because it doesn’t even happen until after it’s transmitted to the server. Until then the password is protected through the same encryption that protects the rest of the request content

However the request itself will have encryption so that things like the password and other request details can’t be seen. If an attacker tries to send the exact same request later it won’t be valid anymore because an important secondary input to the encryption (and decryption) algorithm will have changed.

Anonymous 0 Comments

When passwords are encrypted they are typically hashed. This means they are converted in a way that’s easy to do in a repeatable fashion, but very difficult to undo. This used to be safe but computers are powerful enough to break hashes with ease nowadays.

Sending over a hashed password doesn’t help, since the hashed password essentially becomes the password itself, and can be stolen in the way you’ve described.

The solution is to “salt” the hashed password before transmitting it. The salt is just some random number or characters, but it is applied to the password before hashing in some way. Maybe added to the start/end of the password, or scattered throughout. This way when the password is hashed, the hashed password is no longer your password but a new completely random word.

Your PC can send the hashed password and salt together to the server, and as long as the server knows how to use the salt against the password it can verify your login, however a man in the middle won’t know how to apply the salt and it will be useless to them.