coding, security

OAuth and Spring Security

While Spring Framework – and in particular Spring Security – provides many ways to deal with authentication and authorization, there are some new approaches that are becoming increasingly popular. As in most cases, the requirements of the cloud along with that of mulitenant applications have been the driving force of this evolution.

For example, while SSL is definitely a secure layer, many (if not most) home grown applications simply do not want to pay for a signed certificate (even less in face of the fact that such a certificate is mostly restricted to a single domain) and, thus, simply do not use SSL. Of course, this is worst, but still common practice.

Also, basic authentification is, presumingly with respect to its simplicity, still widespread. However, basic authentification in combination with a non-secure transport layer is a security black hole.

And finally, with SaaS rising, comfortable single sign-on in a multitenant environment must be considered in modern software design. Latter issue, cloud based single sign-on, is supported by the Spring Security (see ref. manual).

There are some more requirements emerging from the evolving cloud: for example, RESTful web services as part of asynchronous data transfer need to be secured on user level. While such scenarios can definitely be realized with the Spring Security, it definitely focuses on securing classic synchronous data transfer and flows (for instance, I would rather not choose Spring Web Flow to implement the flow of an highly AJAXian web application). In order to implement flows based on highly asynchronous communication between the client and server, there is definitely some hacking to do (see e.g. this tutorial).

However, the most important issue in times of millions of home grown smartphone apps is sharing credentials with such a client. Using same password over and over again, because you cannot remember millions of different passwords? Of course, this is worst, but still common practice. Now, what if your credentials are misused by your app? Wouldn’t it be much better, if you would not share your credentials with the client at all?

OAuth is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications. It has been developed with most of the issues that emerged from cloud-based authentification and authorizastion in mind. Furthermore, it is being used by global players like Digg, Jaiku, Flickr, Twitter, and developers of OAuth are hopeful to see Google, Yahoo, and others soon to follow. With so many heavy weight service providers relying on OAuth, it may definitely be considered as quasi standard. Unfortunately, Spring Security is not (yet) shipped with out-of-the-box support of OAuth, although I am pretty sure that the extremely capable Springsource team will deliver Spring with OAuth support as soon as possible.

For those who cannot (and should not) wait, a promising approach is described in OAuth for Spring Security. The purpose of this project is to provide an OAuth implementation for Spring Security. I have tested their implementation, and hereby I strongly recommend their approach. For me, the most striking advantage of this design is the combined power of both, OAuth and Spring Security. While you still have the comfort of Spring and its AOP framework, you have implemented the security of OAuth.

Advertisements
Standard
coding, security

Preventing SSH Brute Force Attacks

I’ve been looking for a way to prevent ssh brute force attacks. Although they are not particularly dangerous if you have prohibited password login (which you should have done under any circumstances), they had been spamming my log files. Asking the almighty search engine for relief, I found a number of interesting articles about attack blocker, such as DenyHost.

I’ve just installed the package on my private OsX server via MacPorts. However, it took me a while until I found the installation location of all required files. After having touched /etc/hosts.deny (the file used by denyhosts to store suspicious ips for tcp_wrappers to block them), copied /opt/local/share/denyhosts/denyhosts.cfg-dist to somewhere reasonable (e.g. /etc/denyhosts.cfg), modified it to my needs (added E-Mail etc.), I was able to test start DenyHost with:

sudo /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/denyhosts.py --config=/etc/denyhosts.cfg

I’ve got a nice email telling me that, deducing from my /var/log/secure.log some IPs were now added to hosts.deny. Furthermore, some interesting data have been stored in /opt/local/share/denyhosts/data.

However, I prefer DenyHost to be running in daemon mode and to synchronize with data collected from the cloud, so I inserted  SYNC_SERVER = http://xmlrpc.denyhosts.net:9911 into denyhosts.cfg and started DenyHost with some additional options:

sudo /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/denyhosts.py --config=/etc/denyhosts.cfg --sync --daemon

And now I feel much more comfortable now.

Related Links:

Standard
security

Microsoft Security Essentials: Free AntiVirus and AntiSpyware Software by Microsoft

Finally, Microsoft has released a free Antivirus and Antispyware Suite. It is running on my notebook with Windows Vista and I am quite confident. Actually, it has replaced the Security Suite I had been using until now.

The Suite can be downloaded for free at:

http://www.microsoft.com/Security_Essentials/

BTW, I just learned, that installing Windows Security Essentials will either disable (Vista/Win7) or remove (XP) Windows Defender. Defender is no longer required, because it is being replaced by WSE. However, you really should check if Defender is really disabled/removed. If not, do it.

Standard