I was not keen on cryptography before this incident, so I was working on this PR for pagure where I had to write a feature which give the ability to local user to change the password. You can see the PR here. There are two ways to login to pagure FAS account if you want to use pagure online else if you are hosting it you can use local authentication. I learned a lot from this feature for starting “how not to write authentication system” that is because the first PR I sent was all about the wrong practices thanks a lot to Pingou and Peter to correct and guide me on how to do it.
Peter pointed me out to this video which cleared a lot of my questions. So some of the basic rules for writing an auth. system is :
- Never ever store password
- Always adopt the latest encryption technique
- Use constant time function to compare password
The technique we used is called salting, this is a very beautiful technique. Before going into salting we try to look into what is hashing because hashing generates a junk string using an algorithm, salting is just a different layer over it which makes this hashing more random. Hashing is a way in which password is converted into a string which cannot be inverted. Practically once you convert a string into hash there is no way you can retrieve it but the drawback is comes when two same string produce same hash string. Now if that is possible then it can be brute forced or rainbow tables can be used to get the password.
Here salting comes into the picture because with salting the entropy of the strings generated is exponentially increased and hence your site a little more secure because even you are storing password in your database even you can’t decipher the password all you see is a junk string. That makes your site secure and impenetrable.
Python comes handy with it, bcrypt is a library which give us a simple interface to use the functionality without getting into much detail.
Now here comes a tricky part we do not compare passwords directly we use something called a constant time function to compare passwords. The sole reason being the normal compare functions are written in such a way that the compare two strings as fast as possible which reduces their efficiency. When we are dealing with passwords accuracy is the most important factor not efficiency hence a constant time comparison function is used.
The PR evolved very organically and finally after discussing about various aspect we landed up writing test cases which exposed one of the vulnerability in the code. We fixed the error and then we went on to complete the PR, Pingou wrote most of the test cases and then after a lot of hard work and working for a long time the PR was finally complete. I even got my name in some of the files.