Client Authentication

[Mehmet Erol Sanliturk]

On Sat, Mar 23, 2013 at 10:16 PM, Doug Hardie <bc979 at lafn.org> wrote:

>
> On 23 March 2013, at 21:51, Mehmet Erol Sanliturk <m.e.sanliturk at gmail.com>
> wrote:
>
> >
> > Using Static IP in the client side , and checking Static IP of the user
> may be a possibility :
> > In that way , any message from another IP will not be accepted .
> >
> > If this is possible for your systems , it may be checked for usability .
> >
> > One difficulty is that each user should obtain a Static IP and can not
> connect to his/her ISP from another IP .
> >
> > Good side is that nobody can connect to ISP of the user from another IP
> : It supplies hardware security ( we are assuming that the user computer is
> not captured ) ..
>
> That is an interesting idea, but unfortunately our users tend to travel a
> lot and need to be able to access mail from anywhere.  Also, static IPs can
> get quite expensive from some ISPs.  Our users are pretty much on fixed
> incomes and any expense is a hardship for them.
>
> -- Doug
>
>
The following steps may be another idea :

Assume that you supply to your users a small login program prepared for
them specifically ( since you are using SSH )  :

Compile that program for each user with a special identifier for him/her
and ship this program to your user and require that the login will be
performed by this program  . This program will send a very long code to
your system with user password which is only known to you and to your user
.  Since external users will not know this code , they will not be able to
login into their accounts by using only password .

This will also easily identify fake login trials : It is very obvious that
to estimate a very long code will require a large number of tries : If code
fails , it means that login trial is from a fake user .
If password fails , it may be allowed a fixed number of trials ( The banks
are allowing only TWO failed passwords , on third , a new attempt can be
made after 24 hours , in Turkey ) .

This program may also additionally send computer signature to your system
which is previously send to you on subscription computed by a program
prepared by you .

If the user changes  / or uses a different computer , he/she should supply
a signature of the computer .

Here , important point is that , always you should verify that you are
communicating the real user , not a faked user in behalf of the real user .

For the stolen program/codes , prepare a new program and ship to the user .

Another idea may be the following :

Assume the user computer is NOT captured by a criminal bandit .

On subscription , send to the user a square bar code printed on a card like
credit card having a very long code specifically prepared for the user .
On login , the user will show this card to the camera of the computer and
will be transmitted to your system . In your system , it will be decoded ,
and it will be used to identify the user with his/her password .

If this application is used , it may not be necessary to send the users a
special login program prepared for each of them .






Thank you very much .

Mehmet ERol Sanliturk