SparkFun Forums

[abb51]

have you thought of using a telnet/terminal type interface rather than a text file?

opening and editing a text file sounds like it might be counter-intuitive to potential users.
a terminal (with echo turned off) would also provide user input masking for changing passwords etc.

also have you tested if it's immune to software keyloggers? since it shows up as a keyboard I'm guessing it's not

(I currently use KeePass for my passwords, but I have no idea if it offers any resistance to keyloggers. I know it works well at remembering the 500 different passwords I need though, but the downside is keeping the database up to date across multiple machines... )

[jonkuhn]

How about if you rename a file as the answer to the question? I do believe modern OSes automatically "optimizes" USB mass storage devices "for quick removal" (option from the windows device manager), caching might not be a problem.

Only Windows does that, and from XP SP3.
Older versions of Windows and Linux doesn't do that, because it decreases write throughput.

On OSes that delay writes to flash drives until removal my text file based user interface would have some problems. However, in my testing (on Ubuntu Linux, Windows XP and Vista) OSes seem to write to the device immediately, but I know this is a setting that can be altered so it is something I should probably account for.

For my master password entry system it should not be an issue since the device does a detach/attach anyway. The user would be free to "safely remove" the device which would transfer the master password data and unlock the device. The device would still simulate a detach/attach so it would be re-enumerated by the host in the unlocked state.

For my newer system for selecting passwords to enter, user placing * characters next to passwords in a file and saving it, if the OS delays writes to the device it would cause a problem. Although it seems most modern systems are configured to write directly to the device, it would be best to provide an alternative when the user is using a system where this is not the case. Possibilities include:

1) Write a small host application that would be embedded into the device. In this host application use proper API calls to ask the OS to sync the data to physical media. I would have to see how well OSes honor these APIs as I think I have heard there are some issues with them not behaving as advertised. (probably the best solution)

2) Leave the physical button interface even though it is more cumbersome for cases where a machine that is delaying writes is being used.

3) A more complex num lock/scroll lock/caps lock interface that allows the user to use these keys to cycle through passwords somehow. (Would probably get cumbersome, but better than nothing)

4) Allow the user to do a "safely remove" operation each time they want to change passwords (cumbersome, but if the user only occasionally uses a machine configured to delay writes it is better than nothing)

Previously I was responding to the fact that the OS will *read* from it's cache before reading from the device, so let me clarify that here also. It may be the case that the first time a file is read it will be read from the disk (and therefore detectable by firmware), but all subsequent reads will come from the cache. This just means that the firmware cannot change the contents of a virtual file in the middle of a session and expect the user to see those changes.

How about if you rename a file as the answer to the question?

This could probably work, but what advantage does renaming a file have over editing text within a file as I am doing now for master password entry?

Can I buy a spare prototype? I live in Canada and I have PayPal.

I really appreciate your interest in the device, but I am just not ready to do this yet. If and when I am ready to send out devices for broader testing I will definitely contact you right away. Anyone else who would like to be on the list for helping to test devices in the future please contact me (http://jonathankuhn.com/contact).

[jonkuhn]

have you thought of using a telnet/terminal type interface rather than a text file?

opening and editing a text file sounds like it might be counter-intuitive to potential users.
a terminal (with echo turned off) would also provide user input masking for changing passwords etc.

also have you tested if it's immune to software keyloggers? since it shows up as a keyboard I'm guessing it's not

(I currently use KeePass for my passwords, but I have no idea if it offers any resistance to keyloggers. I know it works well at remembering the 500 different passwords I need though, but the downside is keeping the database up to date across multiple machines... )

My device would not be immune to software keystroke loggers, since (like you say) it looks just like a keyboard. It may offer some "protection" (if you can even call it that) from hardware keystroke loggers as long as you did not mistakenly plug it into a USB hardware keystroke logger.

KeePass is likely immune to hardware keystroke loggers (other than when you enter your master password). KeePass may take steps to attempt to avoid software keystroke loggers, but it is probably a losing battle if they do, since the people making keystroke loggers would likely make changes to get around what KeePass does. In the end the password data has to end up in a field in a Window and/or transmitted to the network stack, and in most cases there will be a way for other processes (keystroke loggers) to grab the data.

I think the value proposition for my device over KeePass would mostly be better cross-platform compatibility, and (like you say) not having to keep multiple databases up-to-date. I obviously would have some work to do on the testing side to make it compatible across as many systems as possible. Since you are a KeePass user, I would be interested to hear about your experiences and if you have any ideas for how the password manager experience can be made better.

The problem of keystroke loggers really goes beyond password managers, and it isn't really a problem that password managers can solve. One way to truely thwart keystroke loggers is to use a second factor authentication system in addition to passwords. This unfortunately requires the server you are authenticating to to support it. Examples of one time password systems are: http://www.yubico.com https://www.grc.com/ppp.htm as well as systems that send you a one time password via SMS text message. I am thinking I could provide support for a second factor authentication system in my device (either one time password or a challenge-response system), but like all similar systems the server you are authenticating to would need to support it.

I have thought about implementing a higher level user interface. It may be command line or GUI. It will probably need to be written in X86 assembly to get the file size small enough. Initially at least, this higher level interface would only support Windows. Eventually I would write a version for other OSes provided that I can jam them all into the available memory (possibly adding memory chips if needed).

A similar idea I had was to make the device appear as a virtual COM port and the user could use hyper terminal to interact with it. The main problem here is that (I think) Windows would most require special drivers to be installed for a USB to RS-232 adapter. That and I doubt many users are all that comfortable with hyper terminal.

-Jon

[frank26080115]

renaming a file means pressing F2, the answer, and the enter key, whereas editing a file means pressing enter (launching notepad or similar), typing in the answer, pressing ALT-F4, and then the Y key

i really like saving that extra few seconds

i'm actually only interested in the prototype because it'd be nice to have a chip with USB and three buttons in a nice case, i'd program my own applications for it

[jonkuhn]

renaming a file means pressing F2, the answer, and the enter key, whereas editing a file means pressing enter (launching notepad or similar), typing in the answer, pressing ALT-F4, and then the Y key

i'm actually only interested in the prototype because it'd be nice to have a chip with USB and three buttons in a nice case, i'd program my own applications for it

That is a good point about about the keystrokes involved, I hadn't thought of it that way.

I only have 4 assembled boards, so I'd like to hang onto those. The USB chip is in a QFN-32 leadless package so it is a pain to assemble. I paid a guy I know to assemble 4 for me, since my soldering skills are not great.

The cases are these: http://www.newageenclosures.com/cart.ph ... l&p=33&c=5 You can get them from Mouser in low quantities. You can get the development board that I have here: http://www.futurlec.com/USBDevBoard.shtml

We may be able to work out something if you want a few bare boards (with schematics and BOM) or the Gerber files.

-Jon

[abb51]

Since you are a KeePass user, I would be interested to hear about your experiences and if you have any ideas for how the password manager experience can be made better.

The main annoyance I have is that some applications save your username, some make you type it in each time. So if you can cater for that, that would be good. KeePass lets me Ctrl-V to auto-type both, or Ctrl-C to grab the password into the clipboard for 10 seconds, which works but you have to consciously choose the right method. If it could clear the username field (End, Shift-Home, Del) then type the username, that would be great.

A similar idea I had was to make the device appear as a virtual COM port and the user could use hyper terminal to interact with it. The main problem here is that (I think) Windows would most require special drivers to be installed for a USB to RS-232 adapter. That and I doubt many users are all that comfortable with hyper terminal.

You're probably right about the drivers, and familiarity with HyperTerminal. I just thought it would save writing USB mass-storage device code, serial terminal code presumably being easier. A custom host program stored on the device itself would be perfect.