Identifying Input Device

[Jupiter]

Hi Friends,

I have an interface for swiping card (magnetic strip) . Both Keyboard and the swiping device is connected to the CPU through the same PS2 port.

Now I need to stop input from key board while accepting input from the swiping device.

I am unable to make my application differentiate between the Keyboard entry and the Swiping device entry. Please suggest.

I bet on your experience!

 

[joey.jeremiah]

from the application point of view it is a keyboard. barcode readers in many cases are setup in a similar way.

session:set-wait-state( ) won't work, a dialog-box won't work, maybe you'll find some differences in the lastkey keycode, maybe not ? i don't think it can be done with progress but i'd imagine it is possible to do using win api's.

personally i would represent it in a way and explain to my users as if the device acts as a keyboard, as it actually does. theres something to be said about simplicity.

 

[tamhas]

I don't know about yours specifically, but for many of these kinds of devices there really is no difference between input from the keyboard or from the device. The usual trick is to set the parameters on the device so that the input is given a special lead-in character like control-A to signal the source of the input. Similarly, one often programs the device to put a tab or return at the end.

 

[Jupiter]

The swiping devices we are using uses "%" or "c10" as starting characters. But these can be easily found out by anybody if they swipe their card in any text editor. After knowing a card number and default starting character for a swiping device, an unscrupulous person can easily type in the whole swipe string and use the benefits of the card holder.

I tried to solve this problem in the following way.

1. Stopping Copy-Paste operation for the fill-in where card should be swiped.
2. Setting time limit in which input must me finished using some kind of timer functionality.

But there are cards of varying lengths. There are some cards for which the length of swipe-string is big, there is time-out.

I was weighing upon the feasibility of asking the users of the card (some privileged customers) to enter the password after swiping the card ( as we do in bank ATM s). But that would slow down the whole billing process considerably. [In busy counters we have on average 1 bill on every 2 minutes!!]

 

[joey.jeremiah]

progress is a business application language, it's not really intended for handling devices at this level. if you're looking to block input from one device or recognizing devices, the operating system would be a much better place to look for.

maybe the BlockInput() api would work or using some of the other keyboard api's ? http://tinyurl.com/dd9sy

depending on the setup you could have a problem differentiating between the real keyboard and the card thingy (tech term), especially if they're both connected through the same ps2 port.

another thing i'd do is ask the vendor what's been done in other places ? i bet you're not the first guy facing these same questions. hey, it may even be in a manual, documentation etc.

 

[TomBascom]

It sounds to me like the real problem is that you are displaying the information that has been swiped off the card. If you didn't do that then it wouldn't be there to be copied and pasted (or written down on a piece of paper...)

Treat it like a password field and your problem should go away.

On the other hand... perhaps you have already done that and you are saying that the card number is printed on the card and that it is what is being read when swiped. Because they are the same, knowledge of the card number is sufficient to compromise the account's integrity -- all you need to do is to type in the correct standard prefix and the card number.

In that case the problem is that you're essentially publishing a password in clear text on the card. Of course someone is going to be able to compromise that. If not through this means then through some other.

One possible solution -- decouple the card number from the account number. Put a card number on the card and an account number in the swipe. Better yet put a hash of the account number plus something (hopefully) known only to the application in the swipe (and don't use the same something for every account). It won't be perfect -- but it should be a big improvement.

Having said all that... if security is important and real money is at risk don't try to solve this yourself. "Roll your own" security might stop the lazy and the incompetent but it won't stop a motivated thief.

 

[tamhas]

If, as he seems to say, people are in a position to swipe their cards while in a text editor, it doesn't really matter what one puts on the card, it will be insecure.

 

[joey.jeremiah]

if you need a more secure solution and the current one is insufficient, maybe you should shop around for another card swipe device that comes with different connection options, possibly encryption etc.

but as been suggested you should consider if you're not over engineering.

 

[TomBascom]

If, as he seems to say, people are in a position to swipe their cards while in a text editor, it doesn't really matter what one puts on the card, it will be insecure.

Quite true.

But making it more of a pain in the butt should at least slow down casual abuse :awink: