Secure web authentication system w/o SSL and PKI

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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?

Re: Secure web authentication system w/o SSL and PKI

Quoted text here. Click to load it

Authentication has nothing to do with SSL. You can use SSL to
authenticate. But that's it.

Quoted text here. Click to load it

SSL certificates cost nothing. You can easily set up your own CA with
openssl or use a free CA. SSL certificates signed by a CA which has
its CA certificates preinstalled in standard browsers cost money. But
if you give out certificates to people to use your own services there
is no problem using your own CA.

Quoted text here. Click to load it

Why do you want symmetric encryption? Even SSL does not use symmetric
encryption for authentication or authorization. Certificates are based
on asymmetric encryption. Really secure authentication only based on
symmetric encryption requires off-band exchange of the symmetric key.

I would highly recommend not to develop your own security functions.
It is futile. Even the best make mistakes at times and create security
algorithms which are flawed as various examples in the past have
shown. It is best to use existing functions like for SSL or PGP or
similar. I guess there should be some implementations for that in PGP
as well. However, I guess it won't really work in PHP as asymmetric
encryption requires some number crunching which is slow when scripted
in PHP. It depends on your ISP which libraries are available in PHP.

Thus I would either suggest you find an ISP which allows you to use
the functions you require (e.g. SSL) or you just do a simple standard
password setup and don't worry about the rest. For any normal average
person it is futile to create its own secure algorithm. A correct,
systematic approach to develop that requires a lot of experience and
knowledge. Without the knowledge it won't be secure and thus it is not
really worth it waisting your time to come up with something which you
believe is secure. But that's maybe only my opinion....


Re: Secure web authentication system w/o SSL and PKI

Hi Gerald,

Thanks for sharing your insight on this issue. I believe my own design
is full of loopholes anyway. :)

Just to add some comments to your reply.

Quoted text here. Click to load it

Yes. I do agree. I guess in my posting, I wasn't clear on what my
system can do specifically and I lumped together user account
registration, user log-in and user password change together in 1
system. Technically, SSL provides an encrypted channel to facillitate
authentication and transmission of sensitive data over insecure
network (i.e. Internet).

Quoted text here. Click to load it

For free web hosting accounts, so far I have not heard of the hosting
company allowing their users to install their own certificates
(whether signed by CA or self-generated) or offering HTTPS in the
first place. That was my point when I mentioned that I do not have
access to SSL HTTPS to create a secure channel for handling log-in
authentication and password change, even when I feel it is required.

Quoted text here. Click to load it
Yes. I'm back to puzzling over the old problem in the 1960s and 1970s
of key exchange and distribution when only symmetric encryption was
available and asymmetric encryption wasn't invented. When I do not
have access to RSA or Diffie-Hellman key exchange, the closest to
scramble my password to prevent transmission in the clear is only
symmetric encryption. But how to share the secret key to decrypt the
password on the other end, this I've no answer.

Quoted text here. Click to load it

Agree totally. Just trying to work around some constraints in
resources that I have based on what the hosting company is willing to
provide for free. I haven't checked if the PHP mcrypt library is
installed and available instead of spinning my own cryptographic
implementation. (*gasp* no time plus no expertise)

Quoted text here. Click to load it

Agree as well. Experts like Bruce Schnier has spent decades working on
encryption algorithms, and there're experts working on other areas
like key exchange problems for many years. A novice should never
attempt to develop new security protocol and system on his own and
think it is secure. Taking a 6 months or 1 year computer security
module does not make a person an expert. However, I guess it does boil
down to the confidentiality and value of the information I'm trying to
protect too. Since I'm not trying to protect ultra-secret or top-
secret national secret, a simple system may just suffice for its

Re: Secure web authentication system w/o SSL and PKI

Quoted text here. Click to load it

Client sends username
Server sends challenge (password+challenge hash stored on the server)
Client hashes password+challenge and sends to the server
Server checks if it's the same, and if so the client just authenticated.

Russell Wood

Site Timeline