The Hackaday writers and readers are currently working hand-in-hand on an offline password keeper, the Mooltipass. A few days ago we presented Olivier’s design front PCB without even showing the rest of his creation (which was quite rude of us…). We also asked our readers for input on how we should design the front panel. In this new article we will therefore show you how the different pieces fit together in this very first (non-final) prototype… follow us after the break!
This is the bottom PCB, containing the main micro-controller, the Arduino headers and the FPC connector for the OLED screen. Finding low profile standard .1″ female connectors was one of our longest Google searches. The ones you can see above are pass-through connectors, which means that the pins can go through the PCB.
This is the CNC-milled prototype case. On the bottom you may notice two slots having a smaller depth to the other end, positioned right on top of the Arduino connectors. As previously mentioned in our Developed on Hackaday articles, we want to give the final users the ability to convert their secure password keeper into an Arduino platform. As you may have guessed, converting the Mooltipass will be as simple as cutting this thin plastic layer (see top of the picture) to access the Arduino headers and unlock the platform.
This is how the bottom PCB fits into the case. 4 screws can be used to keep everything in place. The large elevated plastic area serves as a flat surface for the smartcard:
The OLED screen then rests on the case’s sides:
Enough space is left behind the screen for the flex PCB to comfortably bend. Finally, the top board fits in the remaining space and the acrylic panel is put on top of the assembly:
As our last article stated, we obviously still have some things to perfect. In the meantime, we are going to hand solder a few prototypes and ship them out to our current developers.
Want to stay informed? You can join the official Mooltipass Google Group or follow us on Hackaday Projects.
16 thoughts on “Developed On Hackaday: Olivier’s Design Rundown”
It looks sexy.
Who thought blue leds could still be cool after all the abuse in horrible products ? :)
my thoughts exactly.
I am sorry, but it’s too big. Do you really need to use the card? What’s even the point of having removable smartcard, when you can’t use one without another? well… i know you can use smartcard for different purposes… but i’d preffer small self-contained USB stick…
the main point of a removable master key storage is to always have it with you. If you have to get up and go the loo you can simply snatch out the card and take it with you. (In a corporate setting it’s not uncommon to enforce this, by making the secret storing smart card also act as an access control token and therefore necessary for you to get back into the office after you’ve done your business.) A device that’s big enough to have useful input and output units is not as convenient to *always* have an eye on. (Actually, such devices can be manufactured in a small, even smart-card, form factor, but then you’re leaving both the “hobbyist tinkerer” and the “cheapskate” areas. :) )
A secondary point is theft protection: The master key secret storage is the ultimate secret; you have to make sure that no one else can get to it. The mooltipass device ‘only’ needs to be protected against tampering, which is an easier requirement to fulfill. In practice that means that you would want to carry the smart card in your wallet on your person while you can leave the device in your bag. Theft of the mooltipass would be a nuisance but not castastrophic.
Grüße aus Berlin
Thanks a lot Henryk for taking the time to provide such a great answer :)
But how would you be able to use a simple phrase like that when all too often you’re forced to use a bunch of random chars?
Just use some kind of padding with numbers and/or special chars, e.g.:
Got the idea from https://www.grc.com/haystack.htm
note that you should otherwise disregard most of the things Steve Gibson says about passwords. His math is wrong (or rather: he doesn’t calculate anything that is remotely related to the actual attack difficulty) and his examples are extremely dangerous. For a full discussion of this see https://subrabbit.wordpress.com/2011/08/26/how-much-entropy-in-that-password/
A historical perspective on the eye-of-newt password rules (I really like that term) can be found in http://queue.acm.org/detail.cfm?id=2422416
A worse problem, than the pointless requirement to add punctuation, though, is that a surprisingly large number of sites actually have an *upper* password length. This is invariably a bad idea. Also, if you ask them and they have technical reasons for not increasing that length, it means they are Doing It Wrong: They are storing the password unhashed, as plain text.
Grüße aus Berlin
and replacement for arduino http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/LN1847?icmp=ln1847_pron_pr-nucleo_feb2014
In the link you provided, the cheapest MCU with native USB is the STM32F103RB which actually has a comparable price with our atmega32u4.
In the beginning of the project we actually had plenty of discussions on the possibility to switch to a bigger MCU. Given that we didn’t really need the extra computational capabilities we figured we may be better off using the MCU that is compatible with most libraries out there.
I’m sure both approaches must have their valid points though.
Looking good! Thanks for the additional pictures.
So since I keep seeing posts on this project, and I’ve finally gotta ask… What is the point of this? I mean i get that it’s cool as a fifth element tribute, but in practice isn’t this a terribly insecure form of password storage? The idea of a password is that it is “more” secure by being inaccessible being in your head. Writing down passwords is a day one lesson to never do it, and while this isn’t the same, it’s pretty similar. Yeah, it sucks remembering all those passwords but the idea is they aren’t physically accessible, that’s kind of the point right?
Perhaps you should read again the project description on github and point us exactly where our security holes are?
> Writing down passwords is a day one lesson to never do it
That’s one of the “common wisdoms” about passwords (see also: It must never contain a dictionary word, it must always contain numbers and punctuation, it must be changed every x days) that, when you come right down to it, is plain wrong and incredibly counterproductive. The article I linked earlier (http://queue.acm.org/detail.cfm?id=2422416) traces these back to a government manual from the eighties. Since then a Cargo Cult of password rules seems to have been established, each generation of programmers just parroting back what they were subjected to as users in the previous iteration, with no real understanding or rationale for what they are doing.
The IT landscape has changed since 1985. By an enormous margin most attacks now happen over the network. One of your colleagues turning over your keyboard and reading the (single) password you wrote on a note under it is not the primary attack vector anymore.
Telling people to chose non-dictionary, gibberish-infused passwords that they are not allowed to write down and have to change every three months is a recipe for disaster. That barely worked in the eighties when there was only one password per user and all users were military personnel who could be expected to follow a rigid standard of discipline.
These days, when everyone and their grandmother have a dozen or so regularly used accounts of which probably three are financially critical, you get: the same password reused from site to site, that password being D0ggies!, which is also written down on a post-it note taped to the monitor. And if some unenlightened administrator activated the “password must be changed every three months, and may not equal any previous password” ruleset, it becomes D0ggies!1401, D0ggies!1404 etc.
Good password recommendations: Use different passwords for different sites (preferred) or at least for all high value sites (the determination what a high-value site is is somewhat complex though). Enable two-factor login wherever offered. Make passwords have a guessing difficulty of at least ~40 bits (sufficient against online attacks, not sufficient against offline attacks). Use a password manager with strong encryption and a strong passphrase (>~100 bits guessing difficulty, sufficient against offline attacks) or similarly strong local authentication. If you can’t: Write your passwords down, on paper, not your computer, and keep the list in a safe place (like: a safe, if you have one; your wallet will also do, except of course if you’re one of those people that lose their wallet every five days). If at all possible disable all password reset systems or at least make sure that “Your mother’s maiden name” is an unguessable string (essentially: another password) and not what’s listed on ancestry.com.
Grüße aus Berlin
Thank you for such a thorough, educated response to a comparatively uneducated(see: drunken) question. Interesting points to consider.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)