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.

  • I'm not entirely sure what your question is here. "Breaching the software itself" includes getting access to usernames, passwords, and injecting code, so I'm not sure what you are getting at here. Also, pitfalls about what? – schroeder Jul 7 '17 at 12:29
  • Pitfalls about coding your own user authentication system rather than using Spring, Shiro, or JAAS. When I say "breaching the software" I mean specifically the part of the software that is given a username and password and then checks to see if those credentials are authentic, and if so provide authorization data. Do hackers trick the authentication piece itself, or is it more about finding other ways to obtain the username and password and then provide the stolen credentials? In other words, if user auth is a locked door, do hackers break down the door or simply steal a key? – Marcel Marino Jul 7 '17 at 12:42
  • Hackers find the most convenient weakness. Wherever that is. I've seen hackers target the auth system. Using a known package helps you not code the weakest part of the system. – schroeder Jul 7 '17 at 12:45
  • Are you saying the the user auth is the weakest part of the system? Could you give me an example of how a hacker would exploit the user auth code itself? – Marcel Marino Jul 7 '17 at 12:46
  • 1
    I'm not saying that. I'm saying that hackers find the weak parts. Sometimes the weak parts are the auth system. Here's a list of known Shiro vulnerabilities in the past: cvedetails.com/vulnerability-list/vendor_id-45/product_id-20193/… – schroeder Jul 7 '17 at 13:11

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

  • The Shiro documentation is complete enough for limited programming using ini files and such, but advanced stuff isn't well documented due to its open source nature. Perhaps it is an issue with using Glassfish, but whenever we try and set a realm, that realm gets stuck for any later applications that get deployed. Since I can't see what's going on behind Shiro there's not much I can do to to fix it. I've posted on a number of forums and have not received much in the way of help, so I'm at a loss on what other actions I have the ability to take. Does that make sense? – Marcel Marino Jul 7 '17 at 17:06
  • Are there any exceptions being thrown or errors? – Thomas Carlisle Jul 8 '17 at 12:50

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.

  • Specific to your case, this will slow down updating the version of Shiro that you are using. (You'd know that having the latest version of a security software is very important). Every time a new version comes out, you would have to first test if your classes still work or not. If not, then you'll either have to fix it or replace it or remove it – Limit Jul 7 '17 at 18:07

Your Answer

