1

I'm trying a PoC where in I'm trying to authenticate a user based on their HID card value. I don't have any specific API for the reader. The reader outputs plain number of the card by keyboard emulation.

The PoC permits a user to authenticate through username/password or through HID proxy card. To simplify things I wanted to use a hidden TextBox to which the value from HID is read and a corresponding webservice is triggered from TextChanged event.

I was unable to do so. Can anyone advice how this can be done, I'm very new to .Net environment.

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
Anupdas
  • 10,211
  • 2
  • 35
  • 60
  • By 'HID card value', do you mean the serial number? Or do you mean through something like a YubiKey? If it's something like a YubiKey, the key inputs directly via the keyboard, so you should just have to hook into the core window's KeyDown event (or KeyUp), then parse all of the values. – Nate Diamond Jan 10 '14 at 21:38
  • @NateDiamond By HID Card value I meant any identification information stored in a card. I want to know if I can keep a hidden TextBox and populate the value of card to it. – Anupdas Jan 13 '14 at 12:03
  • Can you provide the name and manufacturer of the reader device? – Michael Roland Jan 15 '14 at 05:59
  • @MichaelRoland The Card is [HID 1386 ISOProx II Card](http://www.hidglobal.com/products/cards-and-credentials/hid-proximity/1386) and Reader is [RFIdeas pcProx](http://rfideas.com/products/pcprox_readers/pcprox_enroll/index.php) – Anupdas Jan 15 '14 at 08:30

1 Answers1

2

Using that version of the reader device (the one with the keyboard emulation) you will need some form of text input control (e.g. a TextBox) to capture the text that the virtual keyboard sends. The problem with your approach of using a hidden TextBox is that it won't get the focus while the virtual keyboard "types" the card ID.

So you would need to intercept the KeyDown event in whatever UI element has focus while you expect the card ID. For instance if you have an window and no TextBox (or other element that consumes KeyPress events) has the focus, you could try to intercept the KeyPress event at the window level:

<Window ...
    KeyDown="onKeyDownHandler"
>

The corresponding handler method would look like this:

private void onKeyDownHandler(object sender, KeyEventArgs e) {
    // e.Key will give you the pressed key
}

So using this handler you should be able to collect all virtual key presses that are sent by the RFID reader. So all you would need to do is collect them and translate them into characters.

UPDATE:

This product leaflet suggests that the virtual keyboard version of the reader can configured to add keystrokes before and after the card ID. So you might be able to detect and mask out the input sent from that RFID reader even if the focus is on the text input fields for username or password by adding a character/control keycode that cannot occur in a username/password before the card ID. Then you could intercept the KeyDown event in both textboxes and -- upon receiving that control keycode -- you could consume all keystrokes sent by the virtual keyboard. By marking those key strokes with e.Handled = true;, you should be able to hide them from the text boxes.

As an alternative, you could use the serial version (e.g. USB virtual COM port) of that reader. If that's an option... You could then receive card IDs over a serial connection instead of the virtual keyboard. As a result, you would easily be able to distinguish between user input and RFID reader input as both would arrive on different communication interfaces.

Community
  • 1
  • 1
Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • Thanks for your answer. I will update after trying your suggestion.The Login Page has a username/password `TextBox`. Even if any of them have focus it is not desirable to show characters from the card on scanning. Ideally I would like create a CardReader Listener, which can be started/stopped and a callback which provides the card value once card is scanned. – Anupdas Jan 15 '14 at 10:50
  • In that case, you might want to consider using the other version of that reader (the one that does not work as a virtual keyboard but uses a (virtual) COM port instead). With the virtual keyboard type reader you can't really distinguish between a manually typed username/password and a virtually typed card ID so you would need to let the user switch to a seperate screen that listens for card IDs. – Michael Roland Jan 15 '14 at 11:23
  • The only trouble then is that he'd have to create a custom driver for it (assuming the manufacturer doesn't provide a root-certified, signed driver which uses `WinUSB.sys`). It does appear that they have a serial version though, so that could definitely work. – Nate Diamond Jan 15 '14 at 19:02
  • Right, the other version of that reader uses a virtual serial (COM) port so no need for a customized driver. – Michael Roland Jan 15 '14 at 19:30
  • An ex-colleague of mine successfully did a PoC of the same for Windows 7. By using Reflection I could make out that he used a C based `pcProxAPI.dll` and wrapped it as a class library. Trying to do the same. – Anupdas Jan 16 '14 at 07:34
  • Thanks for your suggestion. I ended up adding keystrokes before and after card number to distinguish from username and password textboxes. So as long as either of the textbox has the focus it would work fine. Thanks for your suggestion. – Anupdas May 03 '14 at 16:48
  • So my suggestion of adding a key-down handler to the window to intercept all unconsumed key-down events (i.e. those that happen when no text input box has focus) did not work? – Michael Roland May 03 '14 at 17:23