Notes on Nedu

Really quick one!

After a small break, online sign up is back on. We’ve added capacity to handle anything the tubes can throw at us, and have more waiting in the wings.

You are able to sign up now by following the links to the sign up pages.

Thanks to everyone who was patient enough to email us before they used the service. We hope we got you up and running without too much delay, let us know otherwise.

Thanks again!

Sorry peoples, we’ve had to disable the web based sign up facility for a little while. The problem is that we reliably tell how much load a specific new customer is going to place on the systems. Whereas web based email has a pretty uniform load across users, we’re finding that some of our new customers are using good slabs of capacity for good slabs of time.

Not that we have a problem with that. We love it. New customers doing lots of business is good, but we’re still working on ways to manage capacity so that everyone gets the best possible service. We’d much rather slow the sign up process a bit than inconvenience current (beloved) customers.

Our logs show that nobody should have noticed any degradation in performance, but if you did, please contact support and we’ll sort out some kind of reparations (after asking you a few painless questions, of course).

So, for the next few weeks you’ll need to contact our sales department to be signed up. There is a simple form on the sign up page that can be used to do that. We’ll be in contact with you within a couple of days and basically ask you what your daily average authentication volume is likely to be. Using that info we’ll work out how to best service your load.

Nobody will be turned away and nothing else will change. If you are an existing customer and you don’t get the wonderful service you’re used to, please let our support team know. We should be OK to turn online sign up back on around mid-April. Thanks for your support.

(P.S. We’d like to thank the OpenNMS guys for the terrific work they do - infrastructure nerds amongst you will understand what I am talking about)

Today’s announcement of the release of Google Sites is something that we suspect will be very good for Google. Whilst Google Apps without Google Sites is a solid offering, it was missing the foundation stone for collaboration. In traditional IT environments it used to be the shared network drive and email, but is now the enterprise wiki, intranet or other knowledge management system. In the SaaS space, the collaboration foundation stone is services like Google Sites.

So what does Google Sites deliver? Mainly the ability for people within an organisation to publish their work in framework that lets others use that work to solve problems. Using a piece of knowledge management theory, Google Apps (without Google Sites) helps to turn data into information and Google Sites helps to turn information into knowledge.

Ok, so why does a company that does Internet security care about that?

Knowledge management theory says that in the data -> information -> knowledge value chain, knowledge is the most valuable. We have been expecting phishers to start to target Google Apps for a while now, which is why we introduced Nedu for Google Apps. And so far, we haven’t seen the amount of nefarious activity we expected. But we think that the introduction of Google Sites could be the catalyst that draws the attention of the bad guys.

And we think this because Google Sites helps to turn information into knowledge thus bumping up the value of credentials that are needed to harvest that knowledge. The economics of phishing say that as soon as the revenue that can be generated from credentials significantly exceeds the cost of getting those credentials, you will see attacks occur.

We think that Google Sites will significantly increase the value of Google Apps data. Obviously so does Google, otherwise they wouldn’t have bought JotSpot and integrated it as Google Sites. This is good news for Google Apps users, but also an expansion of the market for phishers.

The challenge with all collaboration technology is to gain the benefits of being open, whilst managing the risks associated with it. That is how you generate ROI on your new collaboration investments, and that is what we’re here to help with.

This morning in my Google alerts, I found this blogposting. We don’t actively pursue the online-banking authentication market as it is saturated with competitiors and not really a good place for innovation.

Instead, we  focus on helping smaller sized organisations secure their login points. One of the ways we do this is by recognising that SMBs like to use SaaS applications, but they want stronger security at login. So we created our Google Apps and Salesforce.com adaptors. Problem solved.

So whilst I was reading the blog entry, I had an idea. Part of the article says:

“Avivah Litan, a financial fraud analyst with Gartner Inc., said unauthorized wire transfers disproportionately impact small to medium sized businesses that may be using online banking but do not have the same stringent financial controls in place at many larger corporations. “

Which makes sense. Less financial controls makes it harder to know if an SMB has been a victim of theft from their account.

