In our Developed on Hackaday series some readers may recall a sentence we wrote: “if one’s idea is not yet in the market, it’s either completely stupid or people are already working on it”. Well, [Josh] casually mentioned that he was also working on an offline password keeper after having recently subscribed to our google group. Similarly to the Hackaday-developed platform, the USBPass is connected to a computer via USB and is detected as an HID keyboard. As you can see in the picture shown above, it uses very few components: an ATMega32U2, a USB connector, three buttons and a few passives chips.
A total of 20 passwords can be stored in the microcontroller’s memory, which can be ‘typed’ by the platform using the push buttons. The USBPass firmware is based around the LUFA USB stack, to which [Josh] added HID report functionality to allow data transfer from his desktop application. The latter uses the Linux/Windows/OS X HID API library so bringing his software to other operating systems can be done in no time. All the project resources can be found on GitHub, while [Josh] is currently working on a B revision which will include an OLED screen.
The Hackaday writers and readers are currently working hand-in-hand on an offline password keeper, the mooltipass (click to see the project description).
Next in our Developed on Hackaday series, we present the first version of our schematics. There’s already been a lot of discussions going on in our dedicated Google group, mainly about the project’s basic functionality. Because our firmware developers wanted to get to work, we decided to send the first version of our hardware into production a few days ago. Before going through the schematics, let’s review the required list of the mooltipass’s core components:
- an easily-readable screen
- a read-protected smart-card
- large flash memory to store the encrypted passwords
- an Arduino-compatible microcontroller with USB connectivity
We’ve been drowning in component suggestions from motivated hobbyists, so we figured we’d make the mooltipass v1 as simple as possible and then move from there. Given this device is developed on Hackaday, we also wanted future users to modify it, building completely new projects based around these main components. Keep reading for our schematics…
Continue reading “Developed on Hackaday: First Version of the Hardware”
We’re pretty sure that most of our readers already know it by now, but we’ll tell you anyway: the Hackaday community (writers and readers) is currently developing an offline password keeper. In the first post of our first DoH series, we introduced the project and called for contributors. In the comments section, we received very interesting feedback as well as many feature suggestions that we detailed in our second write-up. Finally, we organized a poll that allowed everyone to vote on the project’s name.
The results came in: the project’s name will be mooltipass. We originally had thought of ‘multipass’ but [asheets] informed us that Apple and Canon had both applied for this trademark. [Omegacs] then suggested ‘mooltipass’ as an alternative, which we loved even more. A few days ago we set up a google group which is already very active.
An often under-estimated side of a community driven project is its infrastructure and management. (How) can you manage dozens of motivated individuals from all over the globe to work on a common project? How can you keep the community informed of its latest developments?
Continue reading “Developed on Hackaday: Setting Up the Project’s Infrastructure”
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…
Continue reading “Developed on Hackaday: First Feedback From Users”
We’re pretty sure that most of you already know that a few months ago Hackaday was bought by SupplyFrame, who therefore became our new evil overlords. We do hope you’ve noticed that they’re actually quite nice, and in their divine goodness they recently gave the go-ahead on this series called Developed on Hackaday.
A new project will be made by the Hackaday staff & community and will hopefully be brought to the consumer market. For those who don’t have the time/experience to get involved in this adventure, we want to show and document what it takes to bring an idea to the marketable product stage. For the others, we would like to involve you in the design/development process as much as possible. Obviously, this project will be open source hardware/software. This time around, the hardware will mainly be developed by yours truly. You may already know me from the whistled platform (currently sold on Tindie) or from all the different projects described on my website, which makes this new adventure far from being my first rodeo.
What’s in it for the contributors? During all the steps of this project, we’ll offer many rewards as well as hand-soldered first prototypes of the device so you can start playing/testing it. Nothing is set in stone so every suggestion is welcome. Should we make a Kickstarter-like campaign to manufacture the final product, we’ll only do so once our prototype is final, our partners are chosen and all details of the production process are set and confirmed. In that case, we will just need to gather the required funds to make the device a reality. What are we going to build? Keep reading to find out.
Continue reading “Developed on Hackaday: Let’s Build Some Hardware!”
We don’t know how [Kristoffer Marshall] found himself with free time at work, but he used it to beef up his computer security. Above is the finished project. There is literally nothing to see here. He’s rigged up a hidden RFID reader which locks and unlocks his workstation.
The security of the system depends on xscreensaver, which has a password protected lock feature already built into it. When the tag is removed from the reader’s field it fires up the screensaver using a Perl script.
But waking up from the screensaver is a bit more tricky. The package doesn’t allow you to wake it from the command line — most likely for security. He found the xdotool to be of great use here. It is a command line tool which simulates keyboard and mouse entry. His script detects when the xscreensaver password prompt is on the screen and uses the xdotool to fill in [Kristoffer’s] password. Since the script knows what has focus it won’t give away your password by accident.
See the complete setup in the clip after the break.
Continue reading “Hidden RFID reader locks workstation unless keys are present”
It’s our understanding that the video game industry has long been a driving force in new and better graphics processing hardware. But they’re not the only benefactors to these advances. As we’ve heard before, a graphics processing unit is uniquely qualified to process encryption hashes quickly (we’ve seen this with bitcoin mining). This project strings together 25 GPU cards in 5 servers to form a super fast brute force attack. It’s so fast that the actual specs are beyond our comprehension. How can one understand 348 billion hashes per second?
The testing was used on a collection of password hashes using LM and NTLM protocols. The NTLM is a bit stronger and fared better than the LM, but that’s not actually saying much. An eight character NTLM password will fall in 5.5 hours, while a 14 character LM hash makes it only about six minutes before the solution is discovered. Of course this type of hardware is only good if you have a copy of the password hashes themselves. Login protocols will lock out after a certain number of attempts and have measures in place to slow down automated systems like this one.
[via Boing Boing]