2

Let's say I want to secure authentication on a web app or a mobile app or even a machine to machine app.

My first approach to secure the password is to enable HTTPS and some sort of client-side message-level encryption of data to be sent over the wire.

I think that since MITM could help circumvent HTTPS and discover at least an encrypted password, there is maybe no way to truly protect a password.

Not considering VPN, if a user submitted data (e.g.: password) over the wire is it ever secure? Or if there exists a way to never submit a password over the wire?

schroeder
  • 125,553
  • 55
  • 289
  • 326
tom
  • 31
  • 2
  • @multithr3at3d For instance if on configured properly sslstrip with MITM (ethercap, arp poisonning etc...) one could easily get cleartext traffic in wireshark . That's what I meant by " break " – tom Sep 21 '19 at 16:54
  • 2
    There are several authentication methods which don't require a password or similar secret send over the wire, like client certificates or digest authentication. These of course require support from both sides of the communication so it is unclear if you can use this in your case. – Steffen Ullrich Sep 21 '19 at 17:19
  • I am not sure MITM is quite as easy as what you say, but there are definitely ways of authenticating users without involving a password - mutual TLS would be one example. Maybe you could rephrase your question to explain more about your thread model/concerns? – iwaseatenbyagrue Sep 26 '19 at 07:49

5 Answers5

4

The overall situation is rather complicated. The shortest answer I can give is that it's a solvable problem in principle, but not really solved in practice. I'll give a more complete summary in "good news - bad news" format:

Good news: TLS uses server-side certificates to insure that your encrypted connection is going to the server you intended to talk to, and not being intercepted by some impostor (such as a MiTM).

Bad news: TLS only works if you use it. TLS connections aren't always the default, and things like sslstrip can (mostly) prevent the usual ways of upgrading connections to TLS.

Good news: TLS is gradually becoming the default, HSTS can lock in TLS after first use, and in many situations (client-side apps, for example) the client can know in advance to use TLS.

Bad news: Our certificate infrastructure (certificate authorities, etc) is not entirely trustworthy, and bad/fraudulent certificates do get issued.

Good news: We're starting to use things like certificate transparency and certificate pinning to provide additional checks.

Bad news: Some organizations use TLS-intercepting proxies for network security. These use their own certificates, and are therefore completely detectable by the client (and will be rejected as insecure by default). However, in these situations, the client is effectively forced to change its policy, and trust the proxy's certificates if they want access to the Internet. For a while Kazakhstan was doing this country-wide! Unfortunately, these proxies can watch the entire (unencrypted) client authentication process.

Good news: There are authentication methods that never send the password, even in encrypted form. The most basic of these use a hash of the password to authenticate, but that means the hash itself is sufficient to authenticate, making pass-the-hash attacks possible. There are better methods that don't expose the client's credentials to even a TLS-intercepting proxy, such as client-side certificates and password-authenticated key exchange ("PAKE") protocols (most notably, the Secure Remote Password, or SRP protocol).

Bad news: client-side certificates are unweildy, since they require the user to carry around a certificate file rather than just remember a password (not that remembering passwords is easy -- you can/should use a password manager, but they generally don't support certificates).

PAKE protocols like SRP look to me like a much better solution, but they also have practicality problems. IMO the biggest one is lack of standardization and client-side support. The lack of built-in support in browsers means that the server has to serve the client side of the protocol as Javascript (or something similar), and a TLS-intercepting proxy can just replace it with something that leaks the password. Whee.

Mind you, if you're writing a mobile app (or other situation where you're writing the client), you aren't limited to what any browser supports and can go ahead and use SRP or something similar with a full, secure, native client implementation.

Gordon Davisson
  • 2,601
  • 1
  • 17
  • 13
  • Thank you for this reply. I heard about client certificate for authentication. Never heard about PAKE nor SRP. I'll look into it – tom Sep 21 '19 at 21:18
3

Your assumption that a MitM can always break HTTPS is invalid. The data being transmitted is encrypted with a key that is exchanged during a handshake. The key itself is encrypted during this handshake with pubic key crypto.

If you like, you can add a layer of security on top of HTTPS by encrypting your data. You could encrypt the password with the public key of the server and send it over. The reason you don't see this often is that crypto operations are somewhat expensive and the encryption is seen as redundant with HTTPS and ineffective without HTTPS (if the page is loaded over HTTP, wouldn't be hard to inject a keylogger into the page).

The Arbitrarion
  • 31
  • 2
  • Are you sure sslstrip would work only if communication started over HTTP ? Also, the problem is that HTTPS is not end-to-end encryption. If there are several nodes on the network, some might need to strip ssl to proceed packets. – tom Sep 21 '19 at 17:14
  • End-to-end encryption is a weird thing. It is encrypted until you hit the server that decrypts it. This can be the server itself, it can be a load balancer, can be some other stuff, But either of those can be defined as "ends". In some models, hitting the server directly doesn't even count as end-to-end. Honestly, having read into it a bit more. I may have been wrong about SSLStrip. I'll edit my response to take that part out. I did find a post dealing with SSLStrip specifically: https://security.stackexchange.com/questions/41988/how-does-sslstrip-work. Hope that helps. – The Arbitrarion Sep 21 '19 at 17:29
  • @tom Yes, sslstrip only works if the user browses to `http://`, but since that's the default when typing in a url without the scheme, it's still a concern. HSTS helps prevent this for the most part. – AndrolGenhald Sep 21 '19 at 19:51
1

It is possible to authenticate without ever sending an actual password, using something like Secure Remote Password protocol. It works similar to Diffie-Hellman key exchange to establish a key and in the process prove the user has the password, without ever sending either the password or something that could be used to deliver the password.

It's not used very frequently to my knowledge, but there are libraries out there for it. I found about it through a 1password blog entry; they use it to authenticate a user before allowing them to download their encrypted password vault.

Ben
  • 3,896
  • 1
  • 10
  • 22
  • Hey Ben. Why is it not used frequently ? There so much drama around password security. For instance, when I log into my bank account through for login, my password is sent over the wire. A MITM could intercept it (even if it's encrypted) and replay it later – tom Sep 22 '19 at 22:01
  • 1
    @tom TLS does not allow replays (at least, not simple ones). The session's encryption keys depend on random input from both client and server, so unless the server happens to re-use its contribution to the keys, the recorded encryption keys won't match. – Gordon Davisson Sep 23 '19 at 05:13
1

In addition to PAKE or SRP mentioned in some of the other answers, another way to prove possession of a password without sending the password itself is to use a public key cryptography. Here's how it works:

1) At registration time: On the client side, the user creates a password, then uses a key derivation function (such as PBKDF2) to derives a private key from the password. Then, a public key is derived from the private key. The public key is sent to the server, and saved on the server along with the other information about the user in the user account record.

2) When the user logs in: On the client side, the user enters the password, then the same key derivation function is used to derive the private key from the password. Then, the user proves that he/she is in possession of this private key. There are a number of ways that this can be done. One way is for the server to send the client a nonce, which the client then digitally signs, and sends back to the server. The server can then verify the signature using the public key on record for the user. If the verification is successful, this means that the user must have had possession of the private key to create the signature.

mti2935
  • 21,098
  • 2
  • 47
  • 66
  • What is a MITM steals the public key generated at step 1 ? He/she could perform the same decryption as the server does right ? – tom Sep 22 '19 at 22:53
  • 1
    Sure, a MITM could steel the public key sent in step 1. But, there would be nothing gained by the MITM in doing so, as there is nothing secret about the public key. – mti2935 Sep 23 '19 at 00:01
  • 1
    @tom A public key is allowed to be public knowledge. The server does not *decrypt*. It *verifies* a signature generated by the client. The server cannot sign anything because it's not in possession of the private key. The MITM also is able to verify but not sign because only the public key was ever sent over the wire. – Future Security Sep 23 '19 at 00:01
  • (But it's important to note that any scheme that uses no other secret information besides a password is inherently vulnerable to guess-and-check password recovery. Both the password and the private key could be recovered by brute force if the password is not strong enough.) – Future Security Sep 23 '19 at 00:05
1

As a security dinosaur, I remember the good old Kerberos. It was invented in the 80's to allow a secure authentication over an unsecure network. And it is still used nowadays as the underlying authentication system in Windows Active Directory system. So we can believe it to be a robust piece of software...

It can be used as a second choice is for any reason you cannot use HTTPS which is still the up to date way of securely exchanging sensitive informations.

Serge Ballesta
  • 25,952
  • 4
  • 42
  • 84