With SmartFoxServer 2.10 we have added full TLS encryption to the protocol. In this recipe we’re going to discuss the implications for the Login phase in SFS2X and the differences with\u00a0the previous modality of secure Login.<\/p>\n
<\/p>\n
The Login phase in SmartFoxServer 2X has always been secure, even prior to the introduction of protocol encryption. For those not entirely familiar with the previous system we used a well known communication scheme called CHAP<\/a> (Challenge-Handshake Authentication Protocol) which can be summarized in these steps:<\/p>\n This system is pretty\u00a0secure as it never transmits the password in clear and the hash will be different in every session, but has one main drawback: it typically forces the developer to keep the users’ password either in clear or hashed in the\u00a0database, not allowing for proper\u00a0salting<\/a>.<\/p>\n Using a simple hashing pass is still not good enough, as the passwords need to be quite\u00a0strong in order not be cracked using a reverse-hash database.<\/p>\n With the TLS-encrypted protocol we can overcome these issues because we’re no longer using an asymmetric encryption technique (i.e. hashing). Instead we’re using symmetric cryptography (AES 128) with a key that has been exchanged securely over HTTPS.<\/p>\n This in turn means that\u00a0the password no longer\u00a0gets to the other side as a hash which\u00a0caused the\u00a0storage limitations in the first place.<\/p>\n In essence it means that clients’ passwords can be store in your datasources in whatever way your security requirements dictate.<\/p>\n If you want to get more in-depth on the new\u00a0SFS2X protocol encryption,\u00a0we recommend reading our introduction to SmartFoxServer’s TLS support<\/a>.<\/p>\n No, there a couple of minor changes that need to be applied to your code. It is all\u00a0very simple and it all boils down to one single parameter which, unsurprisingly, is the password\u00a0<\/strong>itself.<\/p>\n Let’s review the pre-2.10 modality of sending a login request. Server side:<\/p>\n With SmartFoxServer 2.10 and higher we need to send the password as a different field in the request. This is because the 2nd parameter in the LoginRequest<\/strong> is always hashed with the unique token<\/span> (as we said in the opening of this article) to maintain compatibility with the previous version.<\/p>\n To bypass the default password field we can simply pass a null value and provide the real user password as a field\u00a0of the SFSObject taken as an optional 4th parameter in the request.<\/p>\n The object is a convenient tool to send any additional custom parameter at login time.<\/p>\n\n
\u00bb What does this all mean?<\/h3>\n
\u00bb Can I use my old Login code with the new TLS protocol?<\/h3>\n
\nClient side (C#) we used this:<\/p>\nsfs.Send(new LoginRequest("user name", "password", "zone name"));<\/pre>\n\r\npublic class LoginEventHandler extends BaseServerEventHandler\r\n{\r\n @Override\r\n public void handleServerEvent(ISFSEvent event) throws SFSException\r\n {\r\n String name = (String) event.getParameter(SFSEventParam.LOGIN_NAME);\r\n String pass = (String) event.getParameter(SFSEventParam.LOGIN_PASSWORD);\r\n\r\n if (getApi().checkSecurePassword(session, clearPass, encryptedPass))\r\n {\r\n \t\t \/\/ Login success...\r\n }\r\n\t else\r\n {\r\n \/\/ Create the error code to send to the client\r\n SFSErrorData errData = new SFSErrorData(SFSErrorCode.LOGIN_BAD_USERNAME);\r\n errData.addParameter(name);\r\n\r\n \/\/ Fire a Login exception\r\n throw new SFSLoginException("Login error!", errData);\r\n }\r\n }\r\n}\r\n<\/pre>\n\r\nLoginRequest(string userName, string password, string zoneName, ISFSObject parameters)\r\n<\/pre>\n
\u00bb\u00a0Secure Login 2.0, using TLS encrypted protocol<\/h3>\n