implementing an authentication mechanism for understanding the basics of client authetication

Question

I'm trying to implement a simple protocol to authenticate users and authorize them to access a certain web page/resource via a login form.

Please note that this is just something to use on my own and that it's just to get the basic idea of how such systems work.

My idea is to store the hash of a shared secret between Server and client on the server side and then use a challenge-response mechanism to authenticate the user. The user would type an username and the server will respond with a challenge that implies the use of the shared secret to get access to the resource. For example, hashing the password and the challenge together and sending it back to the server. The server would do the same with the user's stored password and check if both values are the same.

However, how can this authenticate a user A to a server B if, let's say user C can intercept A's response to the server and send it to the server as if it was C? Then the server would authorize C to the resource A was supposed to gain access to.

Isn't this the way protocols such as CHAP or EAP work? (in an over-simplified way). I think I have a bit of a mess in my head, but the only solution I can think of to prevent a MiTM attack is to use TLS/SSL. But how do websites authenticate users nowadays without TLS? Also, OpenID seems to me equally vulnerable to man in the middle attacks, but it must be something I don't understand or I'm missing.

Answer 1

For example, hashing the password and the challenge together and sending it back to the server. The server would do the same with the user's stored password and check if both values are the same.

In this scenario, the server would need to have the user's complete password, stored in plaintext or encrypted form. This introduces a security risk - if your database becomes compromised then the passwords are given to the attacker. It's better to store the passwords as hashes, 'salted' with a random value to prevent rainbow table attacks. This way the server cannot accidentally leak the passwords because it doesn't have them to start with.

Also, OpenID seems to me equally vulnerable to man in the middle attacks, but it must be something I don't understand or I'm missing.

OpenID is only effective if it's over HTTPs. Otherwise it is indeed vulnerable to a man in the middle attack.

However, how can this authenticate a user A to a server B if, let's say user C can intercept A's response to the server and send it to the server as if it was C? Then the server would authorize C to the resource A was supposed to gain access to.

Again, HTTPs deals with this. In the initial handshake between Client A and Server B, messages are encrypted using public/private key encryption. This public/private key is stored in an X509 certificate kept on Server B, and Client A can validate the public key by ensuring it's signed by a recognized certification authority.

Server C might attempt a man in the middle attack by substituting its own public/private key pair, but Client A will recognize that Server C's certificate is not signed appropriately.

Answer 2

This is exactly the problem that protocols like PAKE and SRP aim to solve. With PAKE/SRP, the client and the server mutually authenticate each other based on a password known to both the client and the server.

The client demonstrates to the server that it knows the password, without the client sending the password (or password-equivalent data) to the server. Furthermore, the server does not store the password (or password-equivalent data) and is not susceptible to dictionary attacks, and an eavesdropper or man-in-the middle is not able to gain enough information to derive the password. This effectively prevents man-in-the-middle attacks using fake certificates, and prevents 'phishing' sites from stealing users' passwords.

Answer 3

Unfortunately the days of a simple application Authentication and Authorization are gone.

Authentication or trusting of just the end-user and not the server is the basis of Man-in-the-middle attacks.

In today's threat environment there are no simple "safe" methods.

There are three current Web Authentication and Authorization specifications that are proven to be effective:

• https://webauthn.io/ - (Web Authentication API) is passwordless authentication.
• https://appauth.io/ - OAuth 2.0 and OIDC for JavaScript Public Clients, Android, iOS, MacOS
• Authorization Code Flow with PKCE - OAuth 2.0 and OIDC for Web Apps and SPAs

As always, risk assessments of your specific implementation and environment and the comparison of impact of the loss incurred when you suffer a successful attack should be considered.