Spring Security by Craig Walls

Craig Walls presented the Spring Security Session at the latest NFJS Java Conference in Seattle.

What ACEGI Offers?

- Declarative Security, keeps security details out of your code

- Authentication and Authorization, against virtually any user store

- Support for anonymous sessions, concurrent sessions, remember-me, channel enforcement, and much more

- Spring-based, but can be used for non-Spring web framework

ACEGI's moving parts:

- Security Interceptors, aspects for methods, filters for servlets

- Managers, Authentication, Access Decision, Run-As, After-Invocation

- Authentication Providers

- Access Voters

Security Intercepter - First line of defense

Authentication Manager - Verifies user identity 

Access Decision Manager - Determines if the authenticated user has authority to access the secured resource, by aggregating the result from the Voters

Run-As Manager - Temporarily replaces user's Authentication object for the duration of the current secure invocation

After Invocation Manager - Reviews the object returned from a secured invocation, allows for 'after-the-fact' security

The problem of ACEGI

Every time you use Acegi... A fairy dies... It's a great framework but is very hard to use.

- Lots of moving parts

- Lots of options

- Everything is a <bean> with various options injected with <property>

- Requires lots of XML

Spring Security 2.0

- Released last week (Apr.15th)

- All the Same goodness with some new stuff with much less XML

- Provides a new security configuration namespace for Spring that hides <bean> <property>

- Provides auto-configuration

Method Security

- Intercepting method using Spring AOP

- Or, Annotation Driven

1.5 & 2 Factor Authentication

1.5 factors:

The Grid data solution:
http://www.brianmadden.com/blog/iForum07/Grid-Data-Security-introduces-really-cool-15-factor-authentication-for-Citrix

Passmark Security's (acquired by RSA):
http://www.rsa.com/node.aspx?id=3072

2 factors:
http://en.wikipedia.org/wiki/Two-factor_authentication

However, don't trust these too much because 2 factor authentication does not work:

http://blog.washingtonpost.com/securityfix/2006/07/citibank_phish_spoofs_2factor_1.html
http://www.schneier.com/blog/archives/2005/03/the_failure_of.html
http://www.vnunet.com/vnunet/news/2139253/two-factor-authentication
http://www.channelregister.co.uk/2005/03/15/2-factor_auth_is_pants/
http://www.cafeid.com/art-sitekey.shtml

Man-in-the-middle attack:

An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank's real website. Done right, the user will never realize that he isn't at the bank's website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user's banking transactions while making his own transactions at the same time.

Trojan-horse attack:

Attacker gets Trojan installed on user's computer. When user logs into his bank's website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

To fight these type of attack:

The problem here is that the bank's website doesn't authenticate the message source. The attacker's computer sends the transaction request to the bank, and the bank trusted it blindly during and after the authentication process. The message source, i.e. both the hardware and the software sending the message, must include itself as part of the authentication token as well as in the following transaction requests.

In the trojan-horse attack, the trojan software is not the original software that generates the request. It will try to generate the exact same transaction request the original software will be generating, but ultimitally, it is still not the original software and cannot predict the behaviour of the original software in a full scale. As long as the original software is properly protected against reverse-engineering and have a way to generate some ever-changing additional piece of information that the server can use to validate it's authenticity, (better, this piece of information has something to do with the transaction request itself), it makes it more difficult for the trojan to generate his own transaction request for his own benefit.

In the man-in-the-middle attack, the hacker does not own the user's computer, he cannot overcome this obfuscate without physical involvement. Serial number of the CPU of user's computer? MAC of one of his network card? Some secret signature on user's hard-disk? The problem is that the cient and the server must, separately, has a way to obtain this piece of information independent of each other. This can be quite a difficult problem.

In case of http request, one way I can think of is to use the REMOTE_ADDR cgi variable. Server can get this from the http header, client can get this, by performing a lookup to sites like
http://www.whatismyip.org/ or some similar service provided by the bank.

The client can use REMOTE_ADDR to salt the authentication token as well as future requests. The server can decrypt it using the REMOTE_ADDR variable in the request. Thus, if the man-in-the-middle intercepted the communication and try to relay it to the server, the authentication will be invalid because the REMOTE_ADDR is different as in the original request.

In order to defeat this, the man-in-the-middle will need to not only intercept the communication to the bank, but also to intercept the client's request to get the REMOTE_ADDR and respond with the REMOTE_ADDR of the phishing website. This will require a network device very close to the user's computer, and is quite difficult for most phishing sites.

Another method the man-in-the-middle can try is to decrypt the communication and re-encrypt it with his own REMOTE_HOST environment setting. The way we can fight against this is to use a strong encryption algorithm that needs some good amount of time to be defeated. Thus, by the time the communication is decrypted and re-encrypted, the ever-changing part is already invalid and useless. RSA? SHA? RIPEND? http://www.keylength.com/

Do they work?

Unfortunately, the above solution also does not work. the attacker, being his first step, is to analyze the site/application he's going to phish, and because of the openess of the web page, any code generating the hardware/software identification token will be discovered sooner or later, and he'll incorporate them in the phishing website/trojan software. It'll be more difficult for him if it's a obfuscated standalone application and/or webpages with their source code protected (http://www.antssoft.com/htmlprotector/index.htm), but not at all impossible.

EHCache Singleton CacheManager

Here's the problem, when we enable the hibernate secondary cache using org.hibernate.cache.EHCacheProvider, and enable ACEGI user cache using

<property name="userCache">
<bean class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache">
<property name="cache">
<bean class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<property name="cacheName" value="AcegiUserCache">
</property>
</bean>
</property>
</bean>
</property>

They belongs to two different cache manager.

Instead of have to configure 2 different cache manager separately, have to have separate cache invalidating thread etc, we can fall back to the EHCache Singleton CacheManager.

hibernate.cache.provider_class=net.sf.ehcache.hibernate.SingletonEhCacheProvider

Now ACEGI will use the same EHCache CacheManager. They can be configured in the same ehcache.xml file. Yup!