
Holy cr*p guys… we were amazed by the quantity of positive feedback that was left in the comments section of our last article. We have been featured by Slashdot ! We got plenty of project name suggestions, therefore we organized a poll located at the end of this post to let you decide which one is best. I also received many emails from people eager to start contributing to this offline password keeper project. If you missed the call and want to get involved, it’s still not too late. You can get in touch with me @ mathieu[at]hackaday[dot]com. So far, we have many beta testers, several software developers, one security assessor and a few firmware developers. Next step is to create a mailing list and a Hackaday forum category once the project’s name has been chosen.
Obviously, the very first post of our “Developed On Hackaday” series was to gauge your initial reactions to this ‘new’ project. Notice here the double quotes, as when someone has a new idea there usually are only two possibilities that may explain why it doesn’t exist in the market yet: either it is completely stupid or people are already working on it. In our case, it seems we are in the second category as many readers mentioned they wanted to work/were working/had worked on a similar product. As we’re selfish, we offered them to contribute to this new device.
To ensure that all of our readers are on the same page as to how the device will work we embedded a simple block diagram after the break, as well as a list of all new functionalities that we want to implement given the feedback we received. So keep reading to see what the future holds, as well as to vote on this new project’s name…

As we don’t really need an ARM processor for this project, the only microcontroller we can use while keeping direct Arduino compatibility is the ATmega32U4 from Atmel. We haven’t chosen which IDE we’ll develop on (if we actually use one). The device will be recognized as a USB keyboard (USB HID class), therefore no drivers should be required on Windows/Linux/Mac/Android/any system you have. A few of our friends actually told us that Tablet PCs and recent phones can enumerate HID devices via their USB OTG port. We may use the great LUFA library from [Dean Camera] or the Teensy code from [Paul Stoffregen] for USB communications. The next post of our ‘Developed On Hackaday’ series will be about the chosen hardware so we welcome any suggestion from our dear readers in the comments section below.
As a few readers were worried that it’d still be possible to lose stored passwords with the proposed setup, we’d like to emphasize the fact that the device will be able to clone your smart card (containing your AES key and main email password for example). Obviously, it’ll only do so once the initial smart card is unlocked and will copy the same PIN code to the new card. Note that the cloned card is supposed to be kept in a safe place. We’ll also offer the possibility to export the encrypted passwords stored in the device internal memory (not shown in the diagram).
We previously mentioned that a browser extension will send the currently visited website to the device, so the user can approve the sending of his credentials by tapping the touchscreen. One very relevant point has been raised by [tekkieneet]: the fact that one user may always click ‘yes’ without checking that the website visited is the same one shown on the OLED screen. [Tekkieneet] would prefer making the user browse through all the saved websites’ credentials without using any plug-in on the OS side. In our opinion, that reduces user friendliness… what do you think? Could we come up with a way to force the user to check the displayed URL?
[Happyjam64] also suggested that we should force the users to switch passwords every few months. Would this become cumbersome for novice users? Should we allow the users to select what type of security they want? We’re obviously talking about trade-offs here.
Here is another question for our readers: how long should we unlock the smart card for once the user has entered his pin code? A short period may render the device annoying to use daily, and a long one compromises the security of the system. The Hackaday writers’ educated guess would be to force users to lock their computer when they’re away by removing the smartcard. The device would detect that the card is not here anymore and therefore perform a keystroke to lock the computer (what’s windows + L for linux and mac?). We’d just have to teach our acquaintances to lock their computer when they’re not in front of it (that seems reasonable, right?).

We look forward to reading your opinions of these key points, and we’ll see you soon in the next episode of our Developed On Hackaday series (thanks [Ren]). In the meantime, don’t forget to vote for your favorite project name!
Filed under: hardware, news
