For example, suppose a cracker recognizes that you are using single packet authorization, and then sniffs out a copy of your client's authorization message. The message doesn't contain anything the cracker can understand. All the data is encrypted and looks like random garbage.

Ah, the clever cracker thinks, now that he has a copy of the authorization key, all he has to do is resend the same message from his own machine, thus gaining access to the same service, right? Wrong. Single Packet Authorization has a built-in anti-Deja Vu feature. Among other things, the message contains an encrypted time-stamp. If a cracker resends the same message, the server will recognize it as an authorization attempt that it has already seen. It will reject the duplicate message and deny entry to the cracker.

Single packet authorization has other advantages over port knocking alone, but I'll leave that for the techno-geeks in your organization to discover. In particular, they should read about something called fwknop, which is the central utility [PDF] for single packet authorization.

Just like port knocking, single packet authorization is not a replacement for traditional authorization procedures. If you protect your services by user name/password combinations, you should continue to do so. Port knocking and single packet authorization are an extra level of protection meant to prevent unauthorized clients from discovering that you provide SOA services.