[Freeciv-Dev] Re: MD5 password authentication and so on.

["Zverina, David" <David.Zverina@xxxxxxxxxxxxxxx>]

You are missing challenge-response mechanism.
Works something like this.
1. Client sends a login request with user id
2. Server sends a challenge string which changes every time it's used (eg. a
timestamp)
3. Client encrypts the challenge string using his password as the key. It
sends the resultant string to the server.
4. Server does the same calculation as the client using it's copy of the
password and compares it to the password received. If they match the client
is authenticated.

The advantage here is that the password is never transmitted over the
network. The system is thus immune to sniffing and replay attacks.

> -----Original Message-----
> From: Vasco Alexandre Da Silva Costa [SMTP:vasc@xxxxxxxxxxxxxx]
> Sent: 21 August 2001 22:18
> To:   freeciv-dev@xxxxxxxxxxx
> Subject:      [Freeciv-Dev] MD5 password authentication and so on.
> 
> Now there are two ways (from what i see) to implement this password
> authentication thing. The easy way and the not so easy way.
> 
> === easy way:
> (used by several MUDs, MUSHes and good ye olde UNIX login).
> 
> The user gives a password and this is sent to the server in some form
> (plaintext, crypt()ed or some misterious way). The password is stored in
> an encrypted form.
> When a user connects he sends the password in plaintext, the server checks
> if it matches and all is well.
> 
> I guess this is what you use right now.
> 
> === not so easy way:
> (public key authentication, RSA or some other, using an authentication
> server)
> 
> assuming the client knows beforehand the auth server's public key and IP
> address and that these weren't tampered:
> 
> 1) client asks for the server public key.
> 2) auth server replies with the server public key encrypted with the
>    auth server private key so noone can modify it in transit.
> 3) server public key is decrypted by the client using the auth server
>     public key.
> 
> 4) client sends the server a message encrypted with the server public key
>    containing its identifier and a stamp. only the server can decrypt this
>    because only he knows the private key.
> 
> repeat 4) but from the server side (i.e. server authenticates client). The
> server asks the client's public key to the auth server for this.
> 
> Now you have a secure channel. This protocol can also be attacked if
> someone stores the communications and reuses the messages. This problem is
> resolved using timestamps. Of course this requires having synchronized
> clocks on all the machines participating in this (doh!).
> 
> There's also Kerberos (which also requires synchonized clocks) and several
> other ways of doing authentication which vary in their security and
> simplicity.
> 
> 
> IMHO just use the easy way :-)
> 
> Since crypt() isn't very portable i guess freeciv should include a crypt()
> implementation if you are going to use it. There is probably some
> GPL or BSD code you can use for this. Try freshmeat.net :-)
> 
> ---
> Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa
> 
> 
*************************** IMPORTANT NOTE **************************
The above information is confidential to the addressee and may be
privileged.  Unauthorised access and use is prohibited. William M. Mercer
Limited is regulated by IMRO and the Personal Investment Authority.
Registered in London No. 984275 Registered Office: Telford House, 14 Tothill
Street, London SW1H 9NB