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