#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2011
    Posts
    10
    Rep Power
    0

    An idea to add to Paul Johnston's challenge-response protocol


    study Paul Johnston's proposed challenge-response protocol here:
    pajhome.org.uk/crypt/md5/advancedauth.html#alternative

    it's a protocol for making web/http(non-SSL/TLS) register and login systems more secure against passive adversaries.
    in this protocol the user's password is never sent and additionally a passive adversary cannot use the information he gains by eavesdropping the communications between the client and server to login to the server himself.

    but an offline brute-force attack is possible for him to discover the user's password and is specially a concern if the user's password is weak/guessable which can be the case in many situations.

    Paul Johnston suggests some methods to mitigate this problem:
    pajhome.org.uk/crypt/md5/advancedauth.html#brute

    as another weakness Paul Johnston says:
    Information Leakage
    However, related to this, an attacker can see when a user has logged in, because the random number changes on every successful login. The change in random number confirms to the attacker that the account does exist.
    And i got an idea that is related to these two weaknesses.
    i think it can decrease the possibility of brute-force attacks significantly and can eliminate(completely) the 'Information Leakage' which Mr. Paul Johnston have mentioned.

    i have already sent my idea to Mr. Paul Johnston but he seems busy and very slow to analyze it and respond; so i decided to post it publicly before receiving his answer.

    this is the text explaining my idea that i sent to him:

    when the client first registers in our system, it sends to us, in addition to other things in your protocol, a field named encr_key that its value is hex_hmac_md5(password, rand_salt); client also sends rand_salt to the server.

    note: i assumed that the rand_salt is generated at the client side; but we can generate it at the server side (and send it in the register form to the client) if that can be cryptographically stronger.

    we store the encr_key and rand_salt in the registered user's database record permanently.

    server never sends the encr_key to the client (and the client never sends it to the server again), but the server sends the rand_salt instead (via AJAX and after the user enters his username in the login form). then the client computes the hex_hmac_md5(password, rand_salt) each time and encrypts the login information that it sends to the server with that key.

    at the server side we have the encr_key already and can decrypt the login information.

    that's all.

    this method does not remove the possibility of brute-force attacks completely, because if an attacker is eavesdropping when the user registers, he can get that userís encr_key. but at least we decreased the possibility of brute-force attacks on our users because this key is sent only one time at the register stage and for an attacker to be able to use brute-force effectively he must have the chance to record that key exactly for that user when the user registers. so i think this method decreases the possibility of brute-force attacks significantly. it decreases exposing time of sensitive data needed for effective brute-force attacks significantly.

    ------------------------------

    i think encr_key can be used for another purpose too.
    we can encrypt the information the server sends to the client too, and reduce the possibility of the 'Information Leakage' u have mentioned for your Alternative System.

    u have said: "an attacker can see when a user has logged in, because the random number changes on every successful login. The change in random number confirms to the attacker that the account does exist."

    because the information the server sends to the client for login are encrypted now (and u know the cipher text for strong cipher algorithms/modes is not the same each time even for the same data encrypted with the same key; it seems random), an attacker cannot even discover that the random number (challenge) has changed.
    i am eager to hear your opinions about it.
  2. #2
  3. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2011
    Posts
    10
    Rep Power
    0
    and can eliminate(completely) the 'Information Leakage'
    i think i were wrong regarding this.

    i should say "and can mitigate (at least as much as it does for brute-force attacks, and probably much more)..."

    Because i think the 'Information Leakage' consists of two things:
    - the ability of an adversary to acknowledge the existence of an account.
    - the ability of an adversary to discover whether a user has logged in from the last time the communications were wiretapped (and recorded).

    i think my idea can eliminate the first possibility completely and can decrease the second (as much as it does for brute-force attacks).
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2011
    Posts
    10
    Rep Power
    0
    i think the idea can be improved even further this way:

    we create a new rand_salt/encr_key pair each time the user logs in to the system, encrypt the pair with the previous encr_key and send it to the server.
    the server decrypts the new pair and overwrites the old rand_salt and encr_key with the new ones.

    this way if an adversary has gained the first encr_key when a user registered, his key will become useless when he misses a new login session between the client and the server.
  6. #4
  7. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2011
    Posts
    10
    Rep Power
    0
    And yet another idea!

    Johnston says, in the 'Protecting the Session ID' section:
    At login, JavaScript saves the password on the client. One way to store this is a cookie with a random path attribute that doesn't exist on the server, so the cookie is never transmitted.
    pajhome.org.uk/crypt/md5/advancedauth.html#sessionid

    i think it's obviously a bad idea to store the user's password in a cookie on the client (although the cookie is never sent over the network).
    It is not acceptable from a security standpoint. too bad! specially if we want the user to remain logged in for a long time (not merely for the duration of the current web browser session).

    and a place other than cookie isn't better enough (if it is not even worse!). storing the user's password on the client is generally bad; even for a limited time.

    but i think there is, fortunately, a simple good solution for it:
    when the user is logging in (manually) we can create a random string and store it and use it instead of the user's password. for registering and verifying it with/to the server we use the same protocol used with the user's password.
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2011
    Posts
    10
    Rep Power
    0
    My first idea was:
    when the client first registers in our system, it sends to us, in addition to other things in your protocol, a field named encr_key that its value is hex_hmac_md5(password, rand_salt); client also sends rand_salt to the server.

    note: i assumed that the rand_salt is generated at the client side; but we can generate it at the server side (and send it in the register form to the client) if that can be cryptographically stronger.

    we store the encr_key and rand_salt in the registered user's database record permanently.

    server never sends the encr_key to the client (and the client never sends it to the server again), but the server sends the rand_salt instead (via AJAX and after the user enters his username in the login form). then the client computes the hex_hmac_md5(password, rand_salt) each time and encrypts the login information that it sends to the server with that key.

    at the server side we have the encr_key already and can decrypt the login information.
    unfortunately i were wrong regarding this.
    i received Paul's response recently; he says:
    Ok, so if an attacker guesses one password, he can see if this is correct by:

    encr_key = hex_hmac_md5(guess, rand_salt)
    reply = decrypt(encr_key, encrypted_reply)
    check whether: reply == hex_hmac_md5(guess, challenge)

    To do a brute force attack, he'd go through a long list of passwords, until one finally matches.
    But regarding this derived idea:
    i think encr_key can be used for another purpose too.
    we can encrypt the information the server sends to the client too, and reduce the possibility of the 'Information Leakage' u have mentioned for your Alternative System.

    u have said: "an attacker can see when a user has logged in, because the random number changes on every successful login. The change in random number confirms to the attacker that the account does exist."

    because the information the server sends to the client for login are encrypted now (and u know the cipher text for strong cipher algorithms/modes is not the same each time even for the same data encrypted with the same key; it seems random), an attacker cannot even discover that the random number (challenge) has changed.
    Paul says:
    Interesting... and this is a new idea. You'd need to use a random IV (initialisation vector) for the encryption, but that is do-able.

    I will at some point add this to my site, and give you a mention.
    And regarding this one:
    i think it's obviously a bad idea to store the user's password in a cookie on the client (although the cookie is never sent over the network).
    It is not acceptable from a security standpoint. too bad! specially if we want the user to remain logged in for a long time (not merely for the duration of the current web browser session).

    and a place other than cookie isn't better enough (if it is not even worse!). storing the user's password on the client is generally bad; even for a limited time.

    but i think there is, fortunately, a simple good solution for it:
    when the user is logging in (manually) we can create a random string and store it and use it instead of the user's password. for registering and verifying it with/to the server we use the same protocol used with the user's password.
    He says:
    You're absolutely right. I did think of this though - if you look a few bullet points further down on my site I mention:

    "It is best to avoid saving the password on the client. Instead, a temporary password can be derived from the plaintext password, and the login challenge, and all tokens generated from this."
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2008
    Posts
    601
    Rep Power
    43
    Why not implement a form of SSL? A shared session key is sent to a server using the server public key. The key is generated for each session, and does everything you want.

    Sending your public key to the server is no problem, and the attacker can eavesdrop all they like.

    If you need to authenticate the connection, you have a different problem, as the attacker could spoof the server, so you need to ensure you have the server public key before connection initialization and likewise the server needs your public key prior to connection initialization, in order to perform authentication. This must be done via some other channel, e.g. memory stick and physical transfer person to person with the server admin for example.

    Best regards,
    AstroTux.

IMN logo majestic logo threadwatch logo seochat tools logo