Why isn't this a huge flaw in encryption? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist

Closed 8 years ago.

Improve this question

I don't understand encryption very well at all; in the past I've just trusted it, but if I'm writing a web application that will go online I think I should try to understand it better.

Here's my question:

Suppose I'm asked to type in my password to log in on any website. The password, or some function of it, must then be sent to the server so that the server can compare it to the encrypted password stored there.

Either the password is sent in plain text, in which case (I think) it isn't secure as somebody could intercept and read it (which is a Bad Thing), or it's sent in it's encrypted format, in which case somebody could intercept that and, even if they can't read the password, they could then pretend to be you by sending the encrypted string to the site, which wouldn't know any better. Similarly if the hacker gets a copy of the database, he would just be able to send of the encrypted password and gain privileges. This is also a Bad Thing.

Answer 1

You need to read up on

• HTTPS/SSL
• password hashing

The issues you mention have been thought of and addressed.

Either the password is sent in plain text

It's not. It is sent via HTTPS, meaning encrypted.

or it's sent in it's encrypted format, in which case somebody could intercept that and, even if they can't read the password, they could then pretend to be you by sending the encrypted string to the site.

No. HTTPS sessions cannot just be hijacked like that. There is a shared secret key being negotiated between the two parties, and you cannot just intercept and replay. The server issues challenges that a man-in-the-middle cannot reply to convincingly.

Note that this depends on the public-key infrastructure, though, meaning trusted certificate chains. If someone can fake an SSL certificate (or make you accept a self-signed one), you cannot be sure who you are talking to. Then, man-in-the-middle is possible.

Similarly if the hacker gets a copy of the database, he would just be able to send of the encrypted password and gain privileges.

Yes, if the hacker gets a copy of the database, that is a problem.

Sending an encrypted password however is useless. Password checks work by sending the "raw" password (over an encrypted connection), and then comparing it against a hash stored in the database.

What a hacker would do if he got the database is try to brute-force (guess) the passwords locally, and if he is lucky, he can then log in as the user. Fortunately, if the passwords are long and random, and they have been properly hashed and salted, this process still takes a long time. No longer long enough to be completely safe from cracking, but still long enough for you to change your passwords.