Self-Coded User Authentication Security

Question

We are currently using Apache Shiro for our User Authentication needs. We have dynamic authorization\authentication needs, in some cases users will be authenticated using Active Directory while some will be authenticated using JDBC, but all users will be authorized using JDBC.

Shiro has proven up to the task, but not well. It does work, but only sometimes. The programmatic realms I've created don't seem to run the same way each time. Sometimes when attempting logins several times it will fail, only to eventually succeed. This is the exact same request with the exact same data. Debugging shows that sometimes it simply doesn't call the necessary functions to get the authentication or authorization data. Restarting the instance will usually fix this, but only for a time. It also seems to have a serious problems with multiple shiro applications existing on the same Glassfish instance.

As such, Shiro seems to be not be tenable choice especially given how little documentation exists for it. I am already overriding Shiro's methods to tell it exactly how to get the data, so I'd like to simply code my own java user authentication classes.

Currently the best argument I've heard against this is that a custom-coded system will not be as secure as an industry standard one. However from what I've read online and been taught in class, most hacking attempts focus on gaining access to usernames and passwords, or figuring out how to send rouge code into the system. Most methods don't actually breach the software itself; it basically just checks whatever data is provided and as long as all inputs are sanitized the user authentication software itself isn't usually the problem. Is that assessment accurate?

Also, are there any pitfalls I should be aware of? I understand there are other options like Spring Security or JAAS but since I already essentially have the system I need built inside Shiro and only have to remove it from that software, it seems to be the best option would be to use that at this point in the development cycle.

Answer 1

Software developers tend to get exposed to just the tip of the iceberg of credentials and authentication because 98% of the application involves the business logic the app involves and only 2% of the application is handling user authentication. Authentication schemes need to be able to thwart attempts of brute force cracking, intercepting the network communications, man in the middle, etc. and many more ways to break into a closed system. In addition to authentication, you also have to ensure that the user session, once authenticated, works across the app and is secure, e.g. session can't be hi-jacked, etc.

All of this is what Apache Shiro is handling for you, and while I don't have hands-on experience using it yet I am unable to find claims of unreliability, bugs, etc. If it were me, I'd focus on figuring out where the unreliability is coming from and resolve that instead of rolling my own. Because even if you do it right and it is "secure" by today's standards, that doesn't mean it will still be considered secure a year, three, or five years down the road. You will always have to remain knowledgeable of developments in the security/cracking space that develop over time which may put your authentication methodology at risk, update, etc.

The documentation set looks pretty good: Apache Shiro Documentation

Answer 2

Then answer depends on how critical is the system that you are developing. If it being cracked doesn't have a huge impact on your business then you are fine. If it does, then this answer is relevant to you.

When you roll your own security system, you are the one responsible for ensuring that it is actually secure, reliable and continues to be so till it is retired.

Suppose you devised your own Authentication system, you would have to go ahead and do proper penetration tests against it and also ensure that all the systems which it would interact with are compatible with it. (Once you develop a system, the expectation would be that future tools related to this one will use your authentication system as it is something already in use).

Once you have released version 1 of this system, you would have to go through this for every new vulnerability found in libraries/logic that you are using. Also, all the future releases will have to go through this process.

Using a system which is already in market and open source, takes this responsibility away from you. That is one major advantage that businesses see in using something that is already in the market.

TL;DR: If you roll your own security system which solves a problem which has already been solved by others, you would essentially have spent a considerable amount of time developing something which would require a considerable amount of time in the future instead of spending considerable amount of time now and small amount of time in the future.