Is using HTTPS enough to protect a login area?

Asked

Viewed 207 times

4

Considering a system in which you have the correct server-side treatments, validations and protected against SQL, XSS and brute force attacks, it would be sufficient just forward the login area to the HTTPS protocol or should change something in the code so I can use HTTPS resources?

My intention is protect against possible password interception, because only her hash is generated on the server side.

security-guard
  • 1

    Most effective MITM defenses can only be found on the router or server side.

  • 1

    What exactly is your question? You say the system has the correct treatments, then ask if you should forward the login area to the HTTPS protocol or change something in the code. Exemplify what you want. What language, what ecosystem is this login?

  • My intention is to protect against a possible password interception, because only her hash is generated on the server side.

  • What language are you using

  • It would be something more conceptual, I want to know if HTTPS is enough to protect from a possible password interception, independent of the language, and yes of what is sent by POST to the server. If by doing this, someone could access this information even if they were using HTTPS. The question of whether I should change the code refers to the use of the HTTPS protocol and not logical in sending. To be as straightforward as possible, to use the HTTPS features just be HTTPS in the address bar? Do you understand? PS: I’m using PHP.

  • Https is one of the most widely used concepts in web security. It is not 100%, but it helps a lot, you can seek more security using other resources, but https can not miss.

  • 1

    Look at this excellent reply by @jsbueno for a question as interesting as your.

Show 2 more comments

1 answer

10


HTTPS is the HTTP protocol over the SSL/TLS protocol. The function of SSL/TLS is to create a secure communications channel by which all client/server communication will be made. This means that:

  • Regardless of the server used, language, etc., if the channel is successfully established the communication will be confidential (no one in between can read it), righteous (no one in the middle can change it) and authentic (at the other end will be the right server, not a fake server).
    • That is, there is no need to change anything in the code to use the HTTPS resources, because the protection occurs in the transport layer and not in the application layer.
  • Data only in transit are protected - if there is for example malware on the client or server, or if one or the other is invaded by attackers, they could potentially read/change the data as they depart/arrive in flat format.

In particular pro HTTPS, we have that some data are public by necessity of the protocol itself (e.g., the URL/IP, because we need to know to where send each package), but all others are private (including query strings, the data passed via POST, and the whole content of the body of the response).

For an overview of the protocol, I suggest the question "How HTTPS (SSL) works?". At the beginning of the answer I said that "if the channel is established successfully..." and in fact it is very important to be aware of preconditions for this to occur, which may require some additional configuration on your server. In particular:

  • Always use a valid safety certificate: acquired from a trusted Certification Authority by the browsers, within the validity, and whose private key was generated by you and always kept confidential. Without this, the authenticity communication could be compromised.

  • Only enable on your server secure encryption suites. It is very common to setup default of multiple servers accepting weak algorithms if the client does not support the strongest. And a weak protocol could potentially be exploited and compromise confidentiality and integrity of communication.

    How to properly configure varies from server to server, but the site SSL Labs has useful tools to help assess the quality of encryption on your server (and also on your browser, but the focus here is the server). It not only detects potential problems in your certificate, it checks which protocols are enabled on your server and which should not be, and gives instructions on how to disable them.

    (see for example the result of the analysis for my personal website - which is just an ordinary blog, nothing too sensitive - I won a C rsrs)

  • Thank you so much for the information @mgibsonbr, I used the site that passed me to test a blog that I have also, gave grade A, but I think it is because of Cloudflare, if you are to test the certificate directly to my site without going through the CF also gives "C".

  • 2

    Probably Cloudfare is more restricted in the protocols it accepts (note that the test is not only - not primarily - about the certificate, the accepted protocols are the weakest link), and that’s a good thing. But disabling unsafe protocols is relatively easy, the first time I used this tool on my site won was an F... :P

Browser other questions tagged security-guard

You are not signed in. Login or sign up in order to post.