Secure web authentication system w/o SSL and PKI


I've been researching on whether it is possible to have a secure web
application authentication system without the availability of SSL but
not yet found an answer. The system should be able to handle both
initial user account registration and subsequent logins.

The reason for my efforts is that I'm currently using a free PHP
hosting package and thus, there is no SSL option provided. This is
understandable due to cost of providing SSL certificates.
Additionally, due to the host's policy of preventing abuse by spammers
signing up for free PHP accounts on their servers to send out spams,
the email() function, fsockopen(), exec(), passthru() etc. are all
disabled and safe mode is turned on.

Given the above limitations, I wonder if a secure web authentication
mechanism is still possible and if there is any concepts from
established authentication protocols based on symmetric encryption and
MD5/SHA-1 digest that I can recycle and leverage on.

In the beginning, a user should be able to register for an account,
and approval for the account creation has to be granted by the system
administrator. This is slightly different from most public web sites
where approval is granted and account creation is done immediately by
system w/o human intervention.

I have no access to SSL encryption. So to prevent my users from
falling prey to passive attacker sniffing and possibly replaying the
captured plaintext passwords in future login attempts, transmission of
plaintext password over the network is disallowed. My thinking is that
this can be reversed; instead of making the user transmit his chosen
password in plaintext during registration, the server can generate a
one-time password used to activate the new account, and sent the
minted one-time password to their email address.

In a way, I'm relying on their email provider (e.g. Yahoo!, Gmail or
Hotmail) security to provide the protection and thus access to the
reply email containing the one-time password. The user have to check
their email account for the reply email and use the one-time password
for the first time login/activation.

At this point, it is assumed that only both the server and the end
user knows the one-time password but not anyone else, even if there is
a passive attacker monitoring transmission between the web server and
end user connection.

However, if a trojan horse has been implanted on the end user's
machine, or a network sniffer is running, even the reply email
containing the one-time password can be sniffed, considering Web-based
email provider typically send out data in clear without SSL as well.
I'm making the big assumption that the user's email login has not been
compromised and the person who can read the reply email with one-time
password is the end user himself. This is the biggest loophole yet to
be addressed; and the difficulty in ensuring the common secret is
communicated only between server and end user.

The authentication protocol steps are summarized below:

1. User send account registration details (username + email address)
to server to initiate account creation.

2. Administrator will monitor for new account requests and approve/
disapprove. Approval will send an email with a generated one-time
password back to the email address. This process also helps to
validate that the email address is valid.

3. User checks his email account and obtain the one-time password plus
the link to login or activate his account. User clicks on link to
login page.

4. Server generates and embed a nonce in the login form, send it back
for login.

5. User logins with the one-time password. The one-time password is
concatenated with the nonce and is further hashed using MD5/SHA-1 at
the client browser prior to transmission, to prevent passive attack
and replay attacks. Thus, the one-time password is not transmitted in
the clear after hashing. The hashed value is sent back to server.

6. The server checks the login, hashing the one-time password it
recorded when it first generated it, together with the nonce it issued
(a repeat of the client hashing process). Login is determined to be
successful or failed by comparing the expected and received hash

7. Server further checks if it is a first time login using a generated
one-time password. If it is, it directs the user to change to a
permanent password of his choice.

8. User fills up the password change form. The password is encrypted
using symmetric encryption at the client side using the current one-
time password, which presumably is still unknown to potential
attackers, and the encrypted password is sent to the server.

9. Server decrypts the encrypted permanent password using the one-time
password, and updates its user account database.

10. User will be able to login using his chosen permanent password for
future log-ins, with nonces generated by server to prevent identical
hashes for different login sessions given the same password.

Any thoughts or comments on this?


Relevant Pages

  • Re: user cant access OWA or RWW
    ... I filtered the Security log on the server using her name in the User box and unchecked Success. ... Now I see Event 533's for her account when I tried it this morning. ... There should be a couple of events during this login process. ...
  • Re: Error 10061, 0x800ccc0e, bug?
    ... message 'connection to server cannot be established. ... booting and in your first XP login session, ... * changing windows account is not important, ...
  • Re: 0x800ccc0e & 0x800ccc0d
    ... Are you saying that I,:login username@xxxxxxxxxxxxx? ... Tiscali is my ISP but I have not got an e-mail account with them, ... server, set a reasonable number of days to delete from server, or your ISP ... Your Live mail account Will NOT work in WM, ...
  • Re: Tough password question!
    ... Is it possible that NTLMv2 login is failing for some reason and the server / ... > I have used passwords longer than 14 characters on ... >>> account and it will login if I change the domain admin password to ...
  • Re: one-time passwords
    ... > I know that it evolved from S/Key, but what is the difference between S/Key ... > ready to be used when required for authentication while one-time password ... One Time Passwords (OTP) fall into three categories - event based, ... Both the token/software and the server have ...