Unless you’re one of the cool people who uses the same password everywhere, you might be in need of a hardware device that keeps your usernames and passwords handy. The Passkeeper is a hardware password storage system built on a Raspberry Pi. It encrypts your passwords, and only through the magic of a special key fob will you ever get your passwords out of this device.
The hardware for this device is built around the Raspberry Pi Zero. You might be questioning the use of a Pi Zero, but given that it’s an entire Linux system for just a few bucks, it only makes sense. The rest of the hardware is a tiny OLED SPI display, an RFID card reader, a few LEDs, some wire, and some solder. A 3D printed case keeps everything together.
Of course, this build is all about the software, and for that, the Passkeeper device is built in Go, with a system that builds a web interface, builds the firmware, and writes everything to an SD card. Usage is simply plugging the Passkeeper into the USB port of your computer where it presents itself as a network interface. Everything is available by pinging an IP address, and after that the web UI will log your usernames and passwords. All this data is encrypted, and can only be unlocked if an RFID key fob is present. It’s an interesting idea and certinaly inexpensive. It’s not quite as polished as something like the Mooltipass, but if you have a Pi around and don’t have a password keeper, this is something to build this weekend.
One of the more popular security builds in recent memory is USB password vaults. These small thumb drive-sized devices hold all the passwords you have to deal with, and are locked behind a authentication code on the drive itself. For their Hackaday Prize entry, [Miguel] and [Noel] asked how inexpensively one of these devices could be made. The answer, coming in the form of their Memtype project, is very inexpensively.
The Memtype project is based on the cheapest and most simplistic USB implementation on the planet. It’s built around an ATtiny85 and V-USB‘s software only implementation of a USB keyboard, requiring only a few resistors and diode in addition to the ‘tiny85 itself.
The device can only be unlocked with a four-digit pin, input through the clever use of a small SMD joystick. After inputting the correct code, the Memtype grants the user access to all the stored passwords. As far as security goes, [Miguel] and [Noel] have implemented NOEKEON in assembly, however it should be noted that all security is weaker than a pipe wrench. For managing the passwords, [Miguel] and [Noel] built a small, simple GUI app to set the PIN and write credentials to the device.
[Miguel] and [Noel] already have a demo video up for the Memtype, you can check that out below.
Continue reading “Hackaday Prize Entry: A Very Small Password Keeper”
Around 500 awesome people backed the Mooltipass offline password keeper crowdfunding campaign, raising a total of $50k in less than a week… which is nearly half our goal.
The development team and I would therefore like to thank our readers for their support. We were featured by several electronics websites, which definitely helped spreading the world of open source security devices. Many interesting discussions spawned in either our comments section or official Google Group. One new contributor even started looking into implementing TOTP on the Mooltipass.
Another hot topic was a possible smaller and more powerful Mooltipass v2, implementing other functionalities like U2F and encrypted file storage. You may therefore wonder why we didn’t start with it… the reason is simple: limited resources. Our project is made by (great) non-remunerated contributors who took a lot of their spare time to work on the Mooltipass v1. We therefore preferred working on something we’d be sure we could deliver rather than wasting $4M by making promises. We therefore hope that our crowdfunding campaign might allow an even bigger collaboration around a Mooltipass v2!
For a little less than a year open source enthusiasts from all over the globe got together to work on an open source offline password keeper. We narrated our progress here on Hackaday and always asked our readers’ opinion when critical decisions were to be made.
Today, the wait is finally over: the Mooltipass crowdfunding campaign finally arrived.
Our Mooltipass Developed on Hackaday series therefore come to an end. We would like to thank you for your support and hope that you enjoyed seeing an idea materialize into a crowdfunding-ready product!
In one month the Mooltipass offline password keeper project will be one year old.
We hope that our twice a month Developed on Hackaday series posts allowed our dear readers to see what are the steps involved in a device’s life, going from idea to prototype to crowdfunding-ready product. The Mooltipass is the fruit of a unique world-wide collaboration around open source, developed by and for security minded people who (for most of them) never saw each other. Relating our progress here enabled us to benefit from our readers’ feedback and make sure that we didn’t miss important wanted features. Contrary to other campaigns that we often debunk on Hackaday, we preferred to wait until we had a beta-tester approved device to move to the crowdfunding stage. Our geekiest readers will therefore find the launch date embedded in this post, other may want to subscribe to our official Google group to stay updated.
In a few weeks the Hackaday community offline password keeper will reach a crowdfunding platform. This is a necessary step as only a high production volume will allow our $80 early bird perk target. We’ll therefore need you to spread the word.
Thanks to the Chromium development team, a few days ago the Mooltipass installation process became as simple as installing our app & extension. As you may remember, our device is enumerated as composite HID proprietary / HID standard keyboard. This makes it completely driverless for all operating systems and enables standalone operation as the Mooltipass can type logins and passwords selected through its user interface. Management communications are therefore done through the Mooltipass HID proprietary interface, which Chrome 38 now natively supports through its chrome.hid API. The simpler our installation process is, the more likely the final users will appreciate the fruit of our hard labor.
The development of the Hackaday community offline password keeper has been going on for a little less than a year now. Since July our beta testers have been hard at work giving us constant suggestions about features they’d like to see implemented and improvements the development team could make. This led up to more than 1100 GitHub commits and ten thousand lines of code. As you can guess, our little 8bit microcontroller’s flash memory was starting to get filled pretty quickly.
One of our contributors, [Miguel], recently discovered one compilation and one linker flags that made us save around 3KB of Flash storage on our 26KB firmware with little added processing overhead. Hold on to your hats, this write-up is going to get technical…
Many coders from all around the globe work at the same time on the Mooltipass firmware. Depending on the functionality they want to implement, a dedicated folder is assigned for them to work in. Logically, the code they produce is split into many C functions depending on the required task. This adds up to many function calls that the GCC compiler usually makes using the CALL assembler instruction.
This particular 8-bit instruction uses a 22-bit long value containing the absolute address of the function to call. Hence, a total of 4 flash bytes are used per function call (without argument passing). However, the AVR instruction set also contains another way to call functions by using relative addressing. This instruction is RCALL and uses an 11-bit long value containing the offset between the current program counter and the function to call. This reduces a function call to 2 bytes and takes one less clock cycle. The -mrelax flag therefore made us save 1KB by having the linker switch CALL with RCALL instructions whenever possible.
Finally, the -mcall-prologues compiler flag freed 2KB of Flash storage. It creates master prologue/epilogue routines that are called at the start and end of program routines. To put things simply, it prepares the AVR stack and registers in a same manner before any function is executed. This will therefore waste a little execution time while saving a lot of code space.
More space saving techniques can be found by clicking this link. Want to stay tuned of the Mooltipass launch date? Subscribe to our official Google Group!