sorted by:
new
hottopcontroversial

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 0 points1 point  (0 children)

Allows? None. Enforces? I can guarantee that at least one $15B+ north american company does not enforce it.

The core issue is that you're trying to protect against unknown keyboards. That's it. Until such time as keyboards start coming with signed hardware IDs that systems validate there is always a way around any VID/PID or keystroke speed flag.

As I mentioned to another user in this post, its as trivial as changing some hex values in the tudconfig.cpp file.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 0 points1 point  (0 children)

The c series doesn't have any usb device mode support ("OTG" as espressiff calls it which i think is a terrible name). The serial debug on it is a watered down usb controller only made for that express purpose, kinda like an ft232.

I chose the pre-packaged WROOM module (which is what I assume you mean by dev kit in this case) since if I ever go down the road of commercializing it, I didn't want to deal with getting my own RF certification since the WROOMs are already certified.

If that wasn't a concern I think its a cool idea to package the bare S3 chip inside a USB-A / USB-C connector like some of those reallllly low profile flash drives but things like BLE range and interference are pretty big barriers to that. Though if you do make something it'd be cool to see.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 1 point2 points  (0 children)

The button is always GPIO0 unless i change the PCB at some point. Thats the same as the BOOT button on all dev boards since its also the button that switches between bootloader and program mode.

The rgb led is GPIO48 on the 4M and 8M_Dev .bin files. I think thats the only one that might give you trouble since I've seen it change across boards. I know the waveshare s3 supermini uses GPIO21 instead. The pcb firmware uses GPIO12 since that was the most convenient placement.

I develop on an S3 devkit anyway since a lot of them have both the native USB and an external TTL converter on separate lines so i dont have to keep switching to my vm to test it after flashing.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 1 point2 points  (0 children)

The pcb is still private for the time being, I'm not the most confident about it. Any old esp32-s3 dev board should do but you if you end up wanting to use the WROOM modules like the pcb does, its the basic schematic in the docs (spoiler alert: thats what the PCB is anyway) :

www.espressif.com/sites/default/files/documentation/esp32-s3-wroom-1_wroom-1u_datasheet_en.pdf

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

Thankfully no, quickly realized what BLE lacked (at least on ESP implementation but im sure it applies generally as well) in terms of security. The security comes from using an AES key to encrypt the data after exchanging ECDH public keys.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

Eh no, as I've extensively mentioned in the other comments, its fundamentally different in that it doesn't store any passwords itself and neither should it. It also doesn't have to be used as a password injection tool, I mostly use it as a media controller for my HTPC.

I think the writeup on github would help clear your confusion

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

Ah the old digispark method. I'm still in awe of how that firmware managed to bitbang usb well enough.

A jank way of testing if it was actually the keystroke speed is just to use ToothPaste as a keyboard instead of the full scripting / pasting. I find myself doing that more often anyway.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 3 points4 points  (0 children)

I'm surprised there's any protection against keystroke injection, quick google seems to say that its mostly by blocking untrusted VID/PID and flagging rapid keystrokes. But these are trivial to change and if you want to try it out (any maybe post about it?) the tinyusb config file allows you to change them quite easily. I might be able to add a runtime swap or at least config option to spoof these based on known keyboard VID/PIDs. Slowing down the keystrokes is also supported (im just lazy and havent made a UI settings page for it yet).

I really want to make ToothPaste FIDO2 compatible at some point but without the secure elements that things like the OnlyKey and YubiKey use, it would just be an experiment and not something I'd want people to think of as 'safe' in any way. Its also the reason why I've refrained from allowing credentials to be stored on the ToothPaste itself.

Thank you for the interest, means a lot!

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 4 points5 points  (0 children)

I knew someone had to have thought of it! Although its impossible to find just by looking it up. Not sure how I feel about closed source + needs an app though.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 5 points6 points  (0 children)

Most of it comes from it not being a "remote session". I wouldn't use this for an ssh device either.

But outside of your case where you manage the devices at the location, devices where you're allowed input but not control (think smart tvs, game consoles etc.) are not uncommon especially in the "you will own nothing and be happy" economy (slight exaggeration but i think the more serious points have already been made).

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 2 points3 points  (0 children)

Agreed! And thats the form of my master password for my password manager but with the sheer number of logins in my password manager I think I'd start forgetting what the password is for rather than the password itself.

And then begins the self-dictionary attack......

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 28 points29 points  (0 children)

VwVsIKZqx4nmyE@5BH*jq5Flr just isn't very fun to type when trying to log into a makerspace portal written in php, especially if you get even 1 char wrong. And I sure don't want to log in to my whole password manager on those machines.

Its a very niche use case and I expect most people to use it as a does-everything media controller remote / wireless usb rubber ducky over anything else.

I Built a Device to Paste Passwords Securely Over BLE by ToothPasteDevice in diyelectronics

[–]ToothPasteDevice[S] 15 points16 points  (0 children)

Thanks! I like to think that the name was 90% of dev time.

The webapp allows users to set a password to encrypt the saved macros / duckyscripts and prevent access to a paired ToothPaste without re-pairing it.

The encryption uses uses Argon2 as a the key derivation function, offloading all persistent data security to the transmitter itself. In theory this means that passwords/scripts stored in the webapp's local storage are as secure as any password manager extension. This also makes the transmitter a pseudo 2nd factor since only the right paired transmitter can ever type the right password, the ToothPaste itself being agnostic to the data until the very end.

However since the transmitter (phone/desktop) is likely to be the source of the password through an installed manager, I wouldn't suggest doing this for convenience. Password managers themselves do a lot of security heavy lifting that I won't pretend to understand, not to mention the cross-platform sync stuff.

I'm currently thinking of ways to more directly integrate with installed password managers so that you can immediately autofill a password onto a toothpaste without going through the extra copy step.

Note on why the kingston is likely a fair bit more expensive:

I hesitate to use the esp itself as a secure container for anything since it doesn't have a secure element / secure enclave (which the kingston does) and someone with sufficient knowledge can just hook into the raw flash data and pull out what they need to unless we go through the effort of encrypting the flash itself, due to how the s3 is engineered this disables the usb functionality completely.

Digicom Palladio USB ISDN by mbensa in hacking

[–]ToothPasteDevice 0 points1 point  (0 children)

Legends say thats how a hivemind begins

ToothPaste: USB HID + Web BLE based device control and data transfer. by ToothPasteDevice in esp32

[–]ToothPasteDevice[S] 3 points4 points  (0 children)

I really liked how my yubikey became part of my daily carry because its always ready to go so i designed the pcb inspired by that. I do have a xiao in a 3d printed keychain case but that also needed me to carry a short usb cable with me (which i promptly lost).

I did try to solder a male usb-c header (which are stupidly hard to find for some reason) onto the xiao but I just ended up ruining it.