-1

I thought of this process specifically to stop "man in the middle" attacks and replay attacks:

  1. User types their username into the client application.
  2. Client application sends the username to the server.
  3. Server responds with a string of text (let's call it SecretA) that is the encryption of a random string RandomString using the password for the username retrieved as the encryption key!! i.e. SecretA = encrypt( message: RandomString, key: Password)
  4. User types in their password and presses "sign in".
  5. The client application takes the user entered password and SecretA. It decrypts SecretA using the user entered password to discover the RandomString (only if the user entered the correct password). It encrypts the RandomString using the user password concatenated with a timestamp (that goes down to the microseconds) as the key, producing SecretB. i.e. SecretB = encrypt(message: RandomString, key: concat(Password, TimestampInMicroseconds))
  6. The client sends SecretB to the server along with the timestamp used in the encryption in step .
  7. The server decrypts SecretB by concatenating the user's password with the timestamp it also received from the client. If the decryption is RandomString, then the user gets logged in.
  8. The server denies access if the timestamp client sends has too big a difference with the time the server receives the message.
Adé
  • 113
  • 4
  • 1
    your question could be improved by describing the purpose of it. What is the advantage of this over how logins work today? I'm assuming that it avoids the sending of plaintext passwords and is supposed to prevent replay attacks? Also, the password needs to be stored plaintext on the server, right? – tim Jun 18 '15 at 16:02
  • The password will preferably be stored encrypted. And the server will have a secret key to decrypt/encrypt the password. I want to protect from a middle man looking at the password if they are sniffing packets sent over wifi. If I do an encrypt of the password using a key that the server and client only know, there is still a chance of the man in the middle reverse engineering the client to get that key. – Adé Jun 18 '15 at 16:23
  • First, if you store the password encrypted, you're in danger of pulling an Adobe. This is a fundamentally bad practice, as you don't need to know the user's password, and the user may share passwords between sites. Likewise, there is no guarantee that a given login was the user; it could be anyone with access to the key and encrypted password. Please read Thomas Pornin's canonical answer to How to securely has passwords. – Anti-weakpasswords Jun 18 '15 at 23:59

1 Answers1

1

If your intended goal is to stop man in the middle attacks then it sort of works in theory, but practically speaking it falls apart fairly easily. This is just what I see as obvious. I'm sure there are more things I've missed.

You're relying on the secrecy of the password to protect the entire conversation, which means its effectively a symmetric key. User-defined passwords are fundamentally not random, so the ability to guess the key is a real problem. You could use a derived key based on the password and that would make the key a bit stronger.

You need to store the password unprotected (not hashed) which is usually a bad thing to do, because any breach of that list means every user is screwed. You could store the equivalent derived key, but then if the attacker gets that value they can just bypass the derivation on the client side.

There are also a number of undefined crypto requirements here, like algorithm agreement, IV usage, etc. How do you protect the channel from a MITM that specifies a weak algorithm, or uses an IV of { 0, 0, 0, 0, 0, 0, 0, 0 }, or etc.

Steps 5-6 can be replayed by an attacker an infinite number of times within the period of validity for the timestamp. Both client and server need to be in sync time-wise otherwise its very easy for them to diverge and you'll need a wider window otherwise you'll get a never ending barrage of bad requests. This is a fairly serious problem with distributed systems. You need a way to know on both sides that you've never seen that particular message before.

What happens when you've authenticated both parties? Is that it? A one time thing? What about the rest of the communications between the two? Odds are pretty good you're not just authenticating. An attacker can just wait for the authentication to finish before they start fiddling with data to do whatever they want to do.

What you're trying to do is prove authenticity of both parties and then create a secure channel between them based on that authenticity. As such you need to agree on a key for the channel. This is a key exchange of some sort. This might be a useful question to look at too.

Community
  • 1
Steve
  • 15,263
  • 3
  • 39
  • 66