holy cr*p guys… we were impressed 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 numerous 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]hackadaydotcom. So far, we have numerous beta testers, several software developers, one safety and 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 typically are only two possibilities that may discuss why it doesn’t exist in the market yet: either it is completely dumb or people are already working on it. In our case, it seems we are in the second category as numerous readers discussed they wanted to work/were working/had dealt with a similar product. As we’re selfish, we provided them to contribute to this new device.
To guarantee that all of our readers are on the same page as to how the device will work we embedded a easy block diagram after the break, as well as a list of all new functionalities that we want to execute 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), for that reason no chauffeurs ought to be required on Windows/Linux/Mac/Android/any system you have. A few of our pals actually told us that tablet PCs and recent phones can enumerate HID devices through their USB OTG port. We may use the terrific 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 idea from our dear readers in the comments section below.
As a few readers were concerned 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 essential and main email password bijvoorbeeld). 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 expected 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 discussed that a browser extension will send the currently went to site 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 site went to is the same one shown on the OLED screen. [Tekkieneet] would choose 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 ought to force the users to switch passwords every few months. would this become cumbersome for novice users? ought to we allow the users to select what type of safety and security they want? We’re certainly talking about trade-offs here.
Here is another question for our readers: how long ought to we unlock the smart card for once the user has entered his pin code? A short period may render the device bothersome to use daily, and a long one compromises the safety and 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 discover that the card is not here anymore and for that reason carry out a keystroke to lock the computer (what’s windows + L for linux and mac?). We’d just have to instruct 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 essential 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!