Perhaps the delegated authentication model, very similar to that of Salesforce or Google Apps is one that could work for online banking.

I know that there is all sorts of vaporware about federation and internet SSO for financial transactions, but a facility where a banking customer could choose their own identity provider, might work for everyone. Here’s why:

1.  It removes the authentication process monoculture that currently makes it so easy for bad guys to write automated attacks for online banking
2. SMBs can actively manage their risk by choosing to spend a little bit, or a lot on their authentication processes
3. Banks can stop being IT security houses (which they don’t want to be, and aren’t very good at)
4. The Internet SSO movement would get a significant shot in the arm

Ok, I know there are all sorts of problems with something like this. But it is an interesting thing to think about. If anyone out on the tubes has any ideas around this, or even is a customer of a bank they consider to be a bit innovative, let us know.

I can’t promise anything, but it is food for thought.

For those of you who get tasked with integrating Nedu with various applications, you know that the Nedu side of the integration rarely causes problems. The Nedu API is pretty simple if you’re hitting Nedu from a progamming language, and if you’re using RADIUS, the RADIUS Adaptor simply looks like a RADIUS server.

When there are problems, they are generally caused by the differences in the authentication workflow between traditional username/password systems and Nedu. Whilst the intelligentAuthenticate call usually fixes things, it would be nicer if app developers decoupled their authentication processes from their applications.

Just like Google and Salesforce have done. And we love them for it. So much so, that they get Nedu pre-integrated for their customers. Google does this via SAML and Salesforce uses their own web service calls to an identity provider you configure in your company’s Salesforce configuration.

The SAML method is much more elegant, and Google’s implementation is so nice that we should now be able to pre-integrate Nedu with any SAML capable service very quickly. The Salesforce method is more custom, and without some of the functionality of Nedu, would be slightly frightening (who wants to pass their user’s actual passwords to Salesforce?)

So, we get to the point of the blog entry.

If you are an app developer, particularly a SaaS app developer, please support SAML for authentication at the very least. And if SAML is too daunting, (the spec isn’t the way to learn about SAML) something like Salesforce’s SSO API is better than not supporting anything. Doing so decouples your application logic from the process used for authentication. It means that implementing new authentication schemes is trivial. Better than that, it means you can get somebody else to handle the messy business of authentication for you.

In real terms, it means that your customers can do a lot to secure themselves, rather than relying on you to solve their authentication woes, which probably isn’t your core business. That leads to happier customers, more business and less problems.

If you do decouple your application processes, let us know. If you can mount a solid case for pre-integrating your app with Nedu, we will seriously consider it. Especially if you use SAML :).

The heading says a good part of it really. Last night Nedu 1.3 was released to the world. 1.3 contains a good number of bug fixes, speed improvements and some very cool new features such as Identity aliasing. But better than that…..

The 1.3 release is the beginning of an expansion into securing SaaS applications. SaaS is a growing trend and promises to revolutionise the way IT is delivered. To most of the people reading this blog, I am preaching to the converted. Nedu is a SaaS application. By using Nedu, you get two factor authentication as a service. That means, no hardware, no software (unless you choose to use our handy client software) and no licensing. However, it does mean that you need to interface your traditional systems with Nedu. And that means you can’t start using Nedu in anger until you’ve done a bit of work.

With 1.3 you can use Nedu to secure your Salesforce and Google Apps investment with absolutely no work. It is all done for you. There is some configuration required, but no coding and no adaptors.

Quite seriously, you can add two factor authentication to Google Apps in 3 minutes. And do your first authentication within 4. And if you already have SSO enabled in Salesforce, same deal. (If not, you’ll need to ask Salesforce to enable it for you. It’s free, but you need to wait for them to turn it on).

Go here to read more about how we are supporting SaaS. Or here if you want to read about our Google Apps integration and here to read about our Salesforce integration.

We’re looking for candidate SaaS applications for the next round of integration, so if you have a suggestion, leave a comment, or email our support staff. It’s all very exciting stuff. Have a play and let us know what you think.

