Arduboy Password Manager - Proof of Concept

I created a simple password manager that demonstrates the core features needed in a password manager.

https://github.com/smith725/EnterPassword-Arduboy

This is an incredibly simple password manager, that manages only one password. It is a testbed/proof of concept, to show working examples of the core functions.

It lets you edit the password displayed on the screen. Basic edits
are to change characters using up and down keys (faster if shifted with
the B key). Movement is with left and right, while Bshift-left is delete
left, and Bshift-right is insert a space.

In addition, there are several commands available.

Send - sends the current password out via USB keyboard functionality.

Random+Send - creates a new random password and immediately sends it via USB.

Random - creates a random password with a mix of letter, numbers, and symbols.

Random alphanumeric - creates a random password with a mix of letters and numbers.

Delete - clears the displayed password (not EEPROM).

Save - saves the currently displayed password to EEPROM.

Load - fetches a saved password froM EEPROM to the display.

Comments?

Can we get some kind of video? :open_mouth:

It’s a lot late in this timezone - I’ll see what I can do tomorrow.

1 Like

Interesting concept! This could potentially be expanded to something somewhat useful though. Like second-factor authentication, similar to how Yubikeys are used.

Probably worth point out there are a few security issues with the current version. As a proof of concept that’s ok, but if it was going to be more you’d need to address some of them.

The first one I notice is the random password generation isn’t cryptographically secure. Seeding the random number generator with the current time isn’t adequate for security purposes, and the pseudo random number generator itself would need to be a cryptographically secure one.

Looks cool though! I like the idea. I think one issue for me is… what happens when I want to play a game on my Arduboy? I’d have to save the passwords somewhere else, as the game might overwrite my passwords stored in EEPROM with their save data! The way that it can type in passwords itself through the Keyboard is cool though.

We have to keep in mind that this is fundamentally storing a password. Just point the cursor into a text editor, hit “Send” on the Arduboy, and your password is in the clear. That limitation means that other parts of this setup just don’t derive a lot of value from being over-engineered.

The random number generator is the least of my concerns. We’re not doing ephemeral keys or DH here! And using the time of day isn’t too bad - it’s a since-start clock with 32 bits that cycles every 20 minutes - and you should not use the lowest 3 bits due to lack of resolution. If we take 8 bits off the top, it will cycle about every 4 seconds, and we can still get 16 middle bits quite easily. If micros() is captured a few random times during initial unlock PIN entry (triggered by keypresses), then whitened with the hash function, it should be possible to get about 250 bits of entropy of reasonable quality.

Initial passcode - this will use a double legged PBKDF2 sequence, once to check against a stored hash to see if you belong here, and the second leg (different HMAC key) to prime the encrypted storage. That will use PBKDF2 over a base value with a block number so that every block has a unique key. I have yet to decide if that second leg will just generate the base key, or unlock a stored base key. The second option has the advantage that you can change your passcode without re-encrypting all of the storage.

The double legged process ensures that if you examine memory to get the entry-permission hash, you don’t get anything you could use to decrypt memory.

All of that is necessary because we really don’t have secure storage. Just load up another sketch and it can read out all of EEPROM!

I’m expecting that I can leverage HMAC-SHA256 in some way for the crypto operations. That is an attempt to limit the code size.

I expect that given the need to store both passwords AND a field indicating what the password is for, this utility will warn you once, then just take over all of EEPROM. Even then, it will only be good for between 30 and 50 passwords. That means anything else stored in EEPROM will be gone.

I am looking at one way to limit EEPROM consumption. Rather than always store a “site description”, there will be a list of canned site labels in progmem - think ebay, FB, amazon, gmail - that can be used in the description while consuming only a byte or two. Think of it as a static compression dictionary!

You say “my Arduboy” like you have only one? What’s the point in that?

In some small ways, this is better than more complex solutions. Lots of systems lock down both the running of arbitrary software (for password management), and also the use of higher capability USB functions (such as for memory sticks). As a result, people load all their passwords into either a text file or a spreadsheet. But almost nobody locks down USB keyboard and mouse functionality. Moderately secure crypto in an Arduboy should be better than a text file! Next project? An Arduboy mouse jiggler.

1 Like

That would be nice😄 I’m a visual learner😬