Developed On Hackaday: Current Status And Selected Beta Testers

OLED display, blue LED and Smartcard

Mooltipass final prototype

The Hackaday community is currently working on an offline password keeper, aka Mooltipass. The concept behind this product is to minimize the number of ways your passwords can be compromised, while generating and storing long and complex random passwords for the different websites you use daily. The Mooltipass is a standalone device connected through USB and is compatible with all major operating systems on PCs, Macs and Smartphones. More details on the encryption and technical details can be found on our github repository readme or by having look at all the articles we previously published on Hackaday.

As you can see from our commit activity these last weeks have been extremely busy for us. We finally have a firmware that uses all the different libraries that our contributors made but also a chrome plugin and extension that can communicate with our Mooltipass. We’re very happy to say that our system is completely driverless. A video will be published on Hackaday next week showing our current prototype in action as some of the contributors are already using it to store their credentials.

We selected 20 beta testers that will be in charge of providing us with valuable feedback during the final stages of firmware / plugin development. Selection was made based on how many passwords they currently have, which OS they were using but also if they were willing to contribute to the prototype production cost. We expect them to receive their prototypes in less than 2 months as the production funds were wired today.

We think we’ve come a long way since the project was announced last december on Hackaday, thanks to you dear readers. You provided us with valuable feedback and in some cases important github push requests. You’ve been there to make sure that we were designing something that could please most of the (non) tech-savy people out there and we thank you for it. So stay tuned as in a week we will be publishing a video of our first prototype in action!

Want to chat with us? You can join the official Mooltipass Google Group or follow us on Hackaday Projects.

30 thoughts on “Developed On Hackaday: Current Status And Selected Beta Testers

  1. What advantages does this have to using a PRNG to create unique passes for each website, storing these in a plain text file in an encrypted volume, and keeping copies of the encrypted volume in various locations?

    What if I lose the Mooltipass or it becomes damaged/corrupted? What kind of recovery/redundancy features are there?

    1. 1) When you decrypt your volume then all your passwords are vulnerable at once.

      2) from the faq:

      What if I lose my smartcard?
      Ideally, you should have at least two copies of your smartcard, stored in different places. The Mooltipass allows the user to clone his smartcard, provided that the card PIN is correctly entered.

      What if I lose my Mooltipass device?
      Your encrypted credentials can be exported to either your computer or the Mooltipass official website. If you lose your device, you may purchase another one and restore your credentials.

          1. In your mind, the passwords are encrypted so it doesnt matter if someone steals them.

            In my mind, they are encrypted in such a way that must be reversible since ostensibly the encrypted password is useless. So it follows that since the data is necessarily decryptable, anyone with the encrypted data could decrypt it.

            One of us must be wrong. Who is it?

          2. One of you is forgetting how most people choose weak passwords. Decryption time is based on an exhaustive search — it’s been shown many times over that an exhaustive search is rarely needed.

            You could argue that the type of people who would want to use this device tend to use strong passwords, but that’s not always the case. Security Interested != Security Conscious

          3. To clear some of this up and add some conceptional background:

            Jim is thinking of hashing instead of encryption (though many sites do confuse them and claim that they “encrypt” the password, when they are actually hashing, using “we use encryption” as some kind of magic catch-all “trust us” phrase). A proper one-way hash indeed works so that you input the password (and usually some other data) and get a result that cannot (practically) be reverse-computed into the password. This, as he correctly points out, would be useless here. It is instead usually used on the other side for storing data to be used in password verification. The cool thing here is, that if you just want to check for equality, you can compare the hashes (one stored at enrollment time, one calculated from the password the user that is trying to log in entered).

            Now, actual *encryption* has two inputs: the data (also called plaintext, the password in this case) and the key, and outputs a piece of ciphertext. An (again: properly designed) encryption scheme guarantees that no information whatsoever (aside maybe from a size estimate) about the plaintext can be gleamed from the ciphertext unless you know exactly the right key.
            This is where Jims thought process is lead astray: Giving the ciphertext but not the key to anyone should not enable them to learn anything about the plaintext. Encryption is only reversible if you know the key.

            Daniel: This holds for any plaintext, independent of how ‘strong’ the encrypted password is. An attack predicated on knowing something about the plaintext is called a “known plaintext attack” and while some encryption schemes are susceptible to variants thereof, it is prevented in all modern secure systems. So: Even a weak password is not compromised by looking at an encrypted version of it. Note that this is different for a hash: Knowing the hash of a weak password enables a brute force attack where you just try to hash all candidate passwords until you find one that results in the correct hash. BTW: The mooltipass in its first incarnation has no password input and only stores randomly generated passwords, so they are all strong.

            This is all of course predicated on the encryption key being strong.

  2. Just for poops and chuckles the first random passcode request for each unit should be that linux poem.
    Then you could see how many people actually use it for HaD login. Of course disclosing the fact after they attempt to do so. I’m figuring 97 percent of the people getting one will use it for a new HaD projects passcode first.. Also now realizing they all would have read this comment.
    Bang bang splat easteregg ruined.

Leave a Reply to Daniel GilbertCancel 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.