Yet another Hacker News

8 points rewant 4 days ago 8 comments

Anchor is a cross-platform desktop application that provides hardware-based authentication using SanDisk USB devices. The application automatically detects USB connection/disconnection events and provides secure database access only when an authorized USB device is connected.

Github:https://github.com/TheEleventhAvatar/Anchor

KomoD 2 days ago | parent

To call this "security" is funny in my opinion, can't any application also fetch the serial number?

And also do they not get saved in logs like dmesg?

vivid242 1 hour ago | parent

If you can restrict the software, this would be a good way for controlling physical user ‚presence‘ - like in the supermarket, when a supervisor needs to scan their card for a cash register to take out a wrongly scanned item. I like it!

alexpotato 1 hour ago | parent

You could also use encrypted and signed keys on the devices to confirm that it's the correct drive.

Was recently watching a video on the RFID tags that Bambu Labs use on their spools and not only is the tag data encrypted, it's signed so even if you bypass the encryption, you still don't have a way to spoof the signature.

vel0city 1 hour ago | parent

If they're just files on a flash drive, what stops someone from just copying the files to another drive? Its just moving the same issue up a level in the stack, and in many ways making it easier to clone it.

One of the whole points of authenticator devices is that the actual key material isn't directly readable. You shouldn't be able to trivially reproduce the device.

maximusdrex 1 hour ago | parent

Calling this "hardware-based security" is somewhere between disingenuous and dangerously naive. Hardware-based security normally implies hardware with a dedicated secure element with cryptographic identities which are impossible to spoof. Security based on USB serial numbers can be defeated by any adversarial device claiming to use the same serial device as a device you have registered. There's no secure signatures or anything backing a USB serial number.

This is so, so much worse than that though, because the code doesn't even do what the AI-hallucinated documentation describes, because as far as I can tell the actual "serial number" is returned by the following line: Ok(Some(format!("{:?}", device.product_id()))) So the "serial number" is actually the USB product id, which generally corresponds to the "model", not even unique per-device. So you didn't even test this with multiple identical flash drives.

follie 1 hour ago | parent

How else would you recover from a device failure?

Vexs 1 hour ago | parent

You don't. The normal procedure here is to have multiple unique keys with multiple unique secrets. If one breaks that's it it's broken. This also allows you to revoke a key without removing all keys.

ImPostingOnHN 1 hour ago | parent

You enroll up another hardware device (or 2) as a backup and securely store them in different places.

This is normal to do for yubikeys, for example.

The main point is that the secrets stored on the device are usually used to unlock other secrets stored elsewhere, and so themselves don't need to be synchronized often.