Taming Security Series – Part Login Security

Applications do our job wonderfully. We depend upon them for tasks we give them. And for most part they work all right. As long as we behave with them , they behave with us too. This is the way it should be. But one day you finish with them , bid goodbye to them till tomorrow. Next day you sit in front of the computer and voila you see that your precious and trusty website shows banner of hacking group. Which for most of us may never have heard nothing about them and having a comment about them is far fetched at best. But wait how it happened. We had login , didnt we? You think about it and unless your answer is no(which in case i would genuinely like to meet you) and realise that you had login, no access without login. Then how it happened. Well this is something I am going to cover in upcoming posts whilst going deeper and deeper. For this part we will cover Login Security.

But let’s cover the basic tasks. OK. But before I start here is basic gist of it, “Give as less as you can” . Be absolute miser when it comes to getting any data from server ,because that is first sniffing point of your hacker.Hacker is more filmy word let’s use attacker. As attacker wants to generally enter your application and do nefarious tasks. Security is very important to your application but even more important to your reputation. Often damage caused by hack on social level is devastating. Most of the people who know how to build user interfaces fail when it comes to securing app. I admit security is hard. Even if you try your 100% there is no guarantee that you will succeed. But still if you do basic tasks then it will be pretty much good to go. In

Login Login Login

I often think that login is like gatekeeper. It facilitates  secure entry into application. Secure login and give yourself pat on back.Less is more.Login Security is very important to your application. If you do it all right, chance are it would be less difficult to gain control of your website. Now  So tell me normal login looks likes this

Login Security

So let’s cover very basics. Note that this is should cover most of practical cases for login. So this is how normally works.

1. User fills in email and password and then sends request to server.
2. If credentials match then ok , else we report to user that his credentials don’t match.
3. If credentials match then we allow him to enter application.

It almost makes me scratch my head when people put up applications giving huge details to user layout(Something I quite jealous of) But often turn blind eye to Login Security of form. It’s often said that security is as good as weakest part of system. And for most people Login is most insecure.

Let’s now break them one by one. Note that they should be followed in sequential manner , you can jump any suggestion to follow next one , but latter’s may security depend on former’s implementation.

First of all add SSL, please add SSL if your login has no SSL then it’s very bad for your application security.  They don’t cost much and they are really deterrent from preventing malicious ears to listen to chat between user’s system and our servers.

Add reCaptcha as poor but still secure way of preventing against brute force attacks. Though this may qualify as user interface hindrance and rightly so as you dont see most of websites doing so. Way most of good sites do is add cookie or CSRF token which validates life of login. If it sees that token is invalid then login is simply discarded. I absolutely hate those captcha logins, they totally use to hinder the User experience. Plus they were not good against bots. Still I would say that adding reCaptcha  has two advantages

1. It’s hard against bots and not humans. Normally it’s just picking up similar images from group of images which humans are good at.
2. You can depend upon Google to have it secure.

Ok so far add SSL against packet sniffing and reCaptcha againts brute force attacks on login. Note that if user’s credentials don’t match then it’s step 1 again. Now shall we show them the password in case of failed login. I guess that’s all right. But it should be shown on request of user. After all computers can do nothing against prying eyes(yet!). I love the way amazon does this one. Note that at this stage we have added one layer against Brute force. But what if it’s the user that is trying to guess the password and he has some rough idea about password. I mean if the previous  password is  say RonLovesMagic1234 and new password is RonLovesMagic4321. Then it may not take much time to guess the new password. So good way to do it’s simply irritate the end user if multiple passwords fail. Way we do on our systems is following

1. Up till 3  failed password attempt do nothing.
2. On 4 password attempt give pause of additional 3 seconds before he can try  .Reasoning behind it’s simply lack of patience in humans. Though you can do it via frontend we suggest using backend. As frontend’s javascript can be edited.
3. Once he reaches 10 password fire up email to user notifying about failed login attempt and IP of source. Also block the user login for some duration(How much that is still debate at our office)
4. Fire up another email to end user having the link which will login the user.

As for password complexity I suggest having look at this and this . But in gist have longer passwords. Also if you have want to generate the password, use Last pass password generate.

reCaptcha not Captcha

Ok now we come to last part of login that is what to do if login is correct. I admit I am still learning the ways to do it. So my way could not be fully secure. So please advice. Firstly use JWT tokens (if can) . They remove the burden of using session cookies on your server. JWT are amazing.  They are basically are hashed strings containing user id , token expiry ,salt and other payload data and meta data. But then again not using JWT wont cause thermo nuclear war. You will return some token in any way to authenticate future communications to server. Let’s talk about that token.
What is the life of that token? Can it be used by some other person? If you can narrow it down to around  6hours without remember me and 24 hours with remember me.( users with administrative powers should be less than hour then again we are still trying to find the optimal time frame) . As for masquerading attacks follow login way. Email the user , lock out attacker.

Have logs. Log everything ,go hard on loggers just like Google. We save every login (failed or success both) and then admin can have look at them. Normally things we want logged are  source IP, difference of time between logins and finally login result.
So these are basic tasks I suggest to secure login. Let me know if you have anything to say. As always Live Long and Prosper.