4

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.

  • 1
    Why are you using a challenge-response mechanism instead of standard password hashing? Your description implies you are storing passwords in plain text, which breaks the first and most important rule of passwords – Conor Mancone Dec 29 '19 at 12:26
  • Aren't challenge-response and hashing complementary? – Johnny Dec 30 '19 at 8:54
  • Most importantly though: are you storing the passwords in plain text or a reversible format? – Conor Mancone Dec 30 '19 at 11:12
  • I'm storing the hash of the password – Johnny Dec 30 '19 at 23:19
3

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.

  • 1
    I've read in many places that if in a challenge-response you use timestamps or session id's with expiration dates you prevent a replay attack. However I don't see how can that fight against an instantaneous replay attack. If an attacker can get your message and instantly replay it to the destination, what's the method for the server of making sure he is not you, other than https? Also if the last message in the TLS handshake is replayed, the server B wouldn't know it has been intercepted by a third party (C) until it uses the negotiated symmetric key with A to encrypt the next message, right? – Johnny Dec 30 '19 at 8:51
  • (contd.) Does the server keep track of the details of a TLS connection, such as A's IP address and port, for example? I can imagine it could be a way of seeing if the last message has been replayed by C – Johnny Dec 30 '19 at 8:53
1

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.

-2

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:

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.