We want your valuable feedback and will reward you for it!

Got an opinion about Nedu? Like what it does? See an area for improvement? Let us know via (feedback at gardanto dot com) and if we feel that it is valuable we will amend your account with fifty free authentication credits. Use them anyway you wish as they are identical to paid credits.

Of course you need to have an account first, so stop procrastinating and start authenticating! There has never been a better time.

On Friday, we updated our website to be slicker, more customer focussed and easier to keep up to date.

Some of our digging into our logs seems to suggest that our customers and potential customers were finding the old difficult to navigate. Whilst we’ve got some way to go before we’re happy, we hope the site is an improvement. We’ll use the data we get over the next few weeks to work out what to do next.

In the meantime, if you’ve got a moment, and the inclination, please let us know what you think.

It has been a while since we wrote anything in this blog and for that we apologise. We know it is bad form, but we have been busy with something even better than blog entries - new features!

Over the past 10 weeks or so we’ve been working on the 1.2 release of Nedu. And I’m glad to say that it has been completed and deployed to production for your authentication pleasure. Not only that, but we’ve added more documentation to knowledge.gardanto.com, and released updated versions of the Web SDK for all supported languages and a new version of the RADIUS connector.

This release was focussed on addressing the main feature requests we’ve received in the past few months. Whilst there will be a series of articles on this blog discussing the new features in detail, here’s the rundown of the goodies in Nedu 1.2:

1. Self-Service - Lots of people have asked for this as it has the potential to save a significant amount of time and money and frustration. Nedu Self-Service is a place where the people that you authenticate (the people with the phones) can go to update their own details. Nedu Self-Service is also able to help a user recover their forgotten password without a call to the helpdesk or system administrators.

2. ZeroSignal tokens - Nedu can now authenticate your users when they don’t have any mobile/cellular coverage at the time of authentication. ZeroSignal tokens are pre-sent, long-lived, single-use tokens that a user can use to authenticate to your systems when they can’t receive a message.

3. Intelligent Authentication - Nedu changes the workflow of authentication slightly. In some circumstances this can make integration with legacy applications a little difficult. Most of this difficulty comes from having to add another field or screen to the login process. Intelligent Authentication lets you integrate Nedu’s strong authentication with applications that you can’t change the login workflow of.

4. Slicker reporting - Nedu’s reporting facilities have been polished. Reports generated in Nedu are now better looking and more informative.

5. Loads of bug fixes - From rendering problems in IE7 to more reliable SMS delivery, the 1.2 release of Nedu provides a higher quality product than the previous version.

Over the next couple of weeks I’ll go into the the new features in a bit more depth. But in the meantime, they are all available to you right now if you have signed up, and if not, they are available for free when you sign up (which is also free). So let us know what you think, we’re keen for your feedback on the new release.

There is a pretty good chance that if you’re here, you have a pretty good understanding of why OTP tokens aren’t going to work for most organisations. Here’s a quick refresher just in case:

1. They must be deployed (and redeployed after 2-3 years) to the field
2. They must be managed in the field (expensive at best, impossible at worst)
3. They’ll add a non-trivial load to your helpdesk (if you have one)
4. People don’t like them, as they’re  finding that tokens are starting to breed on their keyrings
5. People don’t care about them, this means they lose and break them
6. They are the ultimate in vendor lock-in.

None of these observations are earth shatteringly new, but people are beginning to see that we weren’t making these up. So much so that CNN has an article on the shift to SMS authentication by the big boys.

Basically, the banks are finding that tokens are costing them too much and are looking for alternatives. Whilst I think that the core problem tokens have is that they are physical devices, I would also contend that another of their major problems is that that are so inflexible. Tokens can’t adapt to new threats and they can’t improve. All you can do is replace them.

Authentication using a messaging medium (like SMS) allows for innovation in authentication. We can do clever things to beat emerging threats, streamline processes and improve manageability, because we have room to move. And clever things we will do. Stay tuned.