I spent about a day working on things before I discovered that I really should be using the Seam framework’s Identity Management feature.  So I threw out everything I’d done, and started by re-reading the docs, and went from there.  Seam’s Identity Management framework is VERY powerful, but is also a little complicated to get going and in many cases it seems like it would easier to just write stuff from scratch.  I’m banking on the powerful stuff being worth the initial learning curve and a little extra pain.

When I get the starter project in a more complete state I will be open sourcing the whole thing to help others along, but I wanted to share a few things I’ve learned so far:

In order to use the Email address as the login instead of a username, you need to remove the username property from your UserAccount entity and annotate the Email address property like so:

@NotNull
@UserPrincipal
@Email
public String getEmail() {
    return email;
}

Actions like Registration need a RunAsOperation inner class to handle the fine grained security controls that the Identity Management framework enforces:

    public void register() {
	verified = (confirm != null && confirm.equals(password));

	if (!verified) {
	    FacesMessages.instance().addToControl("confirmPassword", "Passwords do not match");
	}
	new RunAsOperation() {
	    public void execute() {
		try {
		    // Check if email address has already been used
		    if (identityManager.userExists(getEmail())) {
			FacesMessages.instance().addToControl("email", "Email has already been used.");
			return;
		    }
		    identityManager.createUser(email, password, mFirstName, mLastName);
		} catch (IdentityManagementException e) {
		    // TODO Auto-generated catch block
		    e.printStackTrace();
		}
		identityManager.grantRole(email, "member");
	    }
	}.addRole("admin").run();

	// Login the user
	identity.getCredentials().setUsername(email);
	identity.getCredentials().setPassword(password);
	identity.login();
    }

Populating custom properties on the User during things like registration requires observing events:

    @Observer(JpaIdentityStore.EVENT_PRE_PERSIST_USER)
    public void prePersistUser(UserAccount pNewUser) {
	// Setup additional UserAccount properties before the user is created
	pNewUser.setRegistrationDate(new Date());
	pNewUser.setOptIn(isOptIn());
    }

You can log audit events with the user’s IP address by doing things like this:

@Scope(ScopeType.EVENT)
@Name("userEvents")
public class UserEvents {
    @Logger
    private Log mLog;

    @Observer(JpaIdentityStore.EVENT_USER_AUTHENTICATED)
    public void loginSuccessful(UserAccount pUser) {
	mLog.info("User logged in with email: #0", pUser.getEmail());
	pUser.setLastLoginDate(new Date());
	Contexts.getSessionContext().set("currentUser", pUser);
	AuditEvent loginEvent = new AuditEvent(((ServletRequest) FacesContext.getCurrentInstance().getExternalContext()
		.getRequest()).getRemoteAddr(), pUser.getId(), "Login Success", null);
	Events.instance().raiseEvent("auditEvent", loginEvent);
    }
}

Hopefully I’ll have the starter project ready soon and will share it with you all. In the meantime, happy hacking!

image from Purpleslog

I’m happy to announce that Spark::red ATG Hosting has received our PCI DSS 1.2 Level 1 Certification as an eCommerce MSP.  We have been Level 2 certified for a while, but completing our Level 1 certification with TrustWave as our third-party auditor is a huge milestone for us.

PCI DSS is the Payment Card Industry’s Data Security Standard.  It is a set of requirements and guidelines designed to ensure merchants who handle or process credit cards, do so securely.  There are different levels based on transaction volume and Level 1 is the highest level, required for the largest volume merchants.  Level 1 is also the most difficult certification to gain, requiring the strictest security protections, the strongest policies, and a very in depth audit by a certified auditing company, such as TrustWave.  Our certification process has taken many months and the completion of our Level 1 Report of Compliance (RoC) is a testament to our dedication to providing the highest level of secure environments to our clients and safeguarding their systems and information, as well as the information of all our clients’ customers.

At Spark::red we focus strongly on Security and Performance beyond the core ATG hosting services.  We handle more PCI DSS requirements than any other ATG Hosting provider out there.  If you are looking for an ATG Hosting provider to help manage your ATG web application, we can offer PCI Level 1 compliant hosting and handle many of your security needs.

A VPN, or Virtual Private Network, is basically a secure encrypted link from your computer to a computer or network somewhere else.  Your computer then routes some or all of it’s network traffic over that encrypted link.  Typically they are used to get access from secure private or corporate networks from remote locations.  Your company might have you using a VPN, when you’re working from home, to access the corporate file server, SharePoint, SVN, etc…

Why Should You Use a VPN?

Wireless networks are more and more ubiquitous.  You’ll find WiFi at your local coffee shop, book store, McDonalds, and more.  WiFi is amazingly convenient.  It’s lets us stay connected and work from anywhere.  Unfortunately it is also typically insecure.  All your internet traffic is flying around through the air, and anyone can see it.  Many WiFi networks use various types of encryption to protect your traffic, however most of those encryption mechanisms aren’t actually that secure.  The technology to break the encryption easily has been around for a while.

Recently it’s been made ten time easier:  A new Firefox plug-in called Firesheep automatically captures wireless traffic, and presents clickable buttons which allow you to hijack (take over) other people’s sessions on common websites such as Facebook, Twitter, and more.

Even if you use SSL/HTTPS for logging in, many websites pass the session cookie over subsequent non-secure/non-SSL requests

If you are using Wifi in any public location, you are potentially at risk of having your sessions and passwords stolen.  Using a VPN prevents this by fully encrypting all of your network traffic between your laptop and a secure server somewhere far away from the insecure WiFi network.

Fact: Everyone who uses WiFi should be using a VPN to protect themselves.

So How Do I Get a VPN?

In the past setting up a VPN was usually a mix of expensive commercial products and complicated technical configurations.  That’s why usually it’s only large companies which use them.

Today there are much cheaper and easier options.  One example is Golden Frog’s VyprVPN,  a Personal, private and secure VPN.  It’s a very affordable, easy to setup, VPN solution.  I use it whenever I’m at the coffee shop or on pubic WiFi networks.  I strongly recommend you check it out, or another similar service.  This is a very real privacy and security threat.

In this newsletter we talk about the importance of improving your site performance, especially now that Google is using site performance as a search result ranking factor. We talk about Why, and provide several helpful links to help with How. I’d be remiss if I didn’t plug the fantastic ATG Hosting that Spark::red can provide, including extensive performance tuning at every level, web, app and database, using knowledge gained from 12 years of ATG experience.

We also reveal our PCI Compliant ATG Encryption Module which is the first PCI complaint credit card encryption option for the ATG eCommerce Platform. It handles strong encryption, key management, importing plain text and encrypted data, periodic re-keying/re-encryption, and more. It’s the fastest and most affordable path to being able to pass a PCI audit for your ATG eCommerce application. Contact us for more info: sales@sparkred.com.

You can see the whole newsletter here: Spark::red ATG Newsletter #1, and if you haven’t already, I recommend signing up so you don’t miss the next one: Sign Up for the Sparkred ATG Newsletter!

Which sounds good as I was wondering if there was stuff I could be doing with layout or ad types to help increase clicks, except this was from a random guy at a gmx.com address, with no company name. Googling his name and e-mail address turned up nothing. So I replied asking for his company info or references, etc…

Sorry, but our company has no web
site.
You will easteablish our credibility during partnership with us.
Lets just try it first, ok?
Put this code between the body tags on your 10minutemail.com
main page only:
<img src=”some russian site” />
It is an 1*1px transparent image.

Supposedly after I do that I’ll see the result in a couple of days.

So wow, little warning bells are now big warning bells. Adding a web bug can’t impact your Google adsense revenue. Adding a web bug to your site from a domain name with no website that’s registered by someone in Russia seems like a TERRIBLE idea! So of course I said no.

What do you think? Some sort of XSS attack, or cookie attack? I’m just not sure what the end game would be on this…

I have NO IDEA why anyone would be attacking 10MinuteMail. It’s very odd.

As is the case with many companies that maintain large databases of information, Monster is the target of illegal attempts to access and extract information from its database. We recently learned our database was illegally accessed and certain contact and account data were taken, including Monster user IDs and passwords, email addresses, names, phone numbers, and some basic demographic data. The information accessed does not include resumes. Monster does not generally collect – and the accessed information does not include – sensitive data such as social security numbers or personal financial data.

The fact that the database was accessed illegally (no word on if it was an internal or external access) is a huge deal. However the fact that they stored passwords in either plaintext, or in a weak enough hash that they feel all the user passwords are compromised, is the most disturbing part of this news in my opinion.

There is no excuse for either of those security failures. Especially after the highly public loss of 1.3 million users’ data in 2007.

Assume that your database will be accessed at some point by someone with nefarious intent. If it can happen to Monster.com it can happen to you. Therefore you should not store passwords in plaintext or weakly hashed.

Use a salted SHA-256 or bcrypt hashing algorithm to protect your users’ accounts.

If you use ATG please check out the open source SecurePassword ATG module. It replaces the default insecure password hashing algorithm with a salted SHA-256 hashing mechanism. (as a side note I will develop a bcrypt version shortly, but SSHA-256 is very secure).

Some new easier exploits were recently published, and many DNS servers are still vulnerable. And up until the new exploits were published publicly, the majority of DNS servers were vulnerable. This situation is worse once you realize that “safe” DNS servers can be poisoned second hand by transitive trust relationships, allowing one compromised DNS server to effectually poison the caches of other un-compromised DNS servers.

DNS Cache Poisoning has been a serious issue for years. The recent flurry of press regarding the compromised AT&T DNS servers is just the tip of the iceberg. It is only reasonable to assume that over the past several years a large number of DNS server have been serving compromised results at some point, either by direct poisoning or indirect poisoning. It is also reasonable to assume that this will continue for the foreseeable future.

In light of this, please re-read my post on 3rd party Javascript.

If I were a malicious hacker, let’s say working for the Russian Mob, or for myself, here is the easiest way to make some money:

1. Create javascript files designed to mask Google Adwords, Google Analytics, Doubleclick Ads, Overture Ads, and maybe a couple others. These scripts would have their cache related response headers set to be cached on the browser for 1 year. These scripts would call back to the real versions of themselves (so that ads show up, etc…). They would also intercept any form submission events and would look for form fields with names like “creditcard” or “ssn” or “password” or “accountnumber”, etc… If any are found, it would essentially clone the form and send the form data, the site hostname and page, the client’s IP address and cookies, etc… to a server I control.

2. Start cache poisoning as many DNS servers as I could find that are vulnerable to point the REAL domains for those scripts to my malicious copies.

3. Sit back and watch the Credit Card numbers roll in.

The best part is that by getting the browser to cache the script locally, I only have to have a computer hit the poisoned cache once to control it for a whole year. On most IE6 installations it’s also easy to actually install a javascript application on the user’s computer.

Personally I use Google javascripts on my site. However I don’t capture credit card numbers here, so the risk is low. If you run an e-commerce site, please do not underestimate the risks involved here.

There was an example on how to integrate JForum and Crowd, which works pretty well. When you login to the forum, it checks Crowd and creates a local account if needed and logs you in.

However, we want single sign-on (SSO) so that our users don’t need to login to the forums separately. We also want group membership in Crowd to be reflected in JForum to allow us to manage permissions based on Crowd managed groups.

I’ve written a JForum SSO implementation that ties into Crowd that I’m going to share here. It’s version 1.1 (just added group sync), but it seems to work nicely.

Download the zip file here:
jforum-crowd-sso

unzip it into your jforum/WEB-INF/classes/ directory.

You have to install the crowd client jar, and the crowd.properties file.

You may also need to install the xfire jars if you get errors. I did.

Then you need to setup the sso configuration in the jforum/WEB-INF/config/SystemGlobals.properties

like this:

authentication.type=sso
sso.implementation = com.digitalsanctuary.jforum.CrowdSSO
sso.redirect = your crowd managed app login page
sso.crowd.syncGroups=false

That last flag should be set to true if you would like the user’s groups synced from Crowd to JForum at auth time. This takes a second, so I made it optional. It does not push JForum group membership info to Crowd, it just syncs Crowd data down, as Crowd should be your master directory for that type of data.

The source code is available here for now:

CrowdSSO.java

-EDIT-

Added a full downloadable module and installation instructions here:

http://confluence.atlassian.com/display/CROWDEXT/JForum+Single+Sign-On+Crowd+Connector