November 16th, 2011, 02:50 AM
An idea to add to Paul Johnston's challenge-response protocol
study Paul Johnston's proposed challenge-response protocol here:
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:
as another weakness Paul Johnston says:
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:
i am eager to hear your opinions about it.
November 18th, 2011, 02:54 AM
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).
November 18th, 2011, 01:20 PM
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.
November 20th, 2011, 03:20 AM
And yet another idea!
Johnston says, in the 'Protecting the Session ID' section:
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.
November 24th, 2011, 12:36 AM
My first idea was:
unfortunately i were wrong regarding this.
i received Paul's response recently; he says:
But regarding this derived idea:
And regarding this one:
December 16th, 2011, 05:55 AM
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.