Authentication for wire transfers

I have an international bank as a customer that is looking for a solution for customers making wire transfers to

authenticate. I have thought of using certificates, but I am not convinced that this is the solution.

I have set up the wire transfer software (on the back end), and they use smart cards to authenticate with the Fed.

Do you know of other manufacturer or technologies I can use? He wants to be able to have a one-time password or something similar.

Certificates are a fine way to do it.

You can do these sorts of things with one-time passwords, too, but there is more to it than that. Let's just call whatever we're going to give the user a token -- be it a certificate or whatever else.

You have to get the token to the user. It also has to be reasonably secure, and you have to teach the user how to use it.

The advantage of a one-time password is that you don't have to teach the user how to use it. The user can read it over the phone, send it in an e-mail, put it in a field of a Web page, fax it, whatever. Since it's a one-time password, there's no threat of it being intercepted or reused.

However, since it's a one-time password, you now have the problem of getting a new one to the user and doing that securely. There are also issues of how the user stores that thing safely and remembers where it was put! This is a mildly dangerous piece of data because if it's lost someone can do a huge transaction with it.

If you use a certificate, you have a different set of problems. Human beings can't use certificates. That's one of the main problems with public key cryptography. Machines use certificates, and humans have faith that the magic done behind their back actually means something. If you come up with a certificate-based system, you have have to supply software that uses the certificate. You also have to worry about where the private key for the certificate gets stored and other crypto issues.

Thinking about how to implement either solution is the sort of thing that makes you look longingly at the other solution.

There are variations you can have on these. For example, you can use a smartcard to implement a public key solution. I know of financial systems that use PGP for their certificate-based security.

You can use other tokens or software to do a one-time password scheme. Some of them could be quite simple. For example, the bank and the customer could share a secret, and you could use that shared secret along with a pin to generate a one-time password based on the time. That software could be written easily to work on a wide variety of systems (Windows, Mac, Palm, etc). That can also be done with smartcards or other interesting devices.

There are basically two broad ways to solve the problem: use public key crypto or use a shared secret. How you implement it has a lot of options, and decisions there need to be made on grounds other than technical ones. Cost, ease of use and customer acceptance may end up being the considerations that make the final decision for you.

For more information on this topic, visit these other SearchSecurity resources:
Best Web Links: Authentication

This was first published in April 2002

Dig deeper on Two-Factor and Multifactor Authentication Strategies



Enjoy the benefits of Pro+ membership, learn more and join.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: