Raspberry Pi Becomes The Encrypted Password Keeper You Need

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.

51 thoughts on “Raspberry Pi Becomes The Encrypted Password Keeper You Need

  1. “The device will register itself as a network interface in the computer/laptop and will be accessible at
    I almost stopped reading the project description at “HTTP”. Couldn’t find anything on how they secured the RFID portion of the whole information flow either. This honestly looks cute but I’d be really wary using it from a security point of view.

    1. For starters, I am greatly surprised to see my project here, never ever thought it will make way anywhere.

      For what it worth, the HTTP interface is deployed over USB ( the Pi works as an USB gadget with ethernet module loaded ). Not wireless or anything, you plug it in – and it manifests itself as an Ethernet device, with DHCP server and stuff.

      The RFID key is standard Mifare 4K key with secured access to the private key block. Just 6 bytes per sector, but should be enough for making bruteforce not feasible. The key to RFID is stored on the Pi, so you need to have both devices to unlock the password database – that was the whole point of RFID involved :)

      And this is not industrial-strength encryption either, there’s the room for improvement ( and it’s opensource ).

        1. The content is encrypted, if someone gets access to the SD card – they won’t be able to decrypt it unless they have a very large cluster to perform brute-force attack on AES, or they get access to the FOB key itself.

          1. Indeed AnyKey relies on the same concept of having a hardware device seperate from the password database. The only with this device is that it’s not really portable and the phob has a threat of being sniffed wirelessly.

            We see mooltipass a lot here and yes it’s also a nice solution but by adding a smartcard reader and a screen the price needs to be higher : solely because of added complexity. Still the single point of failure is again here the smartcard protected with a 4 digit pin (so yes its a bit more secure because you only need 9999 tries to crack that one) ;). But those arguments are besides the point. All solutions are better because for an online/remote attack it makes it more difficult than making users choose a strong password by memorising it.

            Likewise the anykey is on your keychain in your pocket : you insert it when you need it and put it back in your pocket seconds later when you have logged in or opened your KeepassXC db from which you can then apply/use all your passwords. All solutions are good because it moves the possible attacks into the physical world. To compromise them you now need to physically steal a phob or scan it by being really closeby, steal a smartcard or for our solution steal a keychain dongle in order to be able to crack it.

            We believe the AnyKey approach is the simplest and thereby also the cheapest option to do it the hardware way. No it’s not perfect, but neither are all the other solutions. And all three are better than doing nothing and relying solely on human memorised passwords.

          2. I certainly appreciate all your enthusiasm, but don’t you think that piggy-tailing on some opensource project that was made just for fun, and coming out with all these self-advertisement posts are a little bit too much? ;)

    2. You could secure it with HTTPS if you’d like. The problem is, how are you going to give it a cert the PC is going to trust? It’s connected via USB so it’s not like someone is going to sniff wireless, but if the PC is owned, they’ll get the traffic. Then again, if the PC is owned, they’re going to get it when you type it in. So… I’m honestly unsure if https actually buys you anything here. I guess the attacker could MIM the device and capture your input into the device, but again, how are you going to trust the devices cert? This is only an issue if the PC is already compromised, and if it’s already compromised you’re doomed anyway. So… meh?

    3. It’s a usb device. There is really no reason to be concerned about a MITM on a 12′ usb cable. If your PC is compromised enough that the bad actor can read data over an unencrypted http connection over usb networking direct to a device, it is just as exposed on an https connection to the same device. And, for that matter, your https connections to any other website, because it would mean the system is fully compromised already and encrypting that link will will not hide the data from the bad actor. However, creating an ssl cert and enabling it on the webserver would be trivial. One could even get a signed cert if you own a domain as there are now free ssl services. But it has no actual benefit as designed.

      1. It’s registering as a Wired Ethernet Over USB device, so, the MITM risk is … low, except if your main computer is compromised, in which case, it does not really matter, does it?

          1. Indeed that’s why U2F is in our stretch goals as well. Having said that, u2f has other downsides like not working on any pc / software. For instance KeepassXC just does SHA1 currently no u2f yet. The beauty of augmenting an existing login by using hid typing in a hardware key means it works out of the box with all login+password systems which is like 99% of everything on the market.

      1. For the commercial use – definitely, but I don’t think that it’s feasible. At least I have no idea how to do that ( any suggestions / partnerships are very welcome )

  2. 1) This build assumes that RFID tags are unique/secure, sadly you can buy tags with writable sector 0, thus defeating the entire point unique/secure, besides tags can be read without even you being aware of it,
    2) From a security standpoint, Keepass with a decent password (>20 chars) on a simple USB key should be more secure,
    3) The idea is cool nonetheless and could give ideas of less security involved build ;)

    1. I think this depends on your threat model.

      1. you still have to sniff/guess the ID
      2. you can guess millions of Keepass password in the time it takes to read one RFID
      3. indeed

    2. If FOB key is kept in a RFID-protective case ( like any other RFID-enabled credit card ) or simply wrapped in baking foil when not used – there’s absolutely no way someone can read it remotely.

  3. Secure your passwords by loading them on a raspberry pi over a network (implied wireless) using http. But they are secured on the device with AES but unlocked via an RFID token that can a) be copied and b) read from a distance greater then you expect. Ya, i’ll pass.

    1. 1) No wireless or ethernet is involved, the device communicates with a laptop over USB. It doesn’t even have internet access (unless you configure your system to act as a router). No need for HTTPS in this setup, but could be easily done.

      2) RFID token can’t be read by any random reader – the sectors containing the password information are protected by another key, that is stored on the SD card itself. So one will need to have access to the device SD card to unlock the private key stored on FOB to unlock the SD storage on the SD card. I should probably add some more details on that matter, but I didn’t really expect this project to appear anywhere besides reddit )

      https://shop.sonmicro.com/Downloads/MIFARECLASSIC-UM.pdf – more on the RFID security, if you are interested.

    2. @dprocs is correct, and the article is explicit about the USB interface.
      A USB device can present itself as an HID (Human Interface Device) like a mouse or keyboard, or it can say it’s a printer, a network interface… any one of a number of device classes. And through that, it can even represent itself as an entire connected network, like this device does.
      (Like the Matrix, with clever enough programming it could present an entire false reality, and your computer might not know until it’s too late.)

    1. That was the whole point of using buildroot – most of the Linux distros I tried ( especially systemd-based ) were taking about 25-30 seconds to boot on the class-4 SD card. With buildroot compressed kernel ( everything linked in statically ) and some optimizations I managed to get the boot time under 5 seconds. And still it could be better than that – perhaps different FS or simply taking an SD of higher class will make it closer to 2-3 seconds. Which is indeed long – but hey, this is the pet project :) and it’s opensource, so any contribution is highly appreciated.

      1. excellent project! I really like the choices you made to make this as secure as possible and workable in daily use. It may not be FIPS compliant, but as you keep on mentioning, it’s open source so anyone can try to increase security to his/her linking.

    1. Well yes a modern version does beat it: putting it on eeprom in a chip. Writing it down means someone can take a picture and you’ll have to re-type it every time. The plus side is it’s not on you hard drive so yes that’s good and it can’t be hacked remotely in any way (also good). This is why we made AnyKey it has the benefits of good old paper but is more user friendly. https://www.kickstarter.com/projects/715415099/anykey-the-usb-password-key.

    1. As the owner of a proxmark, I can attest to the fact only a certain line of mifare cards known as ‘magic chinese backdoor’ cards are writable without the key. Legit mifare cards are still secure and contain no backdoor to do this.

      Still even with a backdoor card, what do you propose writing into it? You neglected to mention the method you obtained my private key, not being readable off the card or stored on a pi or anything.

      You’re basically saying passwords don’t work because you can purchase a USB keyboard and type anyone’s password, leaving out the most important step of knowing what to type in the first place :P

      1. Thanks for the clarification, I was suspecting that MiFare 4K is not that easy to hack, cuz I couldn’t even read my card with the wrong access key ( screwed up a bunch of sectors while experimenting )

  4. Not a bad idea, but why not make it an AP, use WPA2, and https for added security. That way it can be used on corporate locked down networks that limit USB access.

    I kinda like this, since it has “cloneability”. Most other offline password keepers either use a proprietary db, or you just can’t clone them. Makes the sticky note, or notebook password option slightly better.

    I actually made myself a FIDO2 Key using the solo-key repo, by porting it to a raspberry Pi. I can export my credentials [ encrypted ] , so when the SD card gives up the ghost, I can clone the key, which you can’t do on a traditional FIDO2 key. At $20/pop, it gets a bit expensive.

  5. The content is encrypted, if someone gets access to the SD card – they won’t be able to decrypt it unless they have a very large cluster to perform brute-force attack on AES, or they get access to the FOB key itself.

  6. Within all this discussions I only miss one important point: great idea and work. Thanks for sharing!
    Of course there could be discussions on safety and other features, but all in all it represents a nice gadget, definitely secure enough for every day use.
    I’m looking forward to get some updates on this project :)

    1. Thank you very much! I just added the subscription form to the github pages ( google forms, nothing spectacular ) – so please feel free to subscribe, and once we will get some updates – we will definitely send something out!

  7. HTTPS over a USB cable is a bit like putting a cipher lock on your bedroom closet. Yes, you can do it, and it’s secure, but it’s overkill.

    Personally, I think this is an excellent exercise in data protection. Good work, jdevelop.

Leave a 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.