Mooltipass Installation Process Is Now Dead Simple

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.

As our last post mentioned there’s still plenty of space for future contributors to implement new functionalities. Our future crowdfunding campaign will allow us to find javascript developers for the remaining app & extensions tasks and also implement other browsers support. Want to stay tuned of the Mooltipass launch date? Subscribe to our official Google Group!

 

62 thoughts on “Mooltipass Installation Process Is Now Dead Simple

    1. It is pretty sad that chinese tablets are cheaper than this. Now it would be neat to repurpose them as they already have all the hardware + case.

      Even if you were to buy the shields from China and recode the firmware,
      ABS clear plastic case for PCDuino (with LCD window+ mounting hole) $9.44
      Keypad + LCD shield: $ 10.14
      Add Processor of your choice… May it be ARM with tons of memory and not needed additional FLASH or AVR… ~ $15

      So $35 or so without the premium on bling-bling that doesn’t add to security.

      1. The prices already includes “Free shipping” from China for the reseller (DX and others), so inventory / fulfilment / distribution is done. Return for DOA too for that price.

        Since they are shields based, it is a matter of stacking them, assembly them into the plastic case on my list by the end user. I think someone in China is happy to pocket the difference to sell the final “assembled” product.

        1. Having all the electronics exposed is also a problem.
          Anyway, I agree with you that if you don’t mind having a not so pretty piece of hardware potted in resin your solution should do the trick.
          That being said, I’m fairly sure they produced way more than 1k units to get these prices.

        2. That’s why I have a $9.44 injection molded ABS plastic case specifically made for the *duinos + LCD + buttons already on my BOM in the $35. It wouldn’t be fair if have I show has dangling pieces of wire duct taped together. They now have $5.5 injection molded RPi black case that looks professional.

          You are not taking advantage of mass produced commodity for a small production run. (NIH strikes again.)

      2. My new job has given me a very close look at chinese supply chains versus other nations on our product line, and if you go looking at the source materials in China, *THEY* shouldn’t be able to afford to buy the raw materials for many of the products I deal with, based on their end selling price. I can’t name names, but, those conspiracies about some Chinese companies being heavily subsidzed by government, it’s the only way I can figure it out.

      3. Is there anyway to make the Android phone/tablet a HID device? It sure is tempting at ~40 USD/free for an android device, it could be worth it to make a custom ROM for this.

      1. So…. (I’m just asking here) it needs to be plugged into the computer to work?
        I’m thinking of the public accessible computers (banks, hospitals, public libraries) that have USB ports plugged or locked away. Or can it display a password on the screen
        when a USB port is unavailable.

  1. Can’t wait to fund this already! Me wantee! In addition to the security upgrade it offers me I also want to encourage you to do more things like this. Maybe a had dev board? Or just upgraded parts to other products like 3d printers, cnc router, etc.? Have you guys thought of any possible future ideas?

      1. What is this ‘0x4B command’ that provides random bytes? Do you have a link/doc as this would be useful for many projects and uses, as long as it is a mostly random bytes (RND on Arduino is difficult in my experiments)

        1. I’ve actually been running one Mooltipass for nearly 2 weeks now, dedicated to random number generation.

          current entropy utility output:

          Entropy = 7.999978 bits per byte.

          Optimum compression would reduce the size
          of this 8987840 byte file by 0 percent.

          Chi square distribution for 8987840 samples is 272.59, and randomly
          would exceed this value 21.45 percent of the times.

          Arithmetic mean value of data bytes is 127.4850 (127.5 = random).
          Monte Carlo value for Pi is 3.143586700 (error 0.06 percent).
          Serial correlation coefficient is -0.000034 (totally uncorrelated = 0.0).

          doc: https://github.com/limpkin/mooltipass/tree/master/source_code/src/USB

          1. Generating random numbers is more complex than it appears.
            Many random number generators used actually are _pseudo_ random number generators, which are an algorithm for generating a sequence of numbers whose properties approximate the properties of sequences of random numbers.This sequence may however repeat in some way or another.
            So most (if not all) security guys here will argue that we need a true source for RNG, even though we don’t need so many random numbers in our case.
            We currently use the avr entropy library, which uses the watchdog timer jitter to generate random numbers. But as for every TRNG out there we need to make sure that our implementation is correct, which is why some of us are leaving our mooltipass connected to test the properties of the random numbers generated.

          2. Would you mind running https://gist.github.com/amtal/26f91018e0e12911f6c7 on your data?

            I’d be very curious in looking at the stream pre-whitening. There’s been some data collected by endolith (https://secure.flickr.com/photos/omegatron/7122501307/in/set-72157629934367149) with interesting cyclic patterns. What happens if you isolate the board from USB power supply noise?

            Admittedly if each 16ms sample produces at least 1 bit of entropy, that’s 32 bits of entropy covered in the Jenkins hash input. So, this is all likely to be more interesting than useful.

  2. Are you guys planning on developing a Firefox extension that has feature parity with the Chrome extension? I’m guessing this might be a bit of a challenge if Firefox doesn’t have a good HID API, but a full-featured Firefox extension would be great to have.

      1. Lovely! How does it work in Mooltipass? My bank web site is also doing the same, asking random combination every time.. it’s very frustating that even if you remembered the password, many a times the wrong key is entered..

  3. ‘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.’

    If the Mooltipass is typing the username/password, rather than directly setting them using the browser API (in this case chromium) — how would attacks using a keylogger be mitigated by the Mooltipass?

    1. They can’t be. As the FAQ mentions our goal is to only reduce to a very minimum the number of attack vectors. Perfect security could only be achieved by sharing a secret with all services out there or by verifying in person a public key.
      I’m voluntarily not mentioning chain of trusts given the numerous CAs that were compromised these last years.

    2. > If the Mooltipass is typing the username/password, rather than directly setting them using the browser API (in this case chromium) — how would attacks using a keylogger be mitigated by the Mooltipass?

      Then they’re exactly as secure as writing your passwords down on paper, and locking them in a series of perfectly secure matryoshka safes. You’ll eventually have to use a keyboard, right?

    3. The mooltipass is not susceptible to keyloggers that target HID keyboard devices when it is used with the chrome plugin. The chrome plugin makes use of the RAW HID protocol for its communication, not the HID keyboard protocol.

      Malware would need to log the RAW protocol to capture credentials sent in this manner.

      The mooltipass also supports the HID keyboard method to enter credentials (to, for example, avoid the need to install a browser plugin). In this case its as safe as your keyboard.

  4. What’s there to stop someone to create a rouge login form in order to retrieve user/pass from the mooltipass? I’d be upset to find out that a dodgy web-page with a hidden iframe managed to extract all, or some, of my stored credentials…

    I’ve not extensively read up on mooltipass yet so my question might already been answered. If so, my bad.

Leave a Reply to Ethan ZoncaCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.