Building a case for a Two Factor Authentication Model

Two Factor Authentication (TFA) has been around for quite some time and one gets the idea that it must be important if big names like Apple, Google, Facebook and Twitter are using it. Banks use it to authorize payment transfers and limit changes. While on one hand, it adds another level to the authentication mechanism and slows down the transaction, it definitely makes the possibility of a hacker taking control of a system harder.

While implementing a TFA is not hard, the main issue with implementing a TFA model is recovering the login as the recovery mechanism usually bypasses the TFA model. However inspite of the complexity, I feel that that TFA is a must in cases where a user needs to VPN into the corporate network. While user tokens such as RSA's SecurId have been cracked, bio metrics might be the missing link in setting up a secure and relatively reliable model of TFA.

Securing Fedora Commons 3.6.2 with XACML Policies.

The Flexible Extensible Digital Object Repository Architecture aka Fedora Repository uses XACML  based policies for authentication and authorization. XACML is an XML based policy language that is used to define access control lists and secure applications using a standard policy based approach.
The latest release of Fedora 3.6.2 promotes  the JAAS based FeSL as the default security layer. FeSL which was introduced in 2011 is designed to improve upon the legacy XACML based security scheme that has been Fedora's backbone since its release. While FeSL simplifies security, XACML still retains its relevance in terms of managing and setting up access to the API-A and API-M interfaces. The API-A interface provides a read-only access to the repository's properties and its objects. API-M on the other hand enables management of the repository and allows edit access to the contained objects.

While Fedora ships with a basic set of XACML policies that provide a basis for securing access to the two interfaces, there will be scenaros when authoring a custom policy will be required. When attempting to write the policy writing guide is a good place to start. XACML policies are rule based and generally enforce either an PERMIT or a DENY result to a specific resource. Apart from these two results, there are the the Not Applicable and the Indeterminate results too.
When attempting to understand the application of the policies and the final results that are generated, the two key points to take away is that the DENY rule supercede's the PERMIT rule.  For example, if an administrator is PERMITTED to access the API-A interface but there is a DENY rule on a specific API-A operation that applies to all users including the administrator, then the administrator will not have access to that specific operation.

Secondly, access to a resource has to be explictly granted.  For example, if there is a DENY rule that limits access to the API-A interface to all non-admin users, it does not explicitly imply that administrators will be able to access the API-A interface. There has to be a PERMIT rule that gives them that access. Thus, while designing policies, do remember to check out section 3.3 in the policy enforcement guide. It might save you hours when you are trying to figure out why a certain user cannot access an interface !!

An Integrated Security Framework for Mobile Agent Communities

Open publication - Free publishing - More security

Integrating Spring Security with Active Directory on JBOSS 4.0.5

Spring Security (formely ACEGI) is a fairly robust and flexible framework that fits in well with a J2EE solution stack. Some of the main features that made us choose Spring was its flow transition authorization policy and its database backed 'remember me' implementation.
Based on this, we decided to use Spring Security 2.0.4 on a JBOSS 4.0.5 server. The Spring component authenticates and authorizes a user against a Active Directory through its LDAP authenticator component (org.springframework.security.providers.ldap.authenticator.BindAuthenticator) and authorize the user using its LDAP authorities search classes (org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator & org.springframework.security.providers.ldap.LdapAuthenticationProvider).

The important thing to remember is that Spring security matches a group name with the prefix "ROLE_" so if you have a user belonging to a group called "PG_JAVA_DEV), it would get mapped as ROLE_PG_JAVA_DEV within the security context. You can get more information on how the Spring security LDAP component works in Chapter 10 of the Spring Security guide.A detailed example of how to set up Spring Security to talk to the Active Directory is given here.

To set up Spring Security, you will need Spring Security 2.0.4 and Spring LDAP 1.3 (which has some additional dependencies mapped in them).Just map these to your Maven POM and you'll be good to go.

Banishing the Vundo Trojan

If your browsers have started playing up and are opening up new tabs whenever you Google something and these new tabs in turn are redirecting themselves to random sites that you in your normal sense would never visit then chances are high that you are a host to the Vundo Trojan. While the infection appears to stem from a vulnerability in Java 1.5.0_7, I found the infection on a system that was running a much more advanced version (of Java) and so it is highly probable that a new loophole is being exploited.

On the infected machine, Vundo was able to infect and control the behaviour of Firefox, IE and Chrome. An annoying symptom of the infection was random popups and new windows that redirected themselves to mad-search.com(?) and forcibly tried to install AntiVirus 360 (what's that??) on the machine. The key diagnostic tool that was able to catch these infections was PC Tool's SpyDoctor but since the FREE version only performed a scan and required a paid version for the removal, I tried MalwareByte's Anti Malware version 1.31. This tool successfully located and removed the infections. So if you are facing the same problem, head down to MalwareByte and try out the tool but be aware that the tool only locates and fixes existing infections. To guard against getting infected, keep your SpyDoctor's IntelliGuard setting ON.

Security in Enterprise 2.0: Building a case for Security 2.0

While reading up on the security concerns highlighted in this article from the NY Times, I could see many E2.0 evangelists shaking their head in despair. The recent attack on Google /Orkut's network that compromised close to 400,000 users within a few hours is going to scare people even more.

Web 2.0 and Enterprise 2.0 is all about 'opening up', sharing information, communicating and collaborating. While the latest breed of techies are seeped in blogs, wikis, chat programs, Google docs and social networking sites, traditional firms continue to rely on the good 'old' trusted means of 'securely' disseminating information via emails and file attachments. The idea of sharing company documents that may have client names, sales figures on websites (yeah, Wikis are glorified websites) appears appalling to the senior management. Security concerns are always brought up when someone talks of adopting an Enterprise 2.0 outlook and many cases, these concerns are justified.

My attempts to Google the term "Security 2.0" bought up an interesting post which talks about the author's attempt at Googling 'Security 2.0" in October 2006 and his thoughts on what security 2.0. I can tell you that on today's date, my Googling attempts did not give me much either. Around the same time, Symantec spoke about bringing out Security 2.0 products but to me, the vision looked a lot like anti-virus packages bundled up in a new name.So where are we with Security 2.0?

The secure Enterprise 2.o forum and the ongoing E2.0 conference are good starts towards fostering dialogues between the participants of E2.0. Currently security in an Enterprise 2.o setup is limited to policies and mainly role based authentication but unless some convincing protocols are not established with regards to securing information management in an E2.0 setup, Enterprise 2.0 will not attain its goals of 'open communication and collaboration'.

Securing your Web-App:The WEB-INF story, FORMS, JBOSS and JAAS

Securing your web application is a multi-step process and requires careful planning.If you are not careful, you can end up leaving the application vulnerable to hacker attacks or lock yourself in and throw away the key which is what happened to me recently.

I was securing a web application that was to be deployed on JBOSS. Taking the first step in security, I placed all my web-resources in my WEB-INF. Good move.No. Bad move.Yes.
It was a good move in the sense that by placing every resource under WEB-INF, I was securing them from being accessed externally, i.e no one could get to them unless they pretended to be a servlet call. I had locked myself in and thrown away the key. Hang-on what if I got to a resource as an Authenticated subject. Yeah, you could. I redeployed the application and pointed it to my login.jsp that was sitting in the WEB-INF under a pages directory. It worked fine except for one thing. My login.jsp requested a style-sheet and try as much as I could, I could not get it to load. That was when the lightening struck.

The call to load the stylesheet was a new request being made before the authentication process had completed and of course the WEB-INF would bar the request. I moved my jsp pages, stylesheets, images and scripts out of WEB-INF and secured them using security tags defined in the web descriptors.

Securing web-resources placed outside the WEB-INF folder is carried out using the web.xml and your server specific descriptor. Access to web-resources is granted based on user-authentication and authorization policies. These policies are user role base.

To secure your web-resource folders in JBOSS, follow this tutorial or follow this link in the Sun Forum. Both tutorials are very succinctly written and bring out the salient features required to configure and set up security in JBOSS. If you are after WebLogic, then this guide will be useful. It also describes FORM based authentication in sufficient detail which is what most web-applications are based on.

Well, there you go! Enjoy locking yourself in but don't throw away the key...yet!!

Jumping Folders : A new security paradigm

I believe that

• 'Every object should be able to secure itself against malicious access by another object.'
• 'Randomness in object behavior can be an effective approach in securing themselves against malicious manipulation'

Jumping Folders is a proposal to secure folders and thereby contained Files from malicious access by introducing a default security behavior at creation time. The 'security behaviour'proposed is based on the premise that all objects exhibit a set of repeatable patterns in response to certain pre-defined stimuli. For example : If you double-click on windows based file or folder, it is 'normally' expected to open up.

What if I want to secure the folder or a file? The 'normal' (I keep emphasizing the term 'normal' for a specific reason,

which I will make clear shortly) options available to me could be :
1. Hiding the folder.
2. Preventing access to the folder by encrypting it with a password or even better encrypting the contents of the folder.

But what are we doing here:
We are using some well known and defined services available to us to 'seemingly' secure the contents of the folder. These services are provided by the OS (windows) and can be configured at different levels (users, groups, roles and all that)

Perhaps you must be thinking.Is there an option? The OS is the RingMaster. He or She cracks the whip and the performers jump but what if someone kills the RingMaster or even worse uses the identity of the RingMaster to manipulate the performers. You would perhaps say "Too bad" or "who cares about petty performers, get another one" and that is how Life goes on. An object is destroyed and we create another one to replace it.

Isn't that just what humans do.People are born, they multiply and then they die and sometimes die due to unnatural causes.

Jumping Folders is a proposal to inject a security element within an object (in this case, a folder) at creation time. The security element enables the folder to 'use' the services offered by the OS and behave 'abnormally' on certain stimuli.
Services in this case is refers to the windows cut and paste operations. stimuli is a mouse double-click. The 'abnormal' behaviour in this case would be 'cutting and pasting itself' at a different location on the file system.

Ahh..now we know, the reason for my stress on normal and abnormal behavior of objects.

Thus, we have an object (the folder) that is intelligent enough to recognize a malicious intent (double-click) and protect itself by copying itself to another location.

So what if you want to see the contents of the folder.

Well, you could use a combination of a certain sequence of mouse-clicks and key-strokes to override the abnormal behavior. Why mouse-clicks? so you can get over a key-logger that is monitoring your keyboard operations.

In conclusion, Nothing is secure and we don't really need to be paranoid about security. Jumping Folders is a project proposal that give secures objects based on their randomness, so now don't let anyone tell you that randomness is bad :-)