Up to Main Index                              Up to Journal for June, 2013

                    JOURNAL FOR WEDNESDAY 19TH JUNE, 2013
______________________________________________________________________________

SUBJECT: Who is knocking at my door?
   DATE: Wed 19 Jun 23:14:09 BST 2013

Busy coding session tonight: cleaning up a modified client package and the new
login code - haven't decided which package it will go into yet, currently it's
in the player package.

In my last journal entry I asked for comments and feedback on the idea of
using unique login details other than character's name and password. For
example email address and password. This would then allow for characters with
the same name. The rational I gave was: After all how many John Smiths are
there?

Based on feedback it seems like it's a good idea - although people would
rather use a 'random' ID of characters, numbers and symbols instead of their
email address which I can understand.

One question that was asked was why do we need an email address or ID as well
as a password? Can't just the password be asked for?

Good question, and the answer is no. Asking for the email address or ID
identifies who you are. Providing the password authenticates you - it's how
you prove you are who you say you are.

Another thing you have to be careful of is telling the user 'how' they are
wrong when logging in. For example assume you have error messages like
'Username is wrong!' and 'Password is wrong!'. An attacker trying to log in as
someone else tries some random usernames. As soon as they get 'Password is
wrong!' they know they have a good username and just need to try different
passwords.

However assume you have one message and say 'Username or Password is wrong!'.
Now an attacker does not know if they have hit on a good username ;)

Really this is all basic security stuff a developer should know. Which is also
why I'm documenting things carefully and clearly. Hopefully people will
learn...

Another thing is not to hold plain text or reversibly encrypted passwords.

Store the passwords as salted hashes. When a user provides a password: HASH
THE SALT AND PROVIDED PASSWORD AND COMPARE IT TO THE STORED HASH. Please,
please, please do not decrypt the stored password and compare with the user's
input!

Competent developers who know this stuff know what I am talking about and are
probably smirking or sniggering at this post. However I see so much code from
people that claim to be 'Professional Developers' - and getting paid $$$ or
£££ more than me :( - yet they are making these basic mistakes in production
systems that deal with personal and/or financial details & credit cards.

I really hope this unattributed quote does not offend anyone, it makes me
smile every time I quote it:


                "In God we trust. All others, we virus scan."


Another quote which I heard a long time ago and cannot find a reference for -
I believe it was said by the owner/managing director of Chubb?


                   "We will never build the perfect safe as
                  some idiot will always want a door in it."


I'm far from being a security expert but I do like to think I can get some
basics right and make nefarious people's jobs that much harder.[1][2]

--
Diddymus

  [1] Isn't it ironic that WolfMUD clients use insecure Telnet who's network
      traffic is unencrypted and easy to monitor for interesting stuff like
      login details! [3]

  [2] To my credit I can say I've implemented internet payment systems that
      have been independently certified for local government use.

  [3] I have plans for this problem. Maybe involving SSH clients or secure
      tunnels or ... something ...


  Up to Main Index                              Up to Journal for June, 